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: Henry S. Thompson <ht@inf.ed.ac.uk>
Date: Fri, 20 Apr 2012 10:09:21 +0100
To: Tony Hansen <tony@maillennium.att.com>
Cc: apps-discuss@ietf.org, "www-tag@w3.org List" <www-tag@w3.org>
Message-ID: <f5bzka6hiri.fsf@calexico.inf.ed.ac.uk>
Tony Hansen writes:

> So, I'm revising my draft where I'm actually *registering* a bunch of
> these structured suffixes. (draft-hansen-media-type-suffix-reg)
>
> What I'm thinking is that the fragment considerations section for each
> should simply point at the base application/whatever
> specification. That is, if application/SUFFIX has specific fragment
> identifiers associated with it, then anything with +SUFFIX (e.g.,
> application/TYPE+SUFFIX) should accept the application/SUFFIX fragment
> identifiers as well as anything specific to the given media type.
>
> 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.
>
> I have similar text for +fastinfoset, +wbxml and +zip.
>
> In addition, I'm thinking draft-hansen-media-type-suffix-reg should
> have an IANA considerations note to add the Fragment identifier
> considerations section for +xml, with text similar to the above.

If you go in that direction, please consider the fact that 3023bis
_is_ once again under active development, with W3C TAG cooperation,
and that something very similar to the following (slightly adapted
from the previous editors' draft) will likely appear therein:

  When a new media type is introduced for an XML-based format, the
  name of the media type SHOULD end with '+xml'. This convention will
  allow applications that can process XML generically to detect that
  the MIME entity is supposed to be an XML document, verify this
  assumption by invoking some XML processor, and then process the XML
  document accordingly. Applications may match for types that
  represent XML MIME entities by comparing the subtype to the pattern
  '*/*+xml'.

  XML generic processing is not always appropriate for XML-based media
  types. For example, authors of some such media types may wish that
  the types remain entirely opaque except to applications that are
  specifically designed to deal with that media type. By NOT following
  the naming convention '+xml', such media types can avoid XML-generic
  processing. Since generic processing will be useful in many cases,
  however -- including in some situations that are difficult to
  predict ahead of time -- those registering media types SHOULD use
  the '+xml' convention unless they have a particularly compelling
  reason not to. [1]

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.

ht

[1] http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-04.html
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]
Received on Friday, 20 April 2012 09:10:14 UTC

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