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: Noah Mendelsohn <nrm@arcanedomain.com>
Date: Fri, 20 Apr 2012 14:54:35 -0400
Message-ID: <4F91B0EB.6040304@arcanedomain.com>
To: "Henry S. Thompson" <ht@inf.ed.ac.uk>
CC: Tony Hansen <tony@maillennium.att.com>, apps-discuss@ietf.org, "www-tag@w3.org List" <www-tag@w3.org>

On 4/20/2012 5:09 AM, Henry S. Thompson wrote:
> Note that these paragraphs address_more_  than just fragment
> identifiers.  The level of "generic processing", i.e. processing
> appropriate to any member of a stuctured-syntax family identified by a
> +SUFFIX, is I think the appropriate one at which to address the mutual
> dependency between app/foo and app/bar+foo.

Right, I'm happy with that.

In the context of the overall recommendations on media types, I think it's 
worth thinking a bit about the tradeoffs. There are at least two possible 
goals for having each "derived" type accept (at least) the same 
syntax/semantics as the base: 1) it promotes least astonishment for users 
-- things work as you'd expect; 2) you might wish to enable generic processing.

If generic processing is a goal, then it's worth thinking about the 
consequences of SHOULD vs. MUST. If we go with SHOULD, which is OK with me, 
then it might be worth saying:

"Note: if the specification for a derived type provides for a different 
interpretation of some particular fragment identifier(s) than the base 
does, then generic processors may resolve such identifiers incorrectly."

So, SHOULD somewhat undercuts efforts to enable generic processing, insofar 
as it leaves open the possibility of misinterpreting even conforming 
identifiers and content. I think we should either go with MUST, or warn of 
the risk.

Received on Friday, 20 April 2012 18:55:09 UTC

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