[calsify] SCHEMA vs New Property

[Doug Royer <[e-mail]>]

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.

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?

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.
  
-- 

Doug Royer - (http://DougRoyer.US)
[e-mail]
714-989-6135