W3C home > Mailing lists > Public > www-ws-desc@w3.org > September 2005

LC315: proposal for HTTP Header component's {element} property declaration

From: Hugo Haas <hugo@w3.org>
Date: Wed, 21 Sep 2005 13:30:37 +0200
To: www-ws-desc@w3.org
Message-ID: <20050921113037.GE17618@w3.org>
I have taken an action to propose a resolution for issue LC315:

  LC315: HTTP binding: HTTP Header component's {element} property's
  declaration
  http://www.w3.org/2002/ws/desc/5/lc-issues/#LC315

Last week[1], the Working Group was leaning towards allowing simple
types only, and there was some momentum toward using a combination of
a simple type and a name property for declaring HTTP headers.

Also, there was a preference for disallowing attributes rather than
ignoring them. In this spirit, I think that we should not ignore, but
disallow headers that are not serializable in UTF-8.

Here are two proposals, as I still like the symmetry with
wsoap:header:

• Proposal 1: declaration with a type declaration

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
    each HTTP Header component present MUST be serialized as follows:

      o The HTTP header field name is the value of the {name} property
      of the HTTP Header component. If an HTTP header field
      corresponding to the element information item local name is set
      by a mechanism other than the HTTP binding, such as the HTTP
      stack or another feature, then an error MUST be raised.

      o The HTTP header field value, whose XML Schema type is declared
      by the {type} property of the HTTP Header component, is
      serialized in UTF-8. If this serialization in UTF-8 is NOT
      possible, then an error MUST be raised.

New text for section 6.7 Declaring HTTP Headers:

  {name}, REQUIRED.

    A xs:string, the name of the HTTP header field. The value of this
    property MUST follow the field-name production rules as specified
    in section 4.2 of [IETF RFC 2616].

  {type}, REQUIRED.

    A xs:QName, being a reference to a Type Definition component in
    the {type definitions} property of the Description component
    constraining the value of the HTTP header field.

• Proposal 2: declaration with an element declaration

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:

      o The HTTP header field name used is the element information
      item's local name. If an HTTP header corresponding to the
      element information item local name is set by a mechanism other
      than the HTTP binding, such as the HTTP stack or another
      feature, then an error MUST be raised.

      o The HTTP header field value is serialized from the
      corresponding element information item value in UTF-8. If this
      serialization in UTF-8 is NOT possible, then an error MUST be
      raised.

New text for section 6.7 Declaring HTTP Headers:

  {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 field. The type of the declared
    element information item declared MUST be a simple type. The local
    part of this xs:QName MUST follow the field-name production rules
    as specified in section 4.2 of [IETF RFC 2616].

Cheers,

Hugo

  1. http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/att-0018/20050915-ws-desc-minutes.html#item07
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/

Received on Wednesday, 21 September 2005 11:30:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:37 GMT