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

RE: Application Data Feature and related stuff

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Wed, 7 Jul 2004 10:00:52 -0700
Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA2042B546A@RED-MSG-30.redmond.corp.microsoft.com>
To: "Glen Daniels" <gdaniels@sonicsoftware.com>, <paul.downey@bt.com>, <sanjiva@watson.ibm.com>, <asirv@webmethods.com>, <dorchard@bea.com>, <www-ws-desc@w3.org>

Can we clarify whether the AD proposal has accrued something from Paul's
suggestion as a friendly amendment?

> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]
On
> Behalf Of Glen Daniels
> Sent: Tuesday, June 29, 2004 10:36 AM
> To: paul.downey@bt.com; sanjiva@watson.ibm.com; asirv@webmethods.com;
> dorchard@bea.com; www-ws-desc@w3.org
> Subject: RE: Application Data Feature and related stuff
> 
> 
> 
> 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 Wednesday, 7 July 2004 13:01:21 GMT

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