- From: John J. Barton <John_Barton@hpl.hp.com>
- Date: Tue, 18 Sep 2001 13:49:12 -0700
- 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 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 16:49:07 UTC