RE: Application Data Feature and related stuff

OK, i think that would kill wsdl:mustUnderstand, and wsoap:mustUnderstand
for that matter. 

Moving mustUnderstand into the binding sounds favourite and should answer 
the issue of mustUnderstand having different semantics in different bindings.

Paul

-----Original Message-----
From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
Behalf Of Asir Vedamuthu
Sent: 29 June 2004 14:38
To: Downey,PS,Paul,XSJ67A C; dorchard@bea.com;
gdaniels@sonicsoftware.com; Asir Vedamuthu; www-ws-desc@w3.org
Subject: RE: Application Data Feature and related stuff



> i think wsdl:mustUnderstand does satisfy

Question of clarification: if wsdl:mustUnderstand is an out-of-band
attribute in a schema, how does the WSDL component model capture it?

Asir

-----Original Message-----
From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
Behalf Of paul.downey@bt.com
Sent: Tuesday, June 29, 2004 8:38 AM
To: dorchard@bea.com; gdaniels@sonicsoftware.com; asirv@webmethods.com;
www-ws-desc@w3.org
Subject: RE: Application Data Feature and related stuff



The meaning of a wsdl:mustUnderstand attribute would need to be 
nailed down, and i'd suggest using the SOAP 1.2 semantics.

AIUI where 1.1 and 1.2 mustUnderstand differ is in the area of
fault processing, but like you say, given the WS-I have tried to
make SOAP 1.1 more like 1.2, i wonder how likely it is that a 
header element marked as mu in SOAP 1.1 would not be marked mu 
in SOAP 1.2 (or vice versa).

Yes, abstractions do leak, however i think the key to a 
good abstraction is usefulness for the majority case combined with 
the ability to 'go under the covers' for edge conditions.

i think wsdl:mustUnderstand does satisfy these two goals given 
you can still use the explicit schema syntax and hard-wire the 
attribute to a given SOAP version namespace.

Some possible alternatives i did consider:

   1) offer wssoap:mustUnderstand and wssoap11:mustUnderstand.
      Same as wsdl:mustUnderstand, but only populated by the 
      appropriate binding.

   2) move the ADD feature from the interface/operation into
      to binding/operation, allowing SOAP 1.1 and SOAP 1.2
      bindings to reference different elements.

   3) above used in combination with wsdl:mustUnderstand.
   
Paul


SOAP 1.1 mustUnderstand:
http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383500

SOAP 1.2 mustUnderstand:
http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#soapmu

SOAP 1.2 Primer on mustUnderstand:
http://www.w3.org/TR/2003/REC-soap12-part0-20030624/#L3031

WS-I BP on mustUnderstand:
http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-06-11.html#SOAP_mustUnder
stand_Attribute
http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-06-11.html#Generating_mus
tUnderstand_Faults

those leaky abstractions!:
http://www.joelonsoftware.com/articles/LeakyAbstractions.html



-----Original Message-----
From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
Behalf Of David Orchard
Sent: 28 June 2004 22:43
To: Glen Daniels; Downey,PS,Paul,XSJ67A C; asirv@webmethods.com;
www-ws-desc@w3.org
Subject: RE: Application Data Feature and related stuff



I think there's a poential problem with this proposal.  Soap 1.2
interpretation of mU is different than soap 1.1.  Now WS-I has done a good
job at moving the s12 view "into" s11, but that doesn't mean that all soap
1.1 implementations use the s12 view.  

Are there cases where these 2 come into conflict, that is application
behaviour is different depending upon which protocol is used?  If there are,
then it seems that the application needs to know which version is being
used.  It can't "hide" behind a layer of abstraction.  YALA (Yet another
leaky abstraction).   

Cheers,
Dave

> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
> Behalf Of Glen Daniels
> Sent: Saturday, June 26, 2004 10:31 PM
> To: paul.downey@bt.com; asirv@webmethods.com; www-ws-desc@w3.org
> Subject: RE: Application Data Feature and related stuff
> 
> 
> 
> 
> Our original thinking on this was that we would use SOAP 1.2 
> as a design
> center, and then bindings could potentially interpret the
> soap12:mustUnderstand attribute in the schema in their own ways -
> thinking about it more, I think your suggestion is better.  We should
> also do the same with wsdl:role if we see a need to set that.
> 
> --Glen 
> 
> > -----Original Message-----
> > From: paul.downey@bt.com [mailto:paul.downey@bt.com] 
> > Sent: Thursday, June 24, 2004 11:01 AM
> > To: asirv@webmethods.com; Glen Daniels; www-ws-desc@w3.org
> > Subject: RE: Application Data Feature and related stuff
> > 
> > This would be a problem for us too. 
> > 
> > I propose WSDL extends schema with a wsdl:mustUnderstand, 
> > which the binding then populates with the appropriate 
> > attribute and namespace,
> > e.g.:
> > 
> >     <element name="isGoldClubMember" 
> >             type="xs:boolean"
> > 		wsdl:mustUnderstand="true"/>
> > 
> > Paul
> > 
> > 
> > 
> > -----Original Message-----
> > From: www-ws-desc-request@w3.org 
> [mailto:www-ws-desc-request@w3.org]On
> > Behalf Of Asir Vedamuthu
> > Sent: 24 June 2004 13:54
> > To: 'Glen Daniels'; WS-Description WG
> > Subject: RE: Application Data Feature and related stuff
> > 
> > 
> > 
> > Glen,
> > 
> > I have one comment:
> > 
> > > As a SOAP sender, if the property
> > > http://www.w3.org/@@@@/@@/features/AD/data has a value 
> then each of 
> > > the top-level child element information items in the value 
> > SHOULD [ed:
> > > MUST?] be turned into a SOAP header.  The elements are serialized 
> > > according to their schemas, which might include the SOAP 
> > > "mustUnderstand" or "role"
> > > attributes, which will have the usual meaning in the resultant 
> > > headers.
> > 
> > > <attribute xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
> > >    ref="soap:mustUnderstand"
> > >    fixed="true"/>
> > 
> > This is SOAP 12 binding specific information at the abstract 
> > level, <types/>. I am wondering if we could avoid that. 
> > Embedding binding specific info at the abstract level takes 
> > away re-usability. In this specific case, I would like to 
> > re-use it for SOAP 11 binding.
> > 
> > Asir
> > 
> > -----Original Message-----
> > From: www-ws-desc-request@w3.org 
> > [mailto:www-ws-desc-request@w3.org] On Behalf Of Glen Daniels
> > Sent: Wednesday, June 23, 2004 1:05 PM
> > To: WS-Description WG
> > Subject: Application Data Feature and related stuff
> > 
> > 
> > 
> > 
> > WSDL'ers:
> > 
> > The following is the latest version of the application data 
> > feature, associated SOAP module, and HTTP binding feature 
> > that Dave, Yaron and I have been working on.  We believe we 
> > have come to substantial agreement about the structure and 
> > mechanism here, but there are still a few loose ends we'd 
> > like to sort out with the group (see the ed notes below).
> > 
> > Comments appreciated, and apologies for taking so long to get 
> > this out.
> > 
> > Thanks,
> > --Glen
> > 
> > 
> > = Application Data (AD) Feature =
> > 
> > This feature is identified with the URI
> > http://www.w3.org/@@@@/@@/features/AD
> > 
> > == Operation ==
> > 
> > This feature exists in order to enable the description of 
> > application-defined additional data declarations outside of 
> > the normal data channel (e.g. the SOAP body). The senders 
> > takes the value of the property 
> > http://www.w3.org/@@@@/@@/features/AD/data, which is defined 
> > below, and passes it to the receiver in a manner to be 
> > defined by the particular bindings/modules implementing this 
> > specification.
> > 
> > = AD/data Property =
> > 
> > This property is identified with the URI 
> > http://www.w3.org/@@@@/@@/features/AD/data.
> > 
> > == Description ==
> > 
> > The data property consists of a sequence of elements, each of 
> > which represents an individual piece of application data.  
> > Implementations of this feature must ensure that the runtime 
> > value of this property is correctly transferred from the 
> > sender to the receiver.
> > 
> > Here is an example of using the data property in a WSDL:
> > 
> > <types>
> >  <schema targetNamespace="http://foo"
> >          xmlns:xs="http://www.w3.org/2001/XMLSchema"
> >          xmlns="http://www.w3.org/2001/XMLSchema">
> >   <import namespace="http://www.w3.org/2003/05/soap-envelope"/>
> >   <!-- Define the data type we'll use later -->
> >   <complexType name="myDataType">
> >    <sequence>
> > 
> >     <!-- These elements are our data -->
> >     <element name="isGoldClubMember">
> >      <complexType>
> >       <simpleContent>
> >        <extension base="xs:boolean"/>
> >        <attribute 
> xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
> >                   ref="soap:mustUnderstand"
> >                   fixed="true"/>
> >       </simpleContent>
> >      </complexType>
> >     </element>
> > 
> >     <element name="promotionalCode"
> >              type="xs:string"
> >              minOccurs="0"/>
> > 
> >    </sequence>
> >   </complexType>
> >  </schema>
> > </types>
> > <interface name="customerService">
> >  <operation name="reserveCar">
> >   <input element="myNS:reserveCarRequest">
> >    <property uri="http://www.w3.org/@@@@/@@/features/AD/data">
> >     <constraint xmlns:foo="http://foo">
> >      foo:myDataType
> >     </constraint>
> >    </property>
> >   </input>
> >  </operation>
> > </interface>
> > 
> > This example defines two pieces of application data, and 
> > associates them with the input message of the "reserveCar" 
> > operation.  Notice that the "promotionalCode" element is 
> > optional (minOccurs="0"), and that the "isGoldClubMember" 
> > element has fixed the value of the SOAP 1.2 "mustUnderstand" 
> > element to "true".
> > 
> > 
> > 
> > = Application Data Module =
> > 
> > This module is identified with the URI
> > http://www.w3.org/@@@@/@@/modules/AD
> > 
> > == Features Implemented ==
> > 
> > This module implements the feature
> > http://www.w3.org/@@@@/@@/features/AD.
> > 
> > == Operation ==
> > 
> > This module specifies how to transmit "out of band" 
> > application data, as defined in the Application Data feature, 
> > as SOAP headers.
> > 
> > As a SOAP sender, if the property
> > http://www.w3.org/@@@@/@@/features/AD/data has a value then 
> > each of the top-level child element information items in the 
> > value SHOULD [ed:
> > MUST?] be turned into a SOAP header.  The elements are 
> > serialized according to their schemas, which might include 
> > the SOAP "mustUnderstand" or "role" attributes, which will 
> > have the usual meaning in the resultant headers.  SOAP 
> > senders SHOULD also add an additional header, with namespace 
> > "http://www.w3.org/@@@@/@@/modules/AD" and local name 
> > "dataHeaders" - this header contains a list of element 
> > QNames, one for each application data header created in the 
> > first step.
> > 
> > It is the responsibility of the receiving node to determine 
> > which, if any, SOAP headers will populate the 
> > http://www.w3.org/@@@@/@@/features/AD/data property.  
> > Typically this will be accomplished via using some metadata, 
> > such as an understanding of a <constraint> specified in WSDL, 
> > or out-of-band agreements.  If the "dataHeaders" SOAP header 
> > (described above) is present, the QNames inside that header 
> > indicate which other headers are application data.
> > The contents of each SOAP header identified as application 
> > data will be placed in a child element of the data property 
> > [ed: should we define a particular "wrapper" element here as 
> > the top level one?].
> > 
> > 
> > === The following gets added to the HTTP binding === 
> > 
> > == Features Implemented ==
> > 
> > The HTTP binding implements the feature
> > http://www.w3.org/@@@@/@@/features/AD.
> > 
> > = Operation = 
> > 
> > This section specifies how to transmit "out of band" 
> > application data, defined in the Application Data feature, as 
> > HTTP headers.
> > 
> > As an HTTP sender, if the property
> > http://www.w3.org/@@@@/@@/features/AD/data has a value then 
> > each of the top-level child element information items 
> > indicates a possible element information item that SHOULD [ed:
> > MUST?] be turned into an HTTP header.  The http header name 
> > is serialized from the element information item local name.  
> > The http header content is serialized from the element 
> > information item value.
> > The data elements should only be "xs:string" type, including 
> > xs:anyURI.
> > Any attributes on data elements are ignored.
> > Any complex data types are ignored.  Where the element 
> > information item contains content that cannot be directly 
> > encoded per the HTTP specification, it MUST be escaped.
> > 
> > It is the responsibility of the receiving node to determine 
> > which, if any, HTTP headers will populate the 
> > http://www.w3.org/@@@@/@@/features/AD/data property.  
> > Typically this will be accomplished via using some metadata, 
> > such as an understanding of a <constraint> specified in WSDL, 
> > or out-of-band agreements.  The contents of each such HTTP 
> > header will be placed in a child element of the data property 
> > [should we define a particular "wrapper" element here as the 
> > top level one?].  Each child element information item is 
> > generated by using the http header name as the element 
> > information item local name [ed: should we define a 
> > particular namespace?] and the http header value as the 
> > element information item value.  Where the HTTP header 
> > contains content that cannot be directly encoded in the 
> > element information item, it MUST be escaped.
> > 
> > [ed: any discussion about escaping rules?]
> > 
> > 
> > 
> 
>

Received on Tuesday, 29 June 2004 10:15:56 UTC