RE: HTTP binding: HTTP Header component's {element} property's declaration

Thanks for your comment.  The WS Description Working Group tracked this
as a Last Call comment LC315 [1].  The Working Group agreed to fix the
problem by adopting your proposal 1 with the following amendments:

 - make it clear that the types are restricted to simple types

 - make it clear there are no angle brackets in the value (e.g. use
lexical representation) 

 - include the description of how to make a HTTP name (Jacek's email at
http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/0017.html) and
put that in our schema 

 - for the value of the header reference the HTTP specs and say that
this has to be followed (e.g. line length, escaping).

If we don't hear otherwise within two weeks, we will assume this
satisfies your concern.

[1] http://www.w3.org/2002/ws/desc/5/lc-issues/issues.html#LC315

> -----Original Message-----
> From: public-ws-desc-comments-request@w3.org [mailto:public-ws-desc-
> comments-request@w3.org] On Behalf Of Hugo Haas
> Sent: Wednesday, August 24, 2005 3:11 AM
> To: public-ws-desc-comments@w3.org
> Subject: HTTP binding: HTTP Header component's {element} property's
> declaration
> 
> There are two comments about the definition of the {element} property
> of a HTTP Header component.
> 
> == Error on types not allowed ==
> 
> In Part 2, section 6.3 Default Binding Rules reads:
> 
>      * HTTP Header Construction. If the {http headers} property as
> defined
>        in section 5.10 Declaring SOAP Header Blocks exists and is not
> empty
>        in a Binding Message Reference or Binding Fault component,
> element
>        information item conforming to the element declaration of a
> HTTP
>        Header component's {element} property, in the {http headers}
>        property, MUST be turned into a HTTP header for the
> corresponding
>        message.
> 
>        Only element information items of type xs:string or xs:anyURI
> may be
>        serialized. All complex data types are ignored. Attributes on
> data
>        elements are ignored.
> 
>        Each such element information item is serialized as follows:
> 
> First, the reference should be 6.7 Declaring HTTP Headers and not 5.10
> Declaring SOAP Header Blocks
> 
> Second, as we cannot serialize certain types of data, we shouldn't
> encourage declaring HTTP header using an element that cannot be
> used. We usually try to raised errors when we know there's a problem,
> and we are not doing so here.
> 
> I therefore propose this new text for section 6.3 Default Binding
> Rules:
> 
>   HTTP Header Construction.
> 
>     If the {http headers} property as defined in section 6.7 Declaring
>     HTTP Headers exists and is not empty in a Binding Message
>     Reference or Binding Fault component, HTTP headers conforming to
>     the {element} property of each HTTP Header component present MUST
>     be serialized as follows:
> 
>     [ Keep the two existing rules here and add a following third one ]
> 
>       * Attributes on the instance data element are ignored.
> 
> and to replace the current text in section 6.7 about the definition of
> {element}:
> 
>      * {element}, REQUIRED. A xs:QName, a reference to an XML element
>        declaration in the {element declarations} property of the
> Description
>        component. This element represents a HTTP header.
> 
> the following:
> 
>   {element}, REQUIRED.
> 
>     A xs:QName, a reference to an XML element declaration in the
>     {element declarations} property of the Description component. This
>     element represents a HTTP header. The element information item
>     declared MUST be of the type xs:string or xs:anyURI.
> 
> == Types allowed ==
> 
> We restricted the serialization to xs:string or xs:anyURI.
> 
> 1. What about types derived from xs:string, e.g. xs:token? How about
>    allowing:
> 
>       "type xs:string or xs:anyURI, or of a derived type using those
> as a
>       base type definition."
> 
> 2. Any reason for not allowing xs:int?
> 
> --
> Hugo Haas - W3C
> mailto:hugo@w3.org - http://www.w3.org/People/Hugo/

Received on Wednesday, 5 October 2005 20:39:46 UTC