RE: @headers in input/output construct

Youenn, matière fascinate! Comments in-line. --Jeff

> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
> Behalf Of FABLET Youenn
> Sent: Wednesday, September 10, 2003 1:10 AM
> To: www-ws-desc@w3.org
> Subject: @headers in input/output construct
> 
> 
> At last f2f, we do not really go deep in the discussion of the addition
> of the @headers attribute (or did I miss some parts of the discussion).
> I have some questions and comment regarding this particular attribute.
> 
> First, I am not sure to understand what type of data to put in the
> @headers attribute. Because it is at the interface level, data pointed
> via @headers should be application data (right?)

Not necessarily. We may wish to let the distinction between application and system data be in the eyes of the beholder.

> But then, why not define this @headers application data within the @body
> data. Is it only for serialization matter ? In this case, the
> abstract/concrete layering seems a little bit broken ? Or is there some
> distinction between @headers (application) data and @body (application)
> data ?

We might want to make WSDL flexible in this regard.

> More generally, we get rid of the part construct and it seems to me that
> now, we have a special (@body) part and other (@headers) parts. If it is
> all application data, should not we just have a unique @body containing
> all application data? 

Why not leave it up to the WSDL author to decide which of the data they wish to exchange goes where?

> If @headers is really needed, shouldn't we
> refactor the whole @headers element lists in a unique type. This unique
> type being then able to express multiplicity, optionality,
> cooccurence... rules of headers (same pb as expressed with the part
> construct) ?

I don't understand this. One distinction between the body and headers is that the headers is an open set -- the message may contain headers that are not explicitly listed.

> In the case of the soap protocol, serialization seems obvious: @headers
> map to soap header blocks.

Agreed.

> In the case of the http binding, however this
> seems not that obvious. One could say that @headers can map to http
> headers but then how would take place the real mapping ? The proposal
> was if I remember correctly:
>     -  Use the qname of each element pointed by  @headers as the http
> header key

The name of the HTTP header?

>     - Use the value of each element pointed by @headers as the http
> header value
> Is this the correct proposal?

Seems straightforward.

> Personaly, I find this a little bit odd as we are serializing
> xml/xsd-typed data in an unusual way.
> 
> Last comment, using the following example:
>     - a web service W has two binding: an http and a soap binding
>     - web service W wants to send a complex xml @body data and a complex
> xml @header data with both bindings

I do not expect that all messages can be bound with all bindings. If @body points to a GED with nested elements, it won't be serializable in an HTTP GET.
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/issues/wsd-issues.html#x6a

>        - with the soap binding, it can describe the abstract operation
> using a simple and cool way :-)
>                             <output body="bodyData" headers="headerData">
>        - with the http binding, it cannot reuse (?) this abstract
> description because it won't be able to serialize "headerData" as an
> http header (it is complex xml data)

Agreed. The decoupling of the abstract interface and the concrete binding, while much, much better in WSDL 1.2 still shows through when one tries to exercise capabilities of a given binding. 

>           - the only solution (?)  is then to have another operation
> <output body="bodyData2"> bodyData2 being the aggregation of bodyData
> and headerData.

It might be odd to allow a binding to bind only some of the operations in an interface; the current SOAP binding assumes that all of the operations are bound. This is key to the attribute 'roll up'.

>           => we loose some reusability of the operation construct which
> was possible before with the part construct :-(

Agreed. Do you see an alternative?

> To conclude:
>     - what are the difference between @headers data and @body data at
> the application level ?

Perhaps that is out of scope for WSDL.

>     - is @headers really needed ?

Yes, if WSDL is to allow the description of such in messages.

>     - if @headers is needed, shouldn't this attribute point to a unique
> aggregation type (today it is a list of types)?

I don't understand this.

>     - Do we really loose reusability of the abstract operation construct
> having both a @body and @header attributes?

We lose reusability of operations when we create one that cannot be realized with a specific binding.

> Bye,
>     Youenn

Received on Sunday, 21 September 2003 00:33:09 UTC