W3C home > Mailing lists > Public > xml-dist-app@w3.org > September 2001

RE: text/xml for SOAP is incorrect

From: Dan Kohn <dan@dankohn.com>
Date: Mon, 17 Sep 2001 18:02:32 -0400 (EDT)
To: "'John J. Barton'" <John_Barton@hpl.hp.com>, "'Simon St.Laurent'" <simonstl@simonstl.com>, "'Mark Baker'" <distobj@acm.org>, <mmurata@trl.ibm.co.jp>
Cc: <xml-dist-app@w3.org>
Message-ID: <006d01c13fc4$62eec680$6401a8c0@skymoonventures.com>
(I'm the third co-author of RFC 3023; sorry to triple-team you.)

As XML becomes more common, it is quite likely to have multiple XML
parsers on your machine.  The issue for the MIME transport engine, then,
is to which parser the MIME object should be dispatched.  Clearly, a
DocBook or RFC 2629-based XML document should be handled differently
than SOAP.  Now yes, this is exactly what DTDs are for, but the argument
is that also putting the information in the MIME type makes dispatch
much simpler, especially for existing mail, file, and HTTP engines (not
to mention emerging BEEP ones).  These arguments are well-covered in
Appendix A of RFC 3023.

Essentially, using application/soap+xml should cause no interoperability
problems, since most SOAP peers today are expecting SOAP messages and
will judge based on the namespace or DTD.  But, using a unique MIME type
opens up the potential for SOAP messages to be better dispatched and
treated, both with legacy applications (e.g., operating system level
MIME registries such as .mailcap in Unix and HKEY_CLASSES_ROOT in
Windows) and with new gateways, OS file dispatchers, and other things
not yet invented.

You're welcome to either use application/xml or application/soap+xml.
But since there are potential advantages to the latter and no obvious
disadvantages, the conservative move would be to use
application/soap+xml.

BTW, although text/html is a disgrace and should never be shown (in raw
form) to na´ve users, text/uri-list, text/tab-separated-values, and
text/vnd.abc all probably belong in the text tree.

		- dan
--
Dan Kohn <mailto:dan@dankohn.com>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>

-----Original Message-----
From: John J. Barton [mailto:John_Barton@hpl.hp.com] 
Sent: Monday, September 17, 2001 14:19
To: Simon St.Laurent; Mark Baker; mmurata@trl.ibm.co.jp
Cc: xml-dist-app@w3.org; dan@dankohn.com
Subject: Re: text/xml for SOAP is incorrect


At 02:44 PM 9/17/2001 -0400, Simon St.Laurent wrote:
[ discussion of MIME quoted from Fielding deleted ]
(I left this out to concentrate on Content-type rather and
MIME itself.  It was Fielding's description of how
architectures can obtain reusability by enforcing
generality of component connection, eg pipe-and-filter
style,  that I was citing.)


>>A SOAP message is text: it can be read with text tools and
>>it is encoded as XML so XML parsers can study it and parse
>>further information without hints.
>
>That is not the understanding the IETF has about the use of text/ 
>top-level types.  Text is expressly for human-readable usages.  There
were 
>a number of participants on ietf-xml-mime who wanted text/xml struck
from 
>3023 entirely, and I have to admit that I would support such action.

That sounds sensible, though I guess that text/plain is the
only media that is just human readable.


>>There should not be a
>>different media type for XML sent to an "application"
>>verses one sent to a "browser" (which is just another
>>application).  The server should not assume the use of
>>the media representation.
>
>The server should label the content it sends to the client to the best
of 
>its ability.  In this case, I would argue that text/xml is at best a 
>cop-out, at worst a lie.

Ok you convince me: text/xml is not a good choice.  But no,
the server should not label the content to the best of its
ability, but only adequately for the client to launch the
correct parser.  That leaves us with "application/xml".


>>Therefore application/xml is not necessary.  I suppose it
>>may be to late to turn back from that.  But let us not go
>>further down the path to application/soap+xml,
>>application/soap_for_ecommerce+xml,
>>application/soap_for_book_buying+xml
>>application/soap_for_book_buying_and video_buying+xml, etc.
>>Content-type should describe the media type, not its use,
>>or provide other information that is elsewhere.
>
>I'll settle quite happily for application/soap+xml, and the rest you
can 
>sort out within SOAP, thanks.


So we agree up to here if you can settle for application/xml,
but sorting out media types within an application domain is
exactly what we should not be doing.  Media types should not
be domain specific, they should only aid the client in
selecting a parser.  Once in XML we can read the details:
<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope">

At some point we may have special proxy components able to
do special work on SOAP messages.  Then fast activation
paths for SOAP (XMLP) may be needed.  First we should have one.


______________________________________________________
John J. Barton          email:  John_Barton@hpl.hp.com
http://www.hpl.hp.com/personal/John_Barton/index.htm
MS 1U-17  Hewlett-Packard Labs
1501 Page Mill Road              phone: (650)-236-2888
Palo Alto CA  94304-1126         FAX:   (650)-857-5100
Received on Monday, 17 September 2001 18:21:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:03 GMT