I am cross-posting to ietf-822(_at_)imc(_dot_)org because Keith correctly
points out
that <http://www.normos.org/ietf/draft/draft-murata-xml-02.txt> raises
fundamental architectural questions regarding the right way to integrate XML
and MIME. Those issues have been discussed on ietf-xml-mime(_at_)imc(_dot_)org
and I
believe a rough consensus was achieved, but the purpose of this thread is to
try to confirm that.
why? is there really much value in a default treatment of text/* xml
documents as plain text? (the default doesn't seem to work well in
practice for text/html) or is xml really likely to be used for
image/*, audio/*, video/*, or model/* content?
how do you figure that? such categorization is the primary purpose of
top-level types. and while I grant that XML could be used to represent
images, audio, or video...it does not seem well-suited as a presentation
layer for these.
Keith, I think this may be the crux of the disagreement. For the "-xml"
suffix to make sense, I think it must be likely that XML structure data will
show up in multiple MIME top-level types AND that that data could be
generically processed in a useful way. Those two constraints would imply
that XML is acting fundamentally as the presentation layer in the network
stack (apologies for obligatory OSI network stack reference), and that that
presentation information should be available to dispatchers that can make
use if it.
The fact that almost all subtypes based on XML can be generically processed
is addressed in the I-D and excerpted in my message, which I attach below.
As to whether subtypes based on XML belong in different top-level type, I
believe the following examples demonstrate that XML-based data types will
most likely be registered in ALL top-level categories:
Application/*:
IOTP
<http://www.normos.org/ietf/draft/draft-ietf-trade-iotp-v1.0-protocol-07.txt
RDF <http://www.w3.org/RDF/>
MathML <http://www.w3.org/Math/>
Audio/*:
Nothing yet, but don't rule out VXML <http://www.vxml.org/> or a derivative
SMIL is also a possibility <http://www.w3.org/AudioVideo/>. Also, note that
XML modularization <http://www.w3.org/TR/xhtml-modularization/> makes it
quite likely that new XML subtypes will be created that serve specific
needs, and encoding binary audio information is completely feasible.
Video/*:
SMIL and/or a derivative could be registered here or in Application/*
<http://www.w3.org/AudioVideo>
Model/*:
UML <http://www.omg.org/uml/> (may be under Application/*)
If VRML were being started from scratch today it would likely be built in
XML. See <http://www.vrml.org/WorkingGroups/dbwork/vrmlxml.html> for some
integration discussion.
Image/*:
SVG <http://www.w3.org/Graphics/SVG/>
Text/*:
XHTML <http://www.w3.org/TR/xhtml1/>, though this is better under
Application/*
- dan
--
Daniel Kohn <mailto:dan(_at_)dankohn(_dot_)com>
tel:+1-425-602-6222 fax:+1-425-602-6223
http://www.dankohn.com
-----Original Message-----
From: Keith Moore [mailto:moore(_at_)cs(_dot_)utk(_dot_)edu]
Sent: Friday, 2000-03-10 11:38
To: Dan Kohn
Cc: Keith Moore; ietf-types(_at_)iana(_dot_)org; Martin J. Duerst; MURATA
Makoto;
ned(_dot_)freed(_at_)INNOSOFT(_dot_)COM; Donald E. Eastlake 3rd
Subject: Re: reason for application/iotp-xml (was RE: Registration of
MIME med ia type APPLICATION/IOTP)
okay - more generally, I don't think we should make a special case in
the MIME content-type syntax (not even using an ad hoc mechanism)
for content-types that happen to be based on XML. MIME already has
a mechanism to define default handling of certain classes of objects,
in the top-level content-type. If there's really enough utility in
doing this for XML, we should create an xml/ top-level type.
We shouldn't create another separate syntactical convention to do this.
Keith, take two potential types, image/svg-xml and application/mathml-xml.
In both cases, for dispatchers that don't understand or care about XML,
the
"-xml" suffix is completely opaque.
it may be opaque, but it still does harm if it constrains evolution of
the MIME content-type space.
These subtypes need to be under
existing top-level types in order to be dispatched correctly.
why? is there really much value in a default treatment of text/* xml
documents as plain text? (the default doesn't seem to work well in
practice for text/html) or is xml really likely to be used for
image/*, audio/*, video/*, or model/* content?
A new XML
top-level type doesn't provide any information of categorization, because
XML-based MIME types can fall in any of the top level categories.
how do you figure that? such categorication is the primary purpose of
top-level types. and while I grant that XML could be used to represent
images, audio, or video...it does not seem well-suited as a presentation
layer for these.
but this again begs the question about how much encoding information
you want to make explicit in the content-type name. and my main point
is that the answer is not obvious - embedding -xml in the name comes
at a cost. we need to think carefully before either (a) establishing
yet another syntactic convention for content-type names, or (b)
making XML explicit in a content-type name. and this is is a MIME
architectural issue - it isn't something that should be done just because
XML proponents think it is a good idea.
if there is going to be such a convention, it needs to be carefully
considered both for its impact on the MIME architecture and whether
it's actually desirable to do this for XML. (the latter is easier to
justify than the former)
In summary, there is no downside to using the "-xml" suffix
disagree. see above.
Keith
-----Original Message-----
From: Dan Kohn
Sent: Friday, 2000-03-10 11:19
To: Keith Moore
Cc: ietf-types(_at_)iana(_dot_)org; Martin J. Duerst; MURATA Makoto;
ned(_dot_)freed(_at_)INNOSOFT(_dot_)COM; Donald E. Eastlake 3rd
Subject: reason for application/iotp-xml (was RE: Registration of MIME
media type APPLICATION/IOTP)
Keith Moore said:
okay - more generally, I don't think we should make a special case in
the MIME content-type syntax (not even using an ad hoc mechanism)
for content-types that happen to be based on XML. MIME already has
a mechanism to define default handling of certain classes of objects,
in the top-level content-type. If there's really enough utility in
doing this for XML, we should create an xml/ top-level type.
We shouldn't create another separate syntactical convention to do this.
Keith, take two potential types, image/svg-xml and application/mathml-xml.
In both cases, for dispatchers that don't understand or care about XML, the
"-xml" suffix is completely opaque. These subtypes need to be under
existing top-level types in order to be dispatched correctly. A new XML
top-level type doesn't provide any information of categorization, because
XML-based MIME types can fall in any of the top level categories.
However, for dispatchers that do understand XML, and especially for those
that haven't seen a specific type before (such as application/iotp-xml), the
"-xml" suffix provides additional information that the content could instead
be dispatched to an XML browser or processed generically in various ways.
In the IOTP example, this could be very useful in allowing someone not
configured to deal with the subtype to at least have the information
displayed in an accessible way. Of course, if the dispatcher is configured
to deal with IOTP, then the "-xml" remains opaque.
In summary, there is no downside to using the "-xml" suffix, but significant
potential functionality can be gained.
To quote <http://www.normos.org/ietf/draft/draft-murata-xml-02.txt>:
While the benefits of specific MIME types for particular types of
XML documents are significant, all XML documents share common
structures and syntax that make possible common processing.
Some areas where 'generic' processing is useful include:
o Browsing - An XML browser can display any XML document with a
provided CSS[12] or XSLT[19] style sheet, whatever the vocabulary
of that document.
o Editing - Any XML editor can read, modify, and save any XML
document.
o Fragment identification - XPointers[16] can work with any XML
document, whatever vocabulary it uses and whether or not it uses
XPointer for its own fragment identification. [Editor's note: the
use of non-XPointer fragment identifiers by XML vocabularies like
SVG and SMIL requires further discussion.]
o Hypertext Linking - XLink[17] hypertext linking is designed to
connect any XML documents, regardless of vocabulary.
o Searching - Search engines, agents, and XML-oriented query tools
should be able to read XML documents and extract the content and
names of elements and attributes even if they are ignorant of the
particular vocabulary used for elements and attributes.
o Storage - XML-oriented storage systems, which keep XML documents
internally in a parsed form, should similarly be able to process,
store, and recreate any XML document.
Also, note that Murata-san's draft has specific "opt-out" language if your
XML-based MIME type is not suitable for generic processing:
XML-generic processing is not always appropriate for XML-based media
types. For example, some such media types may require fragment
identifiers different from XPointer. By *not* following the naming
convention */*-xml, such media types can avoid XML-generic
processing.
However, I would suggest that application/iotp-xml is a perfect illustration
of the utility of suffix-based naming.
- dan
P.S. Please use ietf-types(_at_)iana(_dot_)org, which is the permanent address
for
this list, rather than ietf-types(_at_)uninett(_dot_)no(_dot_)
--
Daniel Kohn <mailto:dan(_at_)dankohn(_dot_)com>
tel:+1-425-602-6222 fax:+1-425-602-6223
http://www.dankohn.com