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

> * Ned Freed wrote:
> >> This also does not seem to
> >> address a problem that we actually have, people do not register types
> >> with very similar yet different "fragment identifier schemes", and if
> >> they did so, that would very likely be for good reasons.
> >
> >Actually, if the Wikipedia page on these things can be believed, they do. For
> >example, different fragment id syntaxes for "page N" with what appear to be
> >idential semantics seem to exist.

> Yeah, but if you use #page=13 versus #page(13) or some other variation
> is likely for good reasons, like, you want to use some meta-mechanism
> like XPointer that allows one but not the other. Would be nice to have
> some proper statistics.

... maybe. Having seen so many examples in other places of disrepancies that
turned out to be completely superfluous, I'm skeptical.

> >Based on this feedback, I now have (I'm leaving the XML in this time):
> >
> ><t>
> >Media type registrations can specify how applications should interpret
> >fragment identifiers <xref target="RFC3986"/> associated with the media type.
> ></t>
> >
> ><t>
> >Media types are encouraged to adopt fragment identifier schemes that are used
> >with semantically similar media types. In particular, media types that use a
> >named structured syntax with a  registered "+suffix" MUST follow whatever
> >fragment identifier rules are given in the structured syntax suffix
> >registration.
> ></t>

> This seems reasonable to me, though it would seem better to turn that
> into a general "+suffix types must follow +suffix rules, whatever they
> are" requirement.

Even if we were to insert such a general requirement, I think this one is so
important it bears repeating. Especially since it indirectly places limits on
what you really want to allow in a fragment identifier description in your
suffix registration. If you make this material too restrictive, the result will
be that the suffix won't be usable, and I think that's a good thing.

				Ned

Received on Wednesday, 18 April 2012 04:58:49 UTC