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

RE: text/xml for SOAP is incorrect

From: Andrew Layman <andrewl@microsoft.com>
Date: Tue, 18 Sep 2001 14:06:52 -0700
Message-ID: <C3729BBB6099B344834634EC67DE4AE102540032@red-msg-01.redmond.corp.microsoft.com>
To: <xml-dist-app@w3.org>
Add my agreement to John Barton's statements below.

-----Original Message-----
From: John J. Barton [mailto:John_Barton@hpl.hp.com] 
Sent: Tuesday, September 18, 2001 1:49 PM
To: Larry Masinter; xml-dist-app@w3.org
Subject: RE: text/xml for SOAP is incorrect


At 11:25 AM 9/18/2001 -0700, Larry Masinter wrote:
>I think application/soap+xml is better than application/xml for 
>different reasons than given by others. I think it's better because 
>SOAP messages do not allow arbitrary XML expressions. For example, the 
>SOAP specification restricts:
>
>   A SOAP message MUST NOT contain a Document Type Declaration.
>   A SOAP message MUST NOT contain Processing Instructions.
>
>further, SOAP contains more restrictive rules for encoding types than 
>XML:
>
>   XML allows very flexible encoding of data. SOAP defines a
>   narrower set of rules for encoding.

SOAP is-a instance of XML.  Expressing this narrowing in a typename
leads us down the path of distributed object systems. Each new
restriction motivates a new sub-typename.  The tree of subtypes must be
propagated to all clients/servers and subsystems.  The effective API
becomes broader and broader, increasingly incomprehensible.  Of course
you can say SOAP is really special and it will be the last subtype we
need.  Well, except for a couple more, application/msn+xml,
application/hp-printing+xml, and application/aol+xml.


>MIME labeling is a packaging technology, and the purpose of packaging 
>is not primarily 'routing' in this case (since the URL and SOAPAction 
>header do that) but mainly 'protection'.
>
>Wrapping SOAP content with "content-type: application/soap+xml" instead

>of "content-type: application/xml" protects the SOAP content better 
>from intermediaries that might translate one "application/xml" body 
>into an equivalent one (using XML
>rules) but would leave application/soap+xml alone.

Wouldn't a new header directed at these intermediaries
like the ones designed for caches be more appropriate?
Bundling implicit behavior (transformable) with the typename
(application/xml) again leads us in an OO direction.  XML
may be transformable or not; SOAP may be transformable or
not.  It sounds an issue for "control data", not "representation
metadata". ______________________________________________________
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 Tuesday, 18 September 2001 17:08:00 GMT

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