RE: Application Data Feature and related stuff

Hi Asir!

> BTW, what is the rational for describing mU and role in a 
> WSDL document?

I think Dave and/or Yaron (if he's still listening) will likely pipe up
with an answer to this one. :)

--Glen

> Asir
> 
> -----Original Message-----
> From: David Orchard [mailto:dorchard@bea.com]
> Sent: Monday, June 28, 2004 5:43 PM
> To: Glen Daniels; paul.downey@bt.com; 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 13:38:34 UTC