Re: [calsify] SCHEMA vs New Property

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.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: calsify [mailto:calsify-bounces@ietf.org] On Behalf Of Doug Royer
Sent: Monday, July 8, 2019 11:44 PM
To: calsify@ietf.org
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.

-- 

Doug Royer - (http://DougRoyer.US)
Douglas.Royer@gmail.com
714-989-6135

_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify