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: Tue, 18 Sep 2001 13:49:12 -0700
Message-Id: <>
To: "Larry Masinter" <LMM@acm.org>, <xml-dist-app@w3.org>
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
John J. Barton          email:  John_Barton@hpl.hp.com
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 16:49:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:15 UTC