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

> I think that their assumption was actually that all the image/*, video/* and
> audio/* types would re-register, referencing the Media Fragment spec.

Let me put the kibosh on any such assumption right now. The primary purpose of
this revision exercise is to try and get more people to register the media
types they use. This is, for a variety of reasons, a lot harder than it sounds.

And you can multiply the reluctance of registrants by a factor of 100 at least
when it comes to updating registrations. We're actually doing an adequate job
of getting initial registrations for new types outside of the standards tree,
but the number of people who are willing to revise registrations to include
additional information, especially if that has no immediate relevance to them
personally, is negligable.

As such, the notion that existing registrations will be updated wholesale to
include fragment identifier information is nothing short of laughable.

> Perhaps that's the best way of handling it, and nothing needs to be said
> specifically about fragments identifiers for top-level types.

This isn't an option either. This is a registration best current practices
(BCP) document that sets down rules for registering media types. Default or
intrinsic syntax and semantics of fragment identifiers associated with a
particular top-level type is a protocol specification. This isn't allowed in a
BCP - BCPs are one shot affairs and not subject to interoperability testing,
which rather obviously would apply to the specification of such semantics.

If you want to put this stuff in an RFC, it needs to one that's on the regular
standards track. And that means it needs to be in a different document. All you 
can put in this document are the registration rules for specifying a fragment
identifier. Nothing more.

> In that case, the media type specification draft would need to point out that
> other media types within the same top-level type may describe the use of a
> particular fragment identifier syntax, and that if they do then to make content
> negotiation between different media types work more smoothly, it's best to
> adopt that same fragid syntax in new media types rather than inventing a new
> one.

You can certainly put all that in a separate document and reference it here.
But I doubt very, very much that that can be done on a sufficiently short time
scale for this revision, although as I said before, I deferring how to handle
this to the document shepard, WG chairs, and apps ADs.

> >>   3. generic syntax specified for types sharing a suffix (eg XPointer for XML [2])
> >>   4. specific syntax specified for individual media types
> >>
> >> Taking these in reverse order, I think what we're aiming for is:
> >>
> >> Media type registrants need to be guided to specify the fragment identifier schemes that they inherit from any top-level type or suffix type and how any clashes should be handled. They also need to be guided to reserve plain name fragment identifiers for their common use, and to think about what constraints the media type places on "active fragment identifiers" which may be used within scripts.
> >
> > If there is no multiple inheritance (from top level types), there should be fewer or no clashes at all.

> Even without anything being said for top-level types, there's always the
> possibility of multiple inheritance. For example, say that someone invented a
> fragment identifier syntax for programming languages that used
> #function({name}) to reference functions within source files. If we wanted to
> use that with XSLT, we would need to say so within the application/xslt+xml
> media type definition and deal with the fact that the syntax clashed with
> XPointer syntax inherited through the use of the +xml suffix.

I have to say that this sounds like a much bigger problem than can possibly be
addressed by the addition of a few simple rules to the registration
specification, which given that the primary goal here is to have a registration
process people can use easily, is all that's going to be acceptable here.

> So it still rests with the media type definition itself to explain which
> fragment identifier schemes are supported and how they interact, even if
> there's no explicit recognition of inheritance from the top-level types.

I suspect that without some defaults, probably based on type suffix as much on
top-level types, laid out in one or more standards-track RFCs, this is unlikely
to get much traction.

> >> [2] http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-04.html#frag
> >
> > Note that the draft above has never been submitted as Internet Draft, so
> > from the IETF's point of view it doesn't exist.
> > See <https://datatracker.ietf.org/doc/draft-murata-kohn-lilley-xml/>.

> OK :) I believe the question of what exactly to put in that draft about
> fragment identifiers has been the main thing holding up its submission.

The point of publishing an Internet Draft isn't to expose your polished final
work to the world. Rather, it's to release your working material, missing parts
and all, so that unresolved issues like, say, how to handle fragment
identifiers can be exposed to broader discussion and input. This is
*especially* true of a document which, if the path is any indication, is
intended to be an update to RFC 3023.

Indeed, I'd have to call it highly inappropriate to have handled such an update
in this fashion.

					Ned

Received on Saturday, 14 April 2012 05:34:00 UTC