At 08:12 PM 5/6/99 +0900, MURATA Makoto wrote:
It appears that nobody think parameters are good enough reasons for
introducing a top-level media type "xml". Thus, the only possible reason is:
4. Document-like XML documents can be handled by general-purpose
XML viewers
I do not think this is a good reason either. XML browsers only have to
examine the stylesheet PI and then invoke appropriate formatting engines.
Thus, I believe that there is no reason to introduce a top-level media
type "xml".
Have we reached a consensus here?
No, we definitely haven't. While I didn't support the case you made
earlier for parameters, I still think a top-level media type of 'xml' would
be extremely useful. (I probably should have said this sooner, but hadn't
read closely enough to realize that parameters were the last 'good' reason
for a top-level xml type in the discussion.)
A key part of my concern over the use of MIME types is that MIME types are
used for more than just deciding how to process information once it has
been received. Applications can also use MIME types to negotiate the
content types they will accep using mechanisms like the HTTP Accept header.
It is not at all difficult for me to imagine scenarios where content
negotiation will be important as more and more formats evolve, all riding
along (presently) on application/xml.
For instance, the recent XSL Formatting Object discussions have brought up
a key issue - because FOs are just XML documents, information providers now
have another option for shipping readable but otherwise useless text to
their customers, saving the semantic XML for those willing to pay a fee.
In this case, being able to tell the difference between xml/xfo and
xml/x-pfml (where x-pfml is the paid for markup language) is extremely
significant. Servers may have to make decisions about what form to send a
document in based on received types.
Right now, we just have a weak set of tools for guessing what a client is
capable of based on its ID string. MIME types haven't been powerful enough
(or well-enough used) to handle this work. We have an opportunity here to
give MIME types real work in improving server-client relations and improve
the efficiency of XML transfers.
application/xml (or text/xml) doesn't say anything about the 'real'
expectations of the receiving application. As a result, we may see a lot
of wasted or terminated transactions as 'junk' arrives to client software
that isn't capable of processing what the server sent.
Another, more philosophical, point that I'd like to make is that XML isn't
_just_ a stream of characters. Unlike regular text documents, or even most
binary formats, XML documents contain internal structure that can be used
for processing and storage. You _can_ store XML documents as plain old
text files in plain old file systems - but you can also store your XML
documents in a data store that uses the internal structure of the document
to keep it hierarchically.
XML may be text, but it is certainly text+. Having meaningful MIME types
to describe that information would be much more useful than finagling
namespaces and reading into multiple portions of a document to figure out
what exactly it contains.
If all this goes over like a lead balloon, I'll step out of the way and let
you move on to consensus.
Simon St.Laurent
XML: A Primer
Sharing Bandwidth / Cookies
http://www.simonstl.com