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

Re: text/xml for SOAP is incorrect

From: John J. Barton <John_Barton@hpl.hp.com>
Date: Mon, 17 Sep 2001 14:18:43 -0700
Message-Id: <4.3.2.7.2.20010917125613.01e6ef48@hplex1.hpl.hp.com>
To: "Simon St.Laurent" <simonstl@simonstl.com>, Mark Baker <distobj@acm.org>, mmurata@trl.ibm.co.jp
Cc: xml-dist-app@w3.org, dan@dankohn.com
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 17:18:45 GMT

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