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

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

> 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? 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. I also do not
agree with the "content negotiation" rationale.

> 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.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Tuesday, 17 April 2012 02:09:34 UTC