- From: Marc Hadley <Marc.Hadley@Sun.COM>
- Date: Fri, 17 Feb 2006 11:38:11 -0500
- To: Jonathan Marsh <jmarsh@microsoft.com>
- Cc: Anish Karmarkar <Anish.Karmarkar@oracle.com>, public-ws-addressing@w3.org
- Message-id: <7C33457E-0D67-48FE-957F-03CFB75000C1@Sun.COM>
+1, I'd also much prefer to keep the defaulting at the infoset serialization level. Marc. On Feb 16, 2006, at 4:16 PM, Jonathan Marsh wrote: > > My 2c - this change isn't cost-effective. > > The proposal is apparently motivated by cleaning up the so-called > problem of specifying a default that might not make sense in some > situations (but that's why it's a default that can be overridden > instead > of a constant!) It's not clear that abstracting out defaulting > from XML > infoset representation (which is already confusingly abstracted > from the > properties on the one side, and from SOAP headers on the other) > makes a > whole lot of sense. Why pick defaulting to move from one level of > abstraction to another and not, say, the optionality of the elements? > The previous proposal to make [destination] optional shows how > arbitrary > this "solution" is. > > The shifting sands of these abstractions could be subject to lots more > discussion, ref my proposal to roll the specs together and collapse > some > of these abstractions (XML infoset and SOAP headers would become one) > was not accepted by the group. I can live with the WG's will, grumble > grumble, but IMO further twiddling adds unnecessary complication to > the > already complicated set of abstractions and editorially obscures the > defaulting mechanism by moving it to an unexpected location in another > spec. > > I'm worried about any change to the specs at this stage because of the > general concern of unintended side-effects as we're trying to lock > down > interop results. This change isn't directly motivated by results > of the > interop work, so it's not essential to address. The status quo > functions perfectly well, despite the aesthetic concerns which > appear to > be addressable only at the expense of whatever simplicity we have > left. > > > Therefore my preference is to close CR20 with no action. > >> -----Original Message----- >> From: public-ws-addressing-request@w3.org > [mailto:public-ws-addressing- >> request@w3.org] On Behalf Of Anish Karmarkar >> Sent: Thursday, February 16, 2006 11:02 AM >> To: public-ws-addressing@w3.org >> Subject: CR 20: amalgamated proposal >> >> >> Here is a joint proposal to resolve issue 20. >> >> The proposal does the following: >> >> a) Gets rid of defaulting in the Core, but allow bindings to specify >> defaults. >> b) Does not change the cardinality of [destination] or wsa:To in the > Core >> c) specifies that messages on the "back channel" must have the value > of >> 'anon' for the [destination] property. >> d) specifies 'anon' as the default for messages on the back channel. >> e) incorporates wordings similar to Paul Downey's which say that > outside >> of this particular scope this spec does not define any particular >> semantics for the 'anon' URI. >> >> Please note that this proposal keeps the resolution text of CR4, >> which >> either got removed as a result of resolution of CR15 or was an > editorial >> oversight (I have already sent a separate email for this). If we do > not >> keep the resolution of CR4 then the editors will have to change the >> wordings to make it fit better. >> >> Proposal: >> -------- >> >> 1) In the Core spec [1], section 3.2, change: >> ----- >> /wsa:To >> This OPTIONAL element (whose content is of type xs:anyURI) > provides >> the value for the [destination] property. If this element is NOT > present >> then the value of the [destination] property is >> "http://www.w3.org/2005/08/addressing/anonymous". >> ----- >> >> to: >> ----- >> /wsa:To >> This OPTIONAL element (whose content is of type xs:anyURI) > provides >> the value for the [destination] property. A binding of Addressing >> to a >> specific protocol may define a default value for wsa:To. In the > absence >> of such a default, a value for wsa:To MUST be specified. >> ----- >> >> 2) In the SOAP binding spec [2], in section 5.1 add: >> ----- >> {The para below is the resolution text for CR4 and included here for > flow} >> When "http://www.w3.org/@@@@/@@/addressing/anonymous" is specified as >> the address of an EPR, such as the ReplyTo or FaultTo EPR, the >> underlying SOAP protocol binding provides a channel to the specified >> endpoint. Any underlying protocol binding supporting the SOAP >> request-response message exchange pattern provides such a channel for >> response messages. For instance, the SOAP 1.2 HTTP binding [SOAP 1.2 >> Part 2: Adjuncts] puts the reply message in the HTTP response. >> >> {The next 2 paras below are new} >> Messages on such a channel must have a [destination] property >> value of >> "http://www.w3.org/@@@@/@@/addressing/anonymous". Additionally, this > is >> the default value of such responses if the [destination] value is not >> specified. >> >> Outside of this usage, this specification assigns no particular >> semantics to the use of > "http://www.w3.org/@@@@/@@/addressing/anonymous" >> for the [destination] property in this binding. >> >> >> -Paco & Anish >> -- >> >> > > --- Marc Hadley <marc.hadley at sun.com> Business Alliances, CTO Office, Sun Microsystems.
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Friday, 17 February 2006 16:38:19 UTC