W3C home > Mailing lists > Public > public-ws-addressing@w3.org > November 2005

Re: Syntax options for Async

From: David Hull <dmh@tibco.com>
Date: Wed, 16 Nov 2005 13:58:04 -0500
To: "Yalcinalp, Umit" <umit.yalcinalp@sap.com>
Cc: WS-Addressing <public-ws-addressing@w3.org>
Message-id: <437B813C.2080406@tibco.com>
I prefer (2).  I believe the name of the attribute was to be (or
contain) "Anonymous", in which case

    <wsa:UsingAddressing Anonymous="Allowed"/>

seems better than

    <wsa:UsingAddressing Anonymous="AnonAllowed"/>

Again, I /don't/ like the use of "async" anywhere in this, as the term
is too heavily overloaded.

Yalcinalp, Umit wrote:

> Folks,
>
> I took an [action item] to send Proposal 1 so that it can be
> reevaluated and modified. I am wondering whether we could make high
> level decisions on the syntax first because this is where we will end
> up anyway. If we make a decision first on this, it is easier to write
> this section as it is a straightforward exercise.
>
> We have three options to represent asyncronous capabilities of the
> endpoint, binding or binding/operation to describe the granularity of
> supporting anonymous and non-anonymous URI as response addresses.
>
> We have three granularity levels to support (full capabilities of
> addressing, supporting only anonymous URIs as response addresses or
> supporting only non-anon)
>
>
> (1) Two elements (as [Proposal1])
>    usingAddressing element as currently described
>    Async element which is used in conjunction with usingAddressing
> element with three values.
>
> (2) Marc's proposal (usingAddressing element with an attribute with
> three values) [Marc].
>     He proposes "Required", "Allowed", "Disallowed". I propose
> "AnonRequired", "AnonDisallowed", "AnonAllowed" to reflect the
> semantics we want to capture.
>
> (3) (new option) This came up during our conversations in writing
> Proposal 1 and I speculate it may be discussed again.
>
>    Use three elements:
>
>    usingAddressing: It corresponds to the full usage of addressing
> semantics including both anon/non-anon URI
>    usingAddressingAnonURIRequired (obvious)
>    usingAddressingNonAnonURIRequired (obvious)
>
> In option 1 and 2, we need to replace the text:
>
> {The inclusion of the wsaw:UsingAddressing element indicates that the
> applicable WS-Addressing specifications are supported within the
> constraints of the WSDL binding being used. That is, uses of the
> WS-Addressing specifications that may violate or are inconsistent with
> the semantics of the endpoint's WSDL binding are not supported unless
> explicitly stated by some other mechanism.
>
> Specifically, when included in a SOAP binding, the
> wsaw:UsingAddressing marker identifies the use of Web Services
> Addressing 1.0 bound to SOAP as defined by Web Services Addressing 1.0
> - SOAP Binding[/_WS-Addressing-SOAP_/].
>
> The presence of the wsaw:UsingAddressing element in the binding or
> endpoint (port) components of the endpoint description does not change
> the semantics of the binding. E.g. in the case of the WSDL SOAP/HTTP
> synchronous binding for request-response operations, the presence of
> the wsaw:UsingAddressing element does not change the requirement that
> the response message be sent over the same HTTP channel over which the
> request was received. In this case, the wsa:replyTo header in the
> request MUST NOT contain an address with a value different from the
> anonymous URI.}
>
> The last option requires changes section 3.1 somewhat as we need to
> introduce all the new elements.
>
>
> Let me know if you still want to see the full writeup for Option 1. I
> will be very happy to write the target text depending on which syntax
> that we choose to adopt as well.
>
> All syntax formulations must reflect the decision we have taken as a
> wg, namely
>
> == there are three levels of granularity
> == the new {Async element/attribute|?} is general, not targeted to
> SOAP1.1/HTTP and talks about anon/non-anon URIs in their definition.
>
> == scoping is extended to binding operation
> == separate section targets SOAP 1.1/HTTP binding semantics (semantics
> of separate connection, 202, etc).
>
>
> --umit
>
>
> [Proposal1]
> _http://lists.w3.org/Archives/Public/public-ws-addressing/2005Oct/0116.html_
>
> [Marc]
> _http://lists.w3.org/Archives/Public/public-ws-addressing/2005Nov/0039.html_
>
> [Action Item] _http://www.w3.org/2002/ws/addr/5/11/f2f-minutes.html_
>
>
Received on Wednesday, 16 November 2005 18:58:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:10 GMT