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

[Michael Douglass <[e-mail]>]

On 7/16/19 14:46, Doug Royer wrote:
> On 7/16/19 10:17 AM, Ryan Gunter [Masked] wrote:
>> Preview: Ken / All, Thank you very much for the help. This is my 
>> first --> SPAM? CLICK to BLOCK 
>> <https://dnt.abine.com/#/block_email/[e-mail]/[e-mail]>
>>
>> This email is Masked using Blur - it was sent from ietf.org to 
>> [e-mail] (your reply stays Masked). To protect your 
>> privacy <https://www.abine.com/faq.html#caniaddcc>, do not forward 
>> this message, or add new recipients like CCs or BCCs.
>>
>> Thanks for being a Blur customer! If you haven't yet, [ Try DeleteMe 
>> at a discount. 
>> <https://joindeleteme.com/?utm_campaign=blur-offer&utm_source=masked-email-header> 
>> ]
>>
>> Ken / All,
>>
>> Thank you very much for the help.  This is my first IETF process so 
>> I'm still learning.
>>
>> Our team has been discussing the options, and the STRUCTURED-DATA 
>> field might be better fit for our network maintenance use case.  Has 
>> there been any discussion about coding support / libraries / tooling 
>> for this property? Also, the draft indicates using standardized 
>> schemas from schema.org <http://schema.org> or hosting your own is 
>> acceptable, however we were curious if there were any thoughts on 
>> storing schemas specifically for STRUCTURED-DATA?
>
> Is this a workflow process that involves scheduling? Or are you 
> looking for an XML/HTML (schema.org) web page solution? A massive 
> percentage of the schema.org schemas are CSS or HTML content.
>
> From the NANOG mailing list, it looked as if you wanted to 
> automatically track a log of calendaring events (past or future) and 
> have a standard way to describe and parse the description to keep 
> track of what was done or needs to be done. (looks like 
> calendaring/scheduling to me)
>
> If your content is primarily for automated display (html or otherwise) 
> of data, then maybe schema.org web content will be what you want.
>
> If your content is for processing and work flow (that may be 
> displayed), then you may want an iCalendar (or other type) object.
>
> 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

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