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

Regarding the questions on xs:int and derived types, I took an action to
scribe an alternate proposal that emerged during the call.  The gist of
that discussion was that there does not appear to be a compelling reason
for the current limits to xs:string and xs:anyURI.  Derived types,
numeric types, even QNames (though you'd need some out-of-band mechanism
to map the prefix) seem workable.

Hugo's proposal accommodates this well, except where it states:
  "The element information item declared MUST be of the type xs:string
  or xs:anyURI."

Which would become:
  "The element information item MUST be declared as having simple 
  content."

Note: Since we seem to generally be ignoring stuff we don't directly
care about (attributes, non-UTF-8, etc.) maybe we should just be
collecting character infoitems (incl from descendents) rather than
tossing the whole element.  E.g. <p>This is the <b>header</b></p> could
be serialized as "This is the header" rather than just tossed
completely.  Tossing internal structure seems similar to tossing
attributes, but maybe that's my XSLT roots showing...

-----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 Thursday, 8 September 2005 21:33:54 UTC