Re: [calsify] SCHEMA vs New Property

[Michael Douglass <[e-mail]>]

On 7/8/19 23:44, Doug Royer wrote:
> On 7/8/19 8:25 PM, Michael Douglass wrote:
>> As Ken said earlier this is a perfect use for the new Structured-Data 
>> property defined in the eventpub-extensions draft
>>
>> https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/
>>
>> (I will try to get a new version out this week)
>>
>> The benefit of this approach is that it requires no further 
>> extensions to iCalendar - your maintenance data is carried as a 
>> payload with a known schema.
>
> You say "no further extensions". They would still have to be 
> documented. So would that save any documentation work?
> If released as an RFC, then the SCHEMA uri and content value would be 
> documented. That seems identical in function  as placing them in their 
> own property name.
>
> The only difference is that STRUCTURED-DATA allows, and forces, 
> iCalendar implementations to include parsers for each unique SCHEMA. 
> And does that without *any* restriction to the content (VALUE) format.
STRUCTURED-DATA DOES NOT force any client to parse the data. If it 
doesn't recognize the schema it's free to ignore it completely.
>
> Where as, by defining them as new properties, any compliant iCalendar 
> implementation can parse them now, preserve them, even when they do 
> not know what to do with them. They can even display them as KEY/VALUE 
> pairs.
>
> STRUCTURED-DATA just forces multiple and unlimited new and random data 
> formats into the VALUE. While still requiring them to be documented 
> and published. Seems like more documentation work, and more 
> implementation work. With one new data type parser for each new SCHEMA 
> published.
>
> Why have 2+ data formats in the same object?
I see no requirement for publishing anything about the schema other than 
to reserve it. The only requirement for publishing is if the schema 
definer wishes 3rd parties to make use of it. It doesn't even have to be 
defined and published with the ietf. It's payload
>
> It looks to me as if STRUCTURED-DATA is just a way of passing opaque 
> data that will contain proprietary information. This completely 
> reverses the idea of a standard calendar object.
>
> If your going to document a new data-set. Document it in iCalendar 
> format. Not in unlimited, unrestricted and random formats.
So if somebody has XML or JSON data they wish to transport - already 
defined by a schema - they are required to recast that as iCalendar? I 
think not. Without STRUCTURED-DATA they'll just push it across as an 
x-prop or attachment then it's even more opaque.
>