Re: [calsify] New Draft - Maintenance Notifications Using iCalendar

[Doug Royer <[e-mail]>]

On 7/16/19 4:44 PM, Michael Douglass wrote:
ject.
>>
>> The two are not incompatible, as schema.org ties to MIME-types (attachments). - See the schema.org contentType as one example. Structured-Data has no benefit over ATTACH. I think people misunderstand the ATTACH property.
> 
> So how as an attachment would we represent the example:
> 
> STRUCTURED-DATA;FMTTYPE=application/ld+json;
>   SCHEMA="https://schema.org/SportsEvent";
>   VALUE=TEXT:{\n
>     "@context":"http://schema.org"\,\n
>     "@type": "SportsEvent"\,\n
>     "homeTeam": "Pittsburgh Pirates"\,\n
>     "awayTeam": "San Francisco Giants"\n
>   }\n

Versus the current way, for which parsers already can read:

	ATTACH;FMTTYPE=text/SportsEvent;...:CID:sport-attachement1
	...
	ATTACH;FMTTYPE=text/Maintenance;...:CID:maint-attachement1


>>
>> The W3C (schema.org) and the IETF are in agreement on object identifiers. Schema.org allows for the definition of data sets, and they are tied to mime types when sent as separate, non-web-page objects.
>>
>> Don't over complicate your data set. Define it, then map it to agreed on names, value types, and when needed specific acceptable values. Then decide if its values are primarily web-page-content, or a stand alone transported objects. And if stand alone objects tied to calendar date/time, then keep with the same format and do not invent another one, it will just complicate parsers.
> I don't see how this complicates parsers: the value of structured-data can be ignored if you're not interested and presumably you havea parser if you are.

Because you now have to write new code, to do the same as ATTACH.



-- 

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