W3C home > Mailing lists > Public > www-ws-desc@w3.org > June 2004

RE: Application Data Feature and related stuff

From: Glen Daniels <gdaniels@sonicsoftware.com>
Date: Tue, 29 Jun 2004 13:35:30 -0400
Message-ID: <80A43FC052CE3949A327527DCD5D6B274D8F29@MAIL01.bedford.progress.com>
To: <paul.downey@bt.com>, <sanjiva@watson.ibm.com>, <asirv@webmethods.com>, <dorchard@bea.com>, <www-ws-desc@w3.org>


Hi folks!

Paul sez:
> because it was an abstract mustUnderstand feature defined by 
> WSDL although modelled on SOAP 1.2. This is a generic concept 
> i imagined could be shared by SOAP 1.1, 1.2 and possibly 
> other bindings. 
> 
> i was obviously wrong :-) 

No, you're not wrong at all.  But actually, it's not so much defined by
WSDL as it is defined by the AD feature.  Therefore, Sanjiva's question
about the WSDL namespace is well-taken.  I'd propose we change it to
ad:mustUnderstand....

That said, on to the meaty stuff.  First, a little background here.  I
originally argued (and still believe, though I'm fine with the
compromise we have now) that additional data should in fact be carried
in SOAP within a *single* AD header which makes it very clear that a)
the contents are application/additional data (thus removing the need for
the separate header listing the QNames), and b) the semantics are
crisply defined as "a bag of data that moves through the SOAP message
path to the application" instead of potentially causing nodes to do
things with headers that they don't really understand.  As such, I
didn't see a need for things like mustUnderstand or role on the
individual bits of data at all - they'd just be in the "cookie bag" and
would be plucked out by anyone who wanted to use them.  Yaron and Dave
argued strongly in favor of both setting individual headers and for
allowing the user to specify mustUnderstand and roles.  So we wanted to
do that in a way that would be as friendly as possible.

Once you decide you want to go there, I think a decorator on the schema
is a great way to do it, just like we did with the acceptedMediaTypes
designator.  To Asir's question, this wouldn't affect the WSDL component
model at all, nor does it need to.

As for Dave's concerns about the differences in semantics between SOAP
1.1's MU and SOAP 1.2's MU, I don't really see this as an issue.  You'd
asked if there were cases where the different "views" come into
conflict, and I'll throw that back to you, Dave - can you think of any
cases where there would be a problem?

Thanks,
--Glen 

> 
> Paul
> 
> 
> 
> -----Original Message-----
> From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
> Sent: 29 June 2004 14:51
> To: Asir Vedamuthu; Downey,PS,Paul,XSJ67A C; 
> dorchard@bea.com; gdaniels@sonicsoftware.com; www-ws-desc@w3.org
> Subject: 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 13:35:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:31 GMT