RE: Syntax options for Async

I would like to see more detail on how these proposals tie in with being
specified at the operation level, and their interaction with
wsdl:required.  I do not think we should support the specification of
general WS-A support at the operation level, and I don't think the WG
ever agreed to do this, yet AIUI each of the syntax proposals below
imply this is possible.  Options 1 and 3 appear to allow the
"requiredness" of anonymous support to be separately specified from
general WS-A support at the binding level.  While that might be a good
thing, it's not clear precisely what it means when these aren't in sync.
Option 2 seems to force one to re-claim general WS-A support when making
async claims, and with such redundancy we need to deal with potential
conflicts.

 

Did you consider <wsa:UsingAddressing> on the binding or endpoint, and a
separate attribute wsaw:Anonymous="required | optional | prohibited"
that could be attached to operations? i.e. make the anonymous handling
flag look more like wsaw:Action than like <wsa:UsingAddressing>?  Then,
<wsa:UsingAddressing> can remain at the binding/endpoint level, and no
separate wsdl:required can appear, and we don't have to answer questions
about the conflicts.

 

As you may have noticed from my example above, I prefer the value of
this attribute or element to follow the familiar terms cribbed from the
schema "use" attribute, who's schema follows.

 

       <xs:attribute name="use" default="optional" use="optional">
          <xs:simpleType>
            <xs:restriction base="xs:NMTOKEN">
              <xs:enumeration value="prohibited"/>
              <xs:enumeration value="optional"/>
              <xs:enumeration value="required"/>
            </xs:restriction>
          </xs:simpleType>
        </xs:attribute>

 

 

________________________________

From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Yalcinalp,
Umit
Sent: Wednesday, November 16, 2005 10:50 AM
To: WS-Addressing
Subject: Syntax options for Async

 

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.ht
ml
<http://lists.w3.org/Archives/Public/public-ws-addressing/2005Oct/0116.h
tml>  
[Marc]
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Nov/0039.ht
ml
<http://lists.w3.org/Archives/Public/public-ws-addressing/2005Nov/0039.h
tml>  
[Action Item] http://www.w3.org/2002/ws/addr/5/11/f2f-minutes.html
<http://www.w3.org/2002/ws/addr/5/11/f2f-minutes.html>