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: Sun, 22 Apr 2012 00:03:18 +0200
To: ht@inf.ed.ac.uk (Henry S. Thompson)
Cc: Tony Hansen <tony@maillennium.att.com>, apps-discuss@ietf.org, www-tag@w3.org
Message-ID: <9ua6p79fh03lm9i7f6l98jorsnu9erqqi1@hive.bjoern.hoehrmann.de>
* Henry S. Thompson wrote:
>Bjoern Hoehrmann writes:
>> * Tony Hansen wrote:
>>>So I've added these Fragment identifier considerations sections to the 
>>>suffixes that have an underlying media type registration.
>>>
>>>     Media types using "+json" MUST accept any fragment identifiers
>>>     defined for "application/json". Specific media types may
>>>     identify additional fragment identifier considerations.
>>
>> This says that "+json" cannot be used for JSON types where fragment
>> identifiers are of any concern since any future specification of the
>> application/json type may override such registrations in incompatible
>> ways. This seems to be missing the point of why we would have "+json"
>> to begin with.
>
>Or, it implies any update to a syntax schema registration such as
>application/json has a responsibility to its "deployed base".  Comes
>with the territory.

Saying that an inferior authority must obey a superior authority does
not imply that the superior authority is limited by choices any such
inferior authorities have made. We might find that taking such choices
into consideration is the responsible thing to do, but that is not what
the text says, and certainly not how authorities tend to operate. Look
no further than the +xml discussions where people do not find they need
to re-define +xml in a manner compatible with all existing +xml types.
-- 
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 Saturday, 21 April 2012 22:03:49 UTC

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