Re: [calsify] SCHEMA vs New Property

[Doug Royer <[e-mail]>]

On 7/8/19 10:04 PM, Michael Douglass [Masked] wrote:
> 
>
> 
> 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
>
> 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

Yes, your proposing a free for all data object. Do whatever you want. The opposite of a standard 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.
> 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.

They both are opaque data, except you saying it is different.

X-PROP and STRUCTURED-DATA are the same thing. Random non standard blobs of data to implementations that do not know what they mean. The ATTACH base-64 encoding/decoding value allows for any kind of data.

    X-MY-PROP;x-myparam-data-set-3:base-64-text

They both contain the same thing.

That was the debates with X-PROP. A standard way to parse random blobs of propitiatory data. It makes you want to standardize the data sets to use it across vendors.

And STRUCTURED-DATA is a name that implies structure. It is not. It could be unstructured data, blobs of weather data, blobs of random disk errors. It has no added value over X-PROP or ATTACH. The data could be base-64 encoded or not, it is just text.

Example:

   ATTACH;FMTTYPE=text/html;...:base-64 encoded html page, or URL or CID to that page

vs

   STRUCTURED-DATA:SCHEMA=http://www.w3.org/TR/html4;...:base-64 encoded html page, or URL or CID to that page, or text that may have to be base64 encoded anyway because of its content.

vs

  STRUCTURED-DATA:SCHEMA=http://MyPrepratorySchema;...:base-64 encoded html page, or URL or CID to that page, or text that may have to be base64 encoded anyway because of its content.

Use ATTACH with a CID value, pointing to MIME object and set the mime-type value.

Set the ATTACH fmttypeparam and CID part MIME-TYPE to text/xml or application/json (or whatever) and include anything you can transport.

Or set the ATTACH value to an external URL with ATTACH fmttypeparm set to the correct data type.

If you need to, define and register a new mime-type for your data (schema). Or use an x-mime-type with ATTACH with your preparatory data.

Did I miss something that STRUCTURED-DATA can do, that X-PROP or ATTACH can not do?
Creating it simply because you do not want to base64 encode text is a heavy solution when you can already ATTACH the value in binary, text, or whatever by using a CID URI or a URL URI all of which can contain plain text.

iCalendar is a MIME object.

-- 


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