@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?)
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 ?

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? 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) ?

In the case of the soap protocol, serialization seems obvious: @headers 
map to soap header blocks. 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
    - Use the value of each element pointed by @headers as the http 
header value
Is this the correct proposal?
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
       - 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)
          - the only solution (?)  is then to have another operation 
<output body="bodyData2"> bodyData2 being the aggregation of bodyData 
and headerData.
          => we loose some reusability of the operation construct which 
was possible before with the part construct :-(
To conclude:
    - what are the difference between @headers data and @body data at 
the application level ?
    - is @headers really needed ?
    - if @headers is needed, shouldn't this attribute point to a unique 
aggregation type (today it is a list of types)?
    - Do we really loose reusability of the abstract operation construct 
having both a @body and @header attributes?

Bye,
    Youenn

Received on Wednesday, 10 September 2003 04:10:02 UTC