RE: CR 20: amalgamated proposal

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
> --
> 
>

Received on Thursday, 16 February 2006 21:16:40 UTC