RE: Application Data Feature and related stuff

Perhaps, it is easier to move this problem around. Say, binding:

<binding name="binding-4-customer-service" interface="customer-service">

  <property name="http://www.w3.org/@@@@/@@/features/AD/data"
        required="true" wsoap:mustUnderstand="true">
                        ++++===================++++
    <constraint>tns:some-out-of-band-data</constraint>
  </property>

  <operation ref="reserve-car">
   ...
  </operation>

</binding

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

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 08:39:47 UTC