RE: text/xml for SOAP is incorrect

Andrew brings up a very good point about vocabularies inside SOAP 
messages.  A slightly different view of this is that routing may be done 
based upon soap, but it probably will also be done based upon the body, ie 
getStockTicker.  And it might be routed through a SAML intermediary.  So 
should the name be 
application/getStockTicker+SAML10+crypto+dsig+soap+xml?   We're going to 
have to crack the message to get the information we need anyways, so let's 
not warp content type just for our particular need.

The way I see it, SOAP and XML are meant to be extended, unlike other XML 
vocabularies such as svg, xhtml.  SOAP is more akin to XML than xhtml 
because of the extensibility and composability features, even though it is 
a discrete vocabulary.  Using the same rules for specific vocabularies 
should not apply to SOAP.

One other thing, SOAP is XML.  I've heard some talk about SOAP parsing 
being different because it's a subset of XML, and that SOAP is not "really" 
XML.  There are lots of XML documents and vocabularies that do not use all 
the features of XML 1.0, like notations, internal subsets, etc.  Just 
because a vocabulary does not make full use of the features of XML doesn't 
mean it's "not" XML.  Imagine if we said that XML documents without any 
attributes weren't XML.

Cheers,
Dave



At 10:55 AM 9/19/01 -0700, Andrew Layman wrote:
>But if intermediaries are going to distinguish SOAP from non-SOAP xml,
>would not some intermediaries need to further distinguish among classes
>of SOAP messages?  Suppose that facilities are invented that add digital
>signatures or encryption, for example.  Might not some intermediaries
>desire to distinguish such secured SOAP messages from other SOAP
>messages?  If so, do we end up with "application/crypto+dsig+soap+xml"?
>This seems like a very slippery slope we are setting out on.
>
>And, if we embark on names such as "application/crypto+dsig+soap+xml",
>then how do we designate which crypto spec is being referenced?  Which
>dsig spec?  This is contrary to the decentralized naming in URLs that
>made the web grow so fast and successfully.
>
>
>-----Original Message-----
>From: Mark Nottingham [mailto:mnot@mnot.net]
>Sent: Wednesday, September 19, 2001 9:42 AM
>To: Jacek Kopecky
>Cc: christopher ferris; Henrik Frystyk Nielsen; christopher ferris;
>xml-dist-app@w3.org
>Subject: Re: text/xml for SOAP is incorrect
>
>
>
>I think that's the intent of the '+xml' - to allow MIME processors
>identify it as an XML format.
>
>My concern is not so much dispatch - which is what the request-uri
>should be used for, at any rate - but for identifying the messages as
>being formatted to the SOAP conventions for those that will casually
>handle them, such as intermediaries.
>
>We've decided to run the HTTP binding on port 80, and to use HTTP status
>codes to indicate SOAP semantics. SOAPAction is optional. If SOAP 1.2
>messages use application/xml, there is no easy way to identify a message
>as SOAP. As a result, parts of the Web infrastructure may treat SOAP
>messages as any old XML, performing transforms, etc. Additionally,
>firewall vendors won't even have a stop-gap means of controlling the
>flow of SOAP messages.
>
>Is our intent to effectively hide the use of SOAP? Doing so seems to
>risk both interoperability problems and the appearance that we're
>antagonistic to firewalls, etc.
>
>
>
>
>On Wed, Sep 19, 2001 at 02:55:26PM +0200, Jacek Kopecky wrote:
> >  Chris,
> >  To explain my position: I am wary of application/soap and
> > application/soap+xml because it won't usually allow generic processing
>
> > as if it were XML. It's true that the usability of such generic
> > processing is debatable, but I don't immediately see the advantages of
>
> > application/soap...  either (when I strike out what I feel is misuse -
>
> > that would be the dispatching usecase).
> >
> >                             Jacek Kopecky
> >
> >                             Idoox
> >                             http://www.idoox.com/
> >
> >
> > P.S: 21st century started on Sep 11, 2001
> >
> >
> >
> > On Wed, 19 Sep 2001, christopher ferris wrote:
> >
> >  > Henrik,
> >  >
> >  > Certainly you agree that SOAP is it's own thing.
> >  > It just happens to also be XML. SOAP has its own process
> >  > model. Why the resistance to a soap-specific
> >  > media type? Certainly seems mostly harmless to me.
> >  >
> >  > Cheers,
> >  >
> >  > Chris
> >  >
> >  > Henrik Frystyk Nielsen wrote:
> >  > >
> >  > > >Sure, why not? You can reflect the SOAP version in a MIME  > >
> > >"version" parameter on the Content-Type header. Dispatchers  > > >can
>
> > choose whether to use this (or not) as they see fit. A  > > >SOAP
> > processor can make the determination as to support of the  > >
> > >namespace by inspecting the namespace and further dispatching  > >
> > >as needed (or loading the right modules, schema, whatever).  > >
> >  > > How is this different from regular XML processing to the degree
>that it
> >  > > requires a special content type?
> >  > >
> >  > > Henrik
> >
>
>--
>Mark Nottingham
>http://www.mnot.net/
>

Received on Saturday, 22 September 2001 01:57:13 UTC