Re: [calsify] SCHEMA vs New Property

[Michael Douglass <[e-mail]>]

On 7/9/19 16:57, Tim Hare wrote:
> What is needed is documentation that says all calendar UAs are not required
> to handle STRUCTURED-DATA and SCHEMA,  perhaps that if STRUCTURED-DATA is
> used then DESCRIPTION  SHOULD be present to describe what the structured
> data is so that any CUA can display _that_ text,  but consumers of the
> calendar item that DO understand the SCHEMA can use it.
>
> In my view, defining new properties for every possible kind of VEVENT or
> VTODO amounts to the same amount of work as defining a SCHEMA for that
> structured data.  CUAs would fail, graciously, to process those properties
> in the just about same way as they'd fail to handle the structured data.
> The difference, to me,  is that using STRUCTURED-DATA and SCHEMA  means the
> RFC isn't constantly updated for new use cases involving new kinds of data
> that is related to the calendar event but not calendar data per se.

Additionally - data that is incompatible with the iCalendar format can 
be transported easily.

And I don't think it's quite the same amount of work.

New iCalendar properties need to be generally useful in calendars and 
scheduling. Very specific properties used to address a need such as this 
are probably better contained in data with their own schema.

There's a whole other discussion as to whether or not these properties 
are generally useful - probably not as something only for maintenance.

As an aside having reread the draft - email is not the only possible 
transport mechanism. CalDAV or some other protocol might be appropriate. 
Any draft should probably allow for different ways of transporting the 
messages.


>
> Tim Hare
> Interested Bystander, Non-Inc.
>
>
>
>
> -----Original Message-----
> From: calsify [mailto:[e-mail]] On Behalf Of Doug Royer
> Sent: Monday, July 8, 2019 11:44 PM
> To: [e-mail]
> Subject: [calsify] SCHEMA vs New Property
>
> 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.
>