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

> On 4/17/2012 3:15 AM, Julian Reschke wrote:
> > On 2012-04-17 02:53, Ned Freed wrote:
> >> ...
> >> I note that this raises the issue of what to do about fragment
> >> identifiers in
> >> the initial suffix registry document. Fragment identifiers don't
> >> really make
> >> sense for most of the suffixes defined there. The exceptions I see are
> >> +xml and
> >> +json. +json seems simple enough - refer to
> >> draft-ietf-appsawg-json-pointer-01.
> >> ...
> >
> > I think that would be premature.
> >
> > The question has come up several times, and I don't think we are near
> > any kind of even rough consensus about whether the spec should try to
> > define a fragment identifier syntax for "+json" (or even application/json).
> >
> >> +xml is a bigger issue. This is a document to populate the registry;
> >> it is not
> >> the place to define how fragment identifiers for XML work. But RFC
> >> 3023 section
> >> 5 seems a bit dated. And waiting for a revision for RFC 3023 when
> >> there isn't
> >> even an I-D doesn't sound like a good idea. So dated or not, I guess a
> >> reference to RFC 3023 is as good as it gets for now.

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

The operative term here is "should". There may be very compelling reasons why
you want to support fragment identifiers but not the ones that are normally
associated with whatever format your media type uses.

For example, suppose you defined some sort of structured image representation
using XML. It is entirely possible that the elements of that representation are
basically worthless when it comes to referencing parts of the image. So it
makes no sense to require support for XPointer-based fragment ids in such a
case. Even if such fragment ids were useful for, say, some sort of general
editing application for XML, they neverthless would place an undue burden on
conforming imlementations of that 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 like the overall idea but, per the above, MUST is too strong. SHOULD
is appropriate here, and I'd capitalize the may in the second sentence.

> I have similar text for +fastinfoset, +wbxml and +zip.

> This way, the definition of fragment identifiers for application/json
> can progress at its own pace, as can any definitions of fragment
> identifiers for application/fastinfoset, application/vnd.wap.wbxml and
> application/zip.

Yes, this is very clever, and entirely apporpriate for an initial registry
content document. This is not the place to be defining default fragment
identifier mechanisms for suffixes. Doing so is going to require a lot of work,
and I expect a fair bit of contention for some of them.

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

Agreed.

				Ned

Received on Friday, 20 April 2012 07:32:34 UTC