Re: @headers in input/output construct

Before the @headers addition, it was as feasible as today to describe 
headers data in messages
The binding was the place to describe headers data. Why? Simply because 
in most cases, header data is protocol (and then binding) dependent. See 
the problem with operations boundable to sopa and not http binding...
The goal to put @headers at the abstract layer could be that this header 
data description would be reusable between bindings. But I doubt that it 
will be the case..
It seems to me that we can create operation descriptions that are 
boundable to only one specific binding much more easily than it was 
prior the @headers addition... the benefit of the @headers addition 
being a simplification of the soap binding... (plus some more ?)

    Youenn


See below for some clarifications

Jeffrey Schlimmer wrote:

>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.
>
ok, then what type of header data would it be? security, reliability, ?
Security and reliability seems protocol dependent to me. Adding this 
info at the abstract layer will then disable (at least make it hard) to 
bound this operation description to another binding than the natural one 
(i.e. soap)

>
>  
>
>>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?
>
WSDL1.1 allows that. This information (what goes where) was at the 
binding level. Now we have somewhat pushed that information at the 
abstract level, haven't we?

>
>  
>
>>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.
>
with @headers="list-of-qnames" you define a partial schema for the 
header open set. Basically the equivalent schema to the list of qnames 
would be something like:
    <all>
       <header1/>
       <header2/>
    </all>
The validation scheme would be that header data not defined in the 
schema should be skipped.
Now what if you want to have something like optionality:
    <choice>
       <header1/>
       <header2/>
    </choice>
With @headers="list-of-qnames", I do not see a way to describe this 
constraint.
Why not just pointing to the <choice> schema. Isn't it simpler ? What 
are the drawbacks ?

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

>
>  
>
>>    - Use the value of each element pointed by @headers as the http
>>header value
>>Is this the correct proposal?
>>    
>>
>
>Seems straightforward.
>
I do not see the clear relationship between http headers and soap 
headers that makes them similar enough to be bound to the same 
wsdl:@headers concept. For the moment, I believe that http and soap 
headers are different and should not be treated the same at the abstract 
layer. At the binding level they are not treated the same at all...

>
>  
>
>>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. 
>
IMO, by adding @headers we add some capabilities at the abstract layer 
which will make more binding unable to comply with some operation 
description. Before the addition of @headers, there were only one case, 
http get. Now this unboundable case will be much more common, which is a 
drawback of @headers . And I do not really see the benefit of @headers ...

>
>  
>
>>          - 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'.
>
I agree and we also loose the operation equivalence between the soap 
exchange and the http exchange... The point of this example is to say 
that to allow more than one protocol to be applicable to a particular 
operation, one should maybe not use @headers.

>
>  
>
>>          => we loose some reusability of the operation construct which
>>was possible before with the part construct :-(
>>    
>>
>
>Agreed. Do you see an alternative?
>
For the moment, one alternative is to not have a @headers at the 
abstract layer...
The other alternative is to put all data in the body and at the binding 
level, make the separation between header data and body data, for 
example using xpath expressions or simpler mechanisms...
Yes the bad point of this approach is to loose the cool body validation 
scheme....

>
>  
>
>>To conclude:
>>    - what are the difference between @headers data and @body data at
>>the application level ?
>>    
>>
>
>Perhaps that is out of scope for WSDL.
>
I think that at least there should be a place where we clearly state the 
motivation of separating @headers and @body data at the abstract layer. 
This motivation would then be helpful to define good practices for WSDL 
authoring. What do you think?

>
>  
>
>>    - is @headers really needed ?
>>    
>>
>
>Yes, if WSDL is to allow the description of such in messages.
>
Binding was playing this role and still plays this role (a little bit less)

>
>  
>
>>    - 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.
>
I hope that my example helps clarifying this point.

>
>  
>
>>    - 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.
>
Yes and @headers makes this case much more common

>
>  
>
>>Bye,
>>    Youenn
>>    
>>
>
>  
>