Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures

> Tony Hansen writes:

> > So, I'm revising my draft where I'm actually *registering* a bunch of
> > these structured suffixes. (draft-hansen-media-type-suffix-reg)
> >
> > What I'm thinking is that the fragment considerations section for each
> > should simply point at the base application/whatever
> > specification. That is, if application/SUFFIX has specific fragment
> > identifiers associated with it, then anything with +SUFFIX (e.g.,
> > application/TYPE+SUFFIX) should accept the application/SUFFIX fragment
> > identifiers as well as anything specific to the given media type.
> >
> > So I've added these Fragment identifier considerations sections to the
> > suffixes that have an underlying media type registration.
> >
> >     Media types using "+json" MUST accept any fragment identifiers
> >     defined for "application/json". Specific media types may
> >     identify additional fragment identifier considerations.
> >
> > I have similar text for +fastinfoset, +wbxml and +zip.
> >
> > In addition, I'm thinking draft-hansen-media-type-suffix-reg should
> > have an IANA considerations note to add the Fragment identifier
> > considerations section for +xml, with text similar to the above.

> If you go in that direction, please consider the fact that 3023bis
> _is_ once again under active development, with W3C TAG cooperation,

First of all, given that there has been no I-D posting of a 3023bis "active
development" is a bit of a stretch. There may be something going on inside the
W3C, but 3023 is an IETF RFC, and that means new versions need to be posted as
I-Ds and discussion needs to be happning on an IETF list. I strongly urge
whoever is working on this to see that this happens ASAP.

All that aside, this sort of revision is the reason why Tony is taking this
approach. An 3023bis is necessarily going to contain both a new registration
for application/xml, quite likely including updated information on XML fragment
identifiers. Additionally, since +xml is defined in 3023 and assuming the new
media types registration procedures are in place before 3023bis, 3023bis is
going to have to contain an updated registration for +xml.

> and that something very similar to the following (slightly adapted
> from the previous editors' draft) will likely appear therein:

>   When a new media type is introduced for an XML-based format, the
>   name of the media type SHOULD end with '+xml'. This convention will
>   allow applications that can process XML generically to detect that
>   the MIME entity is supposed to be an XML document, verify this
>   assumption by invoking some XML processor, and then process the XML
>   document accordingly. Applications may match for types that
>   represent XML MIME entities by comparing the subtype to the pattern
>   '*/*+xml'.

>   XML generic processing is not always appropriate for XML-based media
>   types. For example, authors of some such media types may wish that
>   the types remain entirely opaque except to applications that are
>   specifically designed to deal with that media type. By NOT following
>   the naming convention '+xml', such media types can avoid XML-generic
>   processing. Since generic processing will be useful in many cases,
>   however -- including in some situations that are difficult to
>   predict ahead of time -- those registering media types SHOULD use
>   the '+xml' convention unless they have a particularly compelling
>   reason not to. [1]

> Note that these paragraphs address _more_ than just fragment
> identifiers.  The level of "generic processing", i.e. processing
> appropriate to any member of a stuctured-syntax family identified by a
> +SUFFIX, is I think the appropriate one at which to address the mutual
> dependency between app/foo and app/bar+foo.

Of course. And this actually won't be sufficient - as noted above, a
proper +xml registration will also be needed.

				Ned

Received on Sunday, 22 April 2012 02:31:56 UTC