W3C home > Mailing lists > Public > www-tag@w3.org > April 2012

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

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Wed, 18 Apr 2012 06:47:24 +0200
To: Ned Freed <ned.freed@mrochek.com>
Cc: Jeni Tennison <jeni@jenitennison.com>, "www-tag@w3.org List" <www-tag@w3.org>, apps-discuss@ietf.org
Message-ID: <tghso756ijcpgn1udkugi7os5ik9rglgp8@hive.bjoern.hoehrmann.de>
* 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.

>Based on this feedback, I now have (I'm leaving the XML in this time):
>Media type registrations can specify how applications should interpret
>fragment identifiers <xref target="RFC3986"/> associated with the media type.
>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

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.
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 Wednesday, 18 April 2012 04:47:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:44 UTC