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

[Ryan Gunter <[e-mail]>]

Hello,

Appreciate the replies.  Sorry for the delay.

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

This involves scheduling. We looked through schema.org quite a bit and
noticed the same thing.  The idea is the additional fields were to allow
for easier machine parsing, while still functioning as a calendaring file.

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

Is this suggesting to use the ATTACH property with a defined data set from
schema.org, or otherwise?  If that's the case, we could work with schema.org
to define these data sets?  The original hope of the draft was to agree
upon a way to provide network maintenance information within the file.  If
we went with the ATTACH or STRUCTURED-DATA route, would there be a way to
define this data set or method within the IETF?  I just want to make sure I
understand the boundaries and drive this effort correctly.


Ryan Gunter  |   *Twitch* <http://www.twitch.tv/>   |   Network Engineering
 |   +1.415.568.7607


On Tue, Jul 16, 2019 at 5:05 PM Doug Royer <[e-mail]> wrote:

> 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
>
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify
>