- From: Jacek Kopecky <jacek@idoox.com>
- Date: Wed, 19 Sep 2001 14:55:26 +0200 (CEST)
- To: christopher ferris <chris.ferris@east.sun.com>
- cc: Henrik Frystyk Nielsen <henrikn@microsoft.com>, christopher ferris <chris.ferris@Sun.COM>, Mark Nottingham <mnot@mnot.net>, <xml-dist-app@w3.org>
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
Received on Wednesday, 19 September 2001 08:55:28 UTC