Re: Application Data Feature and related stuff

And why is it in the wsdl: namespace at all?

Sanjiva.

----- Original Message ----- 
From: "Asir Vedamuthu" <asirv@webmethods.com>
To: <paul.downey@bt.com>; <dorchard@bea.com>; <gdaniels@sonicsoftware.com>;
"Asir Vedamuthu" <asirv@webmethods.com>; <www-ws-desc@w3.org>
Sent: Tuesday, June 29, 2004 7:37 PM
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 09:51:53 UTC