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

[Ned Freed <[e-mail]>]

> * Jeni Tennison wrote:
> >---
> >
> >1. Add a new section 'Fragment Identifier Recommendations' (before the current 4.11 Additional Information) which says:
> >
> > Media type registrations SHOULD specify how applications should interpret
> > fragment identifiers [RFC3986] within the media type.

> I don't see how this would affect people who don't care about any frag-
> ment identifier semantics of their media types other than putting "n/a"
> in the template.

n/a is not a specification. This is effectively saying that all media types
SHOULD have fragment identifiers. That's unreasonable.

> > Media types SHOULD adopt fragment identifier schemes that are used with
> > other similar media types, to facilitate content negotiation across them.

> There are no "fragment identifier schemes", that would have to be de-
> fined, and it's rather unclear what "similar" is. Is XSL FO similar to
> PDF and should thus allow, say, #page=13?

Fair point. Nevertheless, encouraging some amount of consistency seems like 
a good idea. It just doesn't rise to the level of a requirement.

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

> I also do not
> agree with the "content negotiation" rationale.

I'm by no means familiar with all content negotiation schemes out there, so 
I wasn't willing to be categorical about that.

That said, I agree it definitely isn't the main rationale. As I see it, the
main rationale for specifying fragment identifiers associated with a given type
is the obvious one: So that it gets implemented consistently and the ids, you
know, actually work when you use them.

> > In particular, media types that use a named structured syntax with a
> > registered "+suffix" SHOULD adopt any and all fragment identifier schemes
> > defined within the structured syntax suffix registration.

> This is a layering violation. If the specification for the "+suffix"
> syntax wants to require "sub-types" to do so then it can. There is no
> reason to have this as part of the generic registration rules. This
> would also imply that these "sub-types" have to do something special
> to meet the requirement, rather than just having this by definition,
> by virtue of following the "+suffix" convention. I see no reason why
> the "+suffix" specification would make this SHOULD rather than MUST.

Another fair point. But the meta-point here is that whatever rules are
associated with the suffix need to be followed by types using that suffix. And
it's reasonable to state that here.

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>

				Ned