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

[[e-mail] (Henry S. Thompson)]

Ned Freed writes:

> First of all, given that there has been no I-D posting of a 3023bis "active
> development" is a bit of a stretch. There may be something going on inside the
> W3C, but 3023 is an IETF RFC, and that means new versions need to be posted as
> I-Ds and discussion needs to be happning on an IETF list. I strongly urge
> whoever is working on this to see that this happens ASAP.

Absolutely -- the 'active development' I refer to is only a few weeks
old, and the goal is to get a new I-D up as soon as possible.

> All that aside, this sort of revision is the reason why Tony is
> taking this approach. An 3023bis is necessarily going to contain
> both a new registration for application/xml, quite likely including
> updated information on XML fragment identifiers. Additionally, since
> +xml is defined in 3023 and assuming the new media types
> registration procedures are in place before 3023bis, 3023bis is
> going to have to contain an updated registration for +xml.

Since +xml is the structured syntax we have the most experience with
to date, I hope we can coordinate the two, so that the experience of
the XML community is not lost.

>> 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.
>
> Of course. And this actually won't be sufficient - as noted above, a
> proper +xml registration will also be needed.

For sure -- 3023 contained one, informally, as it were, in the absence
of official guidance at that time, and 3023bis will do so as well,
coordinated, as I said above, with the new official guidance.

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: [phone], e-mail: [e-mail]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]