Re: Proposal for issue 277 - part 2

On Thursday, Oct 17, 2002, at 22:13 US/Eastern, 
noah_mendelsohn@us.ibm.com wrote:
>
> Herve Ruellan writes:
>
>>> That's correct, we could just use the namespace URI of the envelope
> version.
>
> I'm not sure I've thought this through properly, but what if some 
> future
> version of soap changed the local part of the envelope name:
>
> <soap:Envelope2 xmlns:soap="...uri for soap 2.0...">
>
> Is it completely clear that SOAP 1.2 would never want to send a version
> mismatch for this?  I can't quite decide how it would know, but you 
> could
> argue that any root element of the supposed message infoset is by
> definition intended as some version of the envelope.  If so, I think we
> need to send either a QName or an Expanded Name, and I suggest we stick
> with QName.  In general, sending just the namespace name on the theory
> that the local name is always Envelope seems unnecessarily tricky.  We 
> use
> QNames to identify elements in many other faults, so I suggest doing 
> the
> same here.
>
I disagree, the namespace of the envelope defines the version of SOAP - 
any future version of SOAP that added new elements or changed element 
names would also have to change the namespace. The upgrade header block 
just declares support for a particular version and hence only the 
namespace is required - claiming to support that version means 
supporting changed or multiple root elements so there's no need to 
mention them explicitly.

regards,
Marc.

>
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
>
>
>
>
>
>
> "Herve Ruellan" <ruellan@crf.canon.fr>
> Sent by: xml-dist-app-request@w3.org
> 10/14/2002 11:03 AM
>
>
>         To:     xml-dist-app@w3.org
>         cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
>         Subject:        Proposal for issue 277 - part 2
>
>
>
> Hello all,
>
> This is the second part of a proposal for resolving issue 277 [1] (half
> dealing with action attributed to Jean-Jacques)
> This second part is about the use of many Namespaces in the spec, which
> may be unwieldy and unnecessary.
>
> Here is a list of the namespaces used in the spec (both part 1 [2] and
> part 2 [3]) and a summary of their use:
>
> 1) env -- http://www.w3.org/2002/06/soap-envelope
> Used for Envelope related EII and AII
>
> 2) flt -- http://www.w3.org/2002/06/soap-faults
> This is the namespace for the SOAP header block generated by
> mustUnderstand faults.
> Used for NotUnderstood eii
>
> 3) upg -- http://www.w3.org/2002/06/soap-upgrade
> This is the namespace for the SOAP header block generated by
> VersionMismatch faults.
> Used for:
> Upgrade eii
> Envelope eii (child of Upgrade eii)
>
> 4) enc -- http://www.w3.org/2002/06/soap-encoding
> This is the namespace for SOAP encoding.
> Used for:
> itemType aii.
> arraySize aii.
>
> 5) rpc -- http://www.w3.org/2002/06/soap-rpc
> This is the namespace for RPC.
> Used for:
> result eii.
> ProcedureNotPresent fault Subcode
> BadArguments fault Subcode
>
> 6) context --
> http://www.w3.org/2002/06/soap/bindingFramework/ExchangeContext/
> This namespace is used for defining properties which apply to a message
> exchange context:
> ExchangePatternName
> FailureReason
> Role
> State
>
> 7) mep -- http://www.w3.org/2002/06/soap/mep/
> Not used.
>
> 8) fail -- http://www.w3.org/2002/06/soap/mep/FailureReasons/
> Not used any more.
>
> 9) reqres -- http://www.w3.org/2002/06/soap/mep/request-response/
> This is the namespace for the request-response MEP.
> It is used for defining properties which apply to the request-response
> mep (those properties are also used in the SOAP Response MEP):
> reqres:OutboundMessage
> reqres:InboundMessage
> reqres:ImmediateDestination
> reqres:ImmediateSender
>
> 10) webmeth -- http://www.w3.org/2002/06/soap/features/web-method/
> This is the namespace for the Web Method feature.
> It is used for defining one property:
> webmeth:Method
>
>
> Proposal
> --------
> Here is a proposal for dealing with all those namespaces. This proposal
> was cut into pieces to allow a finer grained decision process.
>
> (i) Keep http://www.w3.org/2002/06/soap-envelope namespace
>
> (ii) Merge http://www.w3.org/2002/06/soap-faults namespace and
> http://www.w3.org/2002/06/soap-upgrade namespace into
> http://www.w3.org/2002/06/soap-envelope namespace.
> <rationale>
> This remove two namespaces. Both are used in the main part of the SOAP
> 1.2 specification and are tightly linked with the processing of SOAP
> messages.
> </rationale>
>
> (iii) Keep http://www.w3.org/2002/06/soap-encoding namespace.
> <rationale>
> This namespace is used for defining aii in an independant part of the
> spec.
> </rationale>
>
> (iv) Keep http://www.w3.org/2002/06/soap-rpc namespace.
> <rationale>
> This namespace is used for defining an eii in an independant part of 
> the
> spec.
> </rationale>
>
> (v) Remove http://www.w3.org/2002/06/soap/mep/ namespace and
> http://www.w3.org/2002/06/soap/mep/FailureReasons/ namespace.
> <rationale>
> They are not used anymore.
> </rationale>
>
> (vi) Define properties using URIs and not QNames (see first part of
> proposal), and remove
> http://www.w3.org/2002/06/soap/bindingFramework/ExchangeContext/
> namespace, http://www.w3.org/2002/06/soap/mep/request-response/
> namespace and http://www.w3.org/2002/06/soap/features/web-method/
> namespace which are only used for defining properties.
> <rationale>
> It seems better to identify properties with URIs than with QNames.
> </rationale>
>
> Conclusion
> ----------
> Depending on the choices made over this proposal, we can have from 3 to
> 8 namespaces defined in the spec.
>
> Best regards,
>
> Hervé.
>
>
> [1] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x277
> [2] http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part1.xml
> [3] http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part2.xml
>
>
>
>
>
--
Marc Hadley <marc.hadley@sun.com>
XML Technology Center, Sun Microsystems.

Received on Friday, 18 October 2002 08:14:17 UTC