First, apologies for spreading this message across multiple discussion
groups. The headers for this round of discussion seem to keep growing, so
it would appear that there is interest in multiple circles.
The current draft of XML Media Types
(http://www.ietf.org/internet-drafts/draft-murata-xml-02.txt) includes a
section (6, with some examples in 7) representing a compromise position
arrived at through discussion on the ietf-xml-mime list. I'll attempt to
summarize that discussion with reference to particular posts, and describe
at the end why I think the compromise is worth supporting. Having
participated actively in the discussion, my viewpoint is biased, however,
so readers may wish to return to the archives themselves.
(http://www.imc.org/ietf-xml-mime/mail-archive/)
RFC 2376 provided the foundation for continuing work on XML Media Types,
describing the text/xml and application/xml types. RFC 2376 served a
critical need at the time, providing a basic set of rules for transferring
XML over MIME-aware systems. As XML development has spread to a wider
group, however, many developers began finding that they needed more
specific identifiers for particular XML vocabularies. In the process of
updating RFC 2376, we discussed how to handle these emerging vocabularies
as well as other critical issues, like identifying documents which are used
by XML without being XML per se, and encoding.
I arrived a bit late in the discussion, turning back claims
(http://www.imc.org/ietf-xml-mime/mail-archive/msg00060.html, #3) that
generic XML processing is not in fact useful as a fallback position. I
think at this point there is significant if not complete consensus on
ietf-xml-mime that generic XML processing can be useful in a wide variety
of situtations, not all of which can be predicted at design-time by the
creators of a particular specification.
Given that generic processing can be useful, and becomes far easier if
content is explicitly labeled as XML - I'll be happy to defend that
position in greater detail if necessary - the question becomes how best to
enable such processing within the MIME framework. (See
http://www.imc.org/ietf-xml-mime/mail-archive/msg00105.html for one
viewpoint opposing the provision of additional information within MIME
identifiers.)
I pushed hard at one point for a top-level xml/. In many ways, this would
let the two-part MIME identifiers continue with the least modification,
would take advantage of the hierarchical structure already present. This
did not prove acceptable, however, for a number of reasons that go well
beyond sheer reluctances to add another top-level types. Most notably, XML
can be used to represent content in any of the top-level areas described by
content-types. It is entirely plausible and in fact likely that a generic
tool for playing multimedia content (like the RealPlayer) would support
XML-based formats like SMIL or SVG.
As a result of this, discussion turned to other options for identifying XML
content. The use of additional parameters (beyond content-type) had been
discussed earlier, the creation of an XML registration tree was also
proposed by Rick Jelliffe.
I made a 'modest proposal'
(http://www.imc.org/ietf-xml-mime/mail-archive/msg00149.html, more formally
at http://www.imc.org/ietf-xml-mime/mail-archive/msg00149.html) for the
suffix, hoping to strike a balance between the existing structures and
newer needs. The thread that followed
(http://www.imc.org/ietf-xml-mime/mail-archive/threads.html#00200) was not
exactly a love-fest, but seemed to be acceptable.
Most discussion on the subject since the initial proposals has had to do
with the particulars of the Internet Drafts that subsequently included the
proposals, not a general attack on the principle behind the suffix. In my
other endeavors, outside of the IETF process, I haven't yet found
resistance to the suffix, though admittedly that's only about five cases,
all of which are in their early stages.
Yes, it's a compromise, and yes, it does mean additional work (suffix
examination) for applications that want to work with XML generically, but
it makes the task of generic XML tools much easier while imposing minimal
costs on the rest of the MIME infrastructure.
Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Cookies / Sharing Bandwidth
http://www.simonstl.com