- From: christopher ferris <chris.ferris@Sun.COM>
- Date: Tue, 18 Sep 2001 18:26:07 -0400
- To: Henrik Frystyk Nielsen <henrikn@microsoft.com>
- CC: Mark Nottingham <mnot@mnot.net>, Jacek Kopecky <jacek@idoox.com>, xml-dist-app@w3.org
Henrik, Please see below. Cheers, Chris Henrik Frystyk Nielsen wrote: > > >This presupposes the necessity of reflecting the message's > >namespaces in the content-type; why is this necessary? > > Well, isn't this how we have defined a mechanism for identifying SOAP -- > by the use of a specific XML Namespace identifier? > > If the content type is related to SOAP in any way then I think there is > an inherent link between whatever the content type is and the URI that > we pick for indicating that this is SOAP. > > In this context, what does a shortname even mean? Do we expect > "application/soap+xml" to point to any SOAP including SOAP 1.1, SOAP > 1.2, and beyond? 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). Note that Mark's point was to the argument that the argument presupposes reflecting the message's namespaces in the content-type ^^^^^^^^^^ which is a very different thing altogether than reflecting the fact that it is a SOAP message (regardless of version). > > >Defining a content-type always involves a tradeoff in the > >granularity of information available. IIRC, the discussion you > >reference was in the context of replacing SOAPAction with > >something in the content-type, which is not the intent here > >(based upon our resolution of issue 95). > > That maybe have been addressed in the long thread as well but at least > some parts talk about the use of "application/soap+xml" as a potential > content-type for SOAP. > > Henrik
Received on Tuesday, 18 September 2001 18:26:08 UTC