WSDL 2.0 Second Last Call Issues List

LC300: Infoset refs [link to this issue]

Editorial: Primer | SOAP 1.1 Binding

In the Primer and SOAP 1.1 Binding, the bib ref to the Infoset points to
the original publication.  Core and Adjuncts both correctly point to the
2nd edition.  Request the entries consistently point to 2nd edition.

Transition history

raised on 4 Aug 2005 by Jonathan Marsh (jmarsh@microsoft.com)

agreed on 1 Sep 2005

Accepted.

Acknowledgment cycle

announced by group on 15 Sep 2005

Action history

LC301: {soap action} granularity [link to this issue]

Comment on:

  Web Services Description Language (WSDL) Version 2.0 Part 2:
  Adjuncts
  http://www.w3.org/TR/2005/WD-wsdl20-adjuncts-20050803/

and:

  Web Services Description Language (WSDL) Version 2.0 SOAP 1.1
  Binding
  http://www.w3.org/TR/2005/WD-wsdl20-soap11-binding-20050803/

{soap action} is defined as a property of Binding Operation
component[4]:

     {soap action} OPTIONAL. A xs:anyURI, which is an absolute IRI as
     defined by [IETF RFC 3987], to the Binding Operation component.
     The value of this property identifies the value of the SOAP
     Action Feature (as defined for this specific operation), as
     specified in the binding rules of bindings to specific versions
     of SOAP (see 5.11.3 Default Binding Rules for the SOAP 1.2
     binding when the value of the {soap version} property of the
     Binding component is "1.2").

The SOAP 1.2 binding states[5]:

     SOAP Action Feature. If a value for the {soap action} property of
     a Binding Operation component has NOT been specified then the
     SOAP Action Feature (see [SOAP 1.2 Part 2: Adjuncts]) has NO
     value assigned by the Binding component. Otherwise, the value of
     the {soap action} property of a Binding Operation component is
     the value of the SOAP Action Feature for all messages of the
     corresponding Interface Operation component.

The SOAP 1.1 binding states[6]:

    The value of the {soap action} property identifies the value of
    the SOAP 1.1 SOAPAction HTTP request header field, Section 6.1.1,
    SOAP 1.1 specification [SOAP11].

I believe that this is the wrong granularity. The SOAPAction HTTP
header in SOAP 1.1[1] and the SOAP Action Feature in SOAP 1.2[2] are
properties of a message. It is unclear, as shown by WS-Addressing and
its wsa:Action[3] which has similar properties and motivations, that a
single action value can be applied to all the messages of an
operation in all cases.

I propose the following change: place {soap action} at the Binding
Message Reference, Binding Fault and Binding Fault Reference levels.

Editorially, I think the cleanest way is:
- remove the definition of {soap action} from section 5.8 Binding
  Operations
- add a subsection called "5.9 Assigning SOAP Action values to
  Messages" defining the {soap action} property on the Binding Message
  Reference, Binding Fault and Binding Fault Reference components
- say in the SOAP 1.2 binding that the value of {soap action} sets the
  value of the SOAP Action Feature of the corresponding SOAP message
  or fault
- say in the SOAP 1.1 binding that the value of {soap action} sets the
  value of the SOAPAction HTTP header for an HTTP Request; say that it
  MUST be ignored in other cases (it's not explicitly said right now)

As a related editorial side note, the SOAP 1.1 binding also says[7]:

    SOAP Action. If the Binding Operation component's {soap action}
    property has NOT been specified, then the Binding component
    assigns quoted string value to the SOAP 1.1 SOAPAction HTTP Header
    Field (see [SOAP11]).

I assume that "quoted string" means "an quoted empty string ("")". If
not, I don't know what it means. It should be clarified.

  1. http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383528
  2. http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#ActionFeature
  3. http://www.w3.org/TR/2005/WD-ws-addr-wsdl-20050413/#explicitaction
  4. http://www.w3.org/TR/2005/WD-wsdl20-adjuncts-20050803/#property-BindingOperation.soapaction
  5. http://www.w3.org/TR/2005/WD-wsdl20-adjuncts-20050803/#soap12-defaults
  6. http://www.w3.org/TR/2005/WD-wsdl20-soap11-binding-20050803/#SOAP11
  7. http://www.w3.org/TR/2005/WD-wsdl20-soap11-binding-20050803/#soap11-defaults

Transition history

raised on 5 Aug 2005 by Hugo Haas (hugo@w3.org)

declined on 27 Oct 2005

WG consensus was to leave soapaction where it is, clarifying that it only applies to the first message in an exchange pattern.

Acknowledgment cycle

announced by group on 3 Nov 2005

Action history

LC302: URI comparison reference [link to this issue]

Section 2.20 Comparing URIs and IRIs in Part 1 references:

  [TAG URI FINDING]
      TAG Finding on URI Comparison, X. Foo, Y. Bar, Authors. W3C
      Technical Architecture Group, Month, Year. Draft available at
      http://www.textuality.com/tag/uri-comp-4.

This is a draft TAG finding, whose content is mainly identical to the
IRI spec's Simple String Comparison section, which is a much more
stable document.

Therefore, I would like us to use section 5.3.1. Simple String
Comparison of RFC 3987 as the normative way to compare IRIs in WSDL
2.0 documents.

Transition history

raised on 5 Aug 2005 by Hugo Haas (hugo@w3.org)

agreed on 1 Sep 2005

Accepted.

Acknowledgment cycle

announced by group on 15 Sep 2005

Action history

LC303: Mention IRIs in the primer [link to this issue]

Comment about:

  Web Services Description Language (WSDL) Version 2.0 Part 0: Primer
  http://www.w3.org/TR/2005/WD-wsdl20-primer-20050803/

The primer talks exclusively about URIs. It should talk about IRIs
some. The primer is probably a good place to mention that for
internationalization purposes, WSDL 2.0 supports IRIs which are a
superset of URIs.

It might be useful to point to An Introduction to Multilingual Web
Addresses[1] which explains what IRIs are, how they differ from URIs,
why they exist, etc.

  1. http://www.w3.org/International/articles/idn-and-iri/

Transition history

raised on 5 Aug 2005 by Hugo Haas (hugo@w3.org)

agreed on 22 Sep 2005

Proposal and amendmentaccepted, in a new subsection.

Acknowledgment cycle

announced by group on 5 Oct 2005

Action history

LC304: Definition of a IANA media type token [link to this issue]

Part 2 uses the concept of "IANA media type token"[1], but does not
define by value nor reference what it is exactly: a media type? a
media type with some parameters? As far as I can tell, or more
precisely as far as Google can tell, we are the only ones using this
denomination.

We should clarify this concept.

I believe that what we mean is:

  The 'type "/" subtype' production as defined in section 5.1. Syntax
  of the Content-Type Header Field of RFC 2045 Multipurpose Internet
  Mail Extensions (MIME) Part One: Format of Internet Message Bodies.

Reading this section, the media type is not necessarily registered
with IANA, so I would suggest changing the name to "media type token".

Note that this proposal deliberately leaves out the possibility of
using parameters, which I think is fine and is what we were after.

Cheers,

Hugo

  1. http://www.w3.org/TR/2005/WD-wsdl20-adjuncts-20050803/#http-operation-decl-relate
						

Transition history

raised on 18 Aug 2005 by Hugo Haas (hugo@w3.org)

agreed on 10 Nov 2005

Implement proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2005Oct/0063.html.

Acknowledgment cycle

announced by group on 14 Nov 2005

Action history

LC305: Notational conventions [link to this issue]

The WS-A WG has added a statement "Pseudo schemas do not include
extensibility points for brevity" to their notational conventions [1].
Except for that new statement, that text is identical to ours [2]. I
believe it would be beneficial to add the statement to our notational
conventions section(s) as well.

I propose this be treated editorial and done prior to LC publication.
But if it doesn't happen we'll track it as an editorial issue during the
next LC.

[1]
http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-core.html
?content-type=text/html;%20charset=utf-8#notation
[2]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html#bnfp
seudoschemas
						

Transition history

raised on 26 Jul 2005 by Jonathan Marsh (jmarsh@microsoft.com)

agreed on 15 Sep 2005

Proposal adopted.

Acknowledgment cycle

announced by group on 15 Sep 2005

Action history

LC306: Definition of the wsdlx namespace [link to this issue]

This is an editorial comment which impacts both Part 1 and 2.

Part 1 says:

   wsdlx                                                                       
                                                                               
           "http://www.w3.org/2005/08/wsdl-extensions"                         
                                                                               
           Defined by this specification 3.3 Describing Messages that Refer    
           to Services and Endpoints.                                          

Actually, only part of wsdlx is defined in this section, @wsdlx:safe
being defined in Part 2.

In Part 2, Table 1-1 lists a "wsdl-x" prefix. This should be "wsdlx".

Transition history

raised on 22 Aug 2005 by Hugo Haas (hugo@w3.org)

agreed on 1 Sep 2005

wsdlx is defined in Core, extended in Adjuncts. Editorial clarifications as necessary to explain this will be made. Hyphen removed as well.

Acknowledgment cycle

announced by group on 15 Sep 2005

Action history

LC307: Description's {type definitions} mapping [link to this issue]

In Part 1, section 2.1.3 Mapping Description's XML Representation to
Component Properties reads:

  {type definitions} 	

  The set of Type Definition components corresponding to all the type
  definitions defined as descendants of the types element information
  item, if any, plus any (via xs:include) or imported (via xs:import)
  Type Definition components. At a minimum this will include all the
  global type definitions defined by XML Schema simpleType and
  complexType element information items. It MAY also include any
  definitions from some other type system which describes the
  [attributes] and [children] properties of an element information
  item. It is an error if there are multiple type definitions for each
  QName.

Why are simpleType and complexType called out here, and not element
for example?

I propose simplifying the second sentence:

  At a minimum this will include all the global definitions defined by
  XML Schema declarations.

Transition history

raised on 23 Aug 2005 by Hugo Haas (hugo@w3.org)

declined on 1 Sep 2005

Closed with no action (withdrawn).

Acknowledgment cycle

announced by group on 15 Sep 2005

LC308: Identification of an interface operation [link to this issue]

This is an editorial comment about Part 1.

Section 2.4.1 The Interface Operation Component states:

   Note:

   Despite having a {name} property, Interface Operation components cannot
   be identified solely by their QName. Indeed, two Interface components
   whose {name} property value has the same namespace name, but different
   local names, can contain Interface Operation components with the same
   {name} property value. Thus, the {name} property of Interface Operation
   components is not sufficient to form the unique identity of an Interface
   Operation component.

Since we're going through the effort of saying that you can't use
QNames to identify operations, we should add a reference to our
definition of fragment identifiers for WSDL documents, and more
specifically to appendix A.2.6 The Interface Operation Component.

Transition history

raised on 23 Aug 2005 by Hugo Haas (hugo@w3.org)

agreed on 1 Sep 2005

Accept in this case, and any other similar cases.

Acknowledgment cycle

announced by group on 15 Sep 2005

Action history

LC309: Incomplete list of operation styles in Part 1 [link to this issue]

Section 2.4.1.1 Operation Style in Part 1 states:

   The WSDL Version 2.0 Part 2: Adjuncts specification [WSDL 2.0 Adjuncts]
   defines the following operation style:

     * RPC Style

Part 2 actually defines 3 styles. Either we should list them all, or
we should make a more general reference to Part 2 containing
predefined styles.

Transition history

raised on 23 Aug 2005 by Hugo Haas (hugo@w3.org)

agreed on 1 Sep 2005

Accept a general reference rather than a list.

Acknowledgment cycle

announced by group on 15 Sep 2005

Action history

LC310: Part 1: use of ws namespace prefix [link to this issue]

Editorial: Part 1 uses a ws namespace prefix, apparently mainly for
ws:import, which is not defined anywhere.

Transition history

raised on 23 Aug 2005 by Hugo Haas (hugo@w3.org)

agreed on 1 Sep 2005

Accept removal of "ws:" prefix and make sure each use of import is clear in scope (section 4.2, elsewhere).

Acknowledgment cycle

announced by group on 15 Sep 2005

Action history

LC311: What is the extension type system URI? [link to this issue]

In Part 1, in section A.2.2 The Element Declaration Component, we can
read:

    A.2.2 The Element Declaration Component

   wsdl.elementDeclaration(element)

   wsdl.elementDeclaration(element,system)

    1. element is the {name} property of the Element Declaration component.

    2. system is the absolute URI of the extension type system used for the
       Element Declaration component. This parameter is absent if XML Schema
       is the type system.

Note that a similar statement is done in section A.2.3 The Type
Definition Component.

Two comments:
- what's the system URI?
- why is it a URI and not an IRI?

I am confused about this system absolute URI. Where is it coming from?
Can we provide an example of a value when XML Schema is not in use?

Let's take our example of use of Relax NG or DTDs in Discussion of
Alternative Schema Languages and Type System Support in WSDL 2.0[1]. I
don't believe that we've defined such a URI.

I understand this to mean that if you use something else then XML
Schema for element or type definition, you need to provide a URI (BTW,
why not an IRI?) for identification with the fragment identifiers.

This needs to be clarified.

  1. http://www.w3.org/TR/2005/NOTE-wsdl20-altschemalangs-20050817/

Transition history

raised on 23 Aug 2005 by Hugo Haas (hugo@w3.org)

agreed on 1 Sep 2005

Add clarification that the URI for the extension is the namespace URI, and this URI can be an IRI.

Acknowledgment cycle

announced by group on 15 Sep 2005

Action history

LC312: Predefined MEPs: typo in the definition [link to this issue]

This in an editorial comment.

Section 2. Predefined Message Exchange Patterns states:

  Web Services Description Language (WSDL) message exchange patterns
  (hereafter simply 'patterns') define the sequence and of abstract
  messages listed in an operation.

This should be "sequence and cardinality".

Transition history

raised on 24 Aug 2005 by Hugo Haas (hugo@w3.org)

agreed on 1 Sep 2005

Accepted.

Acknowledgment cycle

announced by group on 15 Sep 2005

Action history

LC313: Part 2: Mapping from XML Representations to Component Properties [link to this issue]

A number of properties in Part 2 are optional, but their mapping from
XML says "otherwise empty", which means that that they would always be
present, but sometimes empty, which is different from not being
present.

I am proposing to remove this "otherwise empty" from the mapping for
the following properties to make them really optional:
- {soap fault subcodes}
- {soap action}
- {http location}
- {http error reason phrase}
- {http transfer coding}

This would mean replacing certain "if empty" in their definition by
"if not present".

{soap fault code} and {http error status code} suffer from the
same problem but should not as I mentioned in another issue I have
raised.

Transition history

raised on 24 Aug 2005 by Hugo Haas (hugo@w3.org)

agreed on 1 Sep 2005

Accepted.

Acknowledgment cycle

announced by group on 15 Sep 2005

Action history

LC314: Part 2: introduction is incomplete [link to this issue]

This is an editorial comment. Part 2's introduction gives an overview
of the document, but doesn't list section 3.

This should be fixed.

Transition history

raised on 24 Aug 2005 by Hugo Haas (hugo@w3.org)

agreed on 1 Sep 2005

Accepted.

Acknowledgment cycle

announced by group on 15 Sep 2005

Action history

LC315: HTTP binding: HTTP Header component's {element} property's declaration [link to this issue]

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?

Transition history

raised on 24 Aug 2005 by Hugo Haas (hugo@w3.org)

agreed on 26 Sep 2005

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

Acknowledgment cycle

announced by group on 5 Oct 2005

Action history

LC316: RPC style: an example defines a type [link to this issue]

This is an editorial comment.

Section 4.1.2 XML Representation of the wrpc:signature Extension in
Part 2 states:

  See Example 4-1 for a definition of this type.

We should change the mark-up as this is peculiar for an example to
define something in the spec.

Transition history

raised on 24 Aug 2005 by Hugo Haas (hugo@w3.org)

agreed on 1 Sep 2005

Add the wrpc namespace to table 1-1; in section 4.1.2, insert "excerpt" to clarify that this is not the full normative description.

Acknowledgment cycle

announced by group on 15 Sep 2005

Action history

LC317: HTTP binding: Misalignment between IRI style and application/x-www-form-urlencoded serialization, and between Multipart style and multipart/form-data serialization [link to this issue]

In our previous last call, we went back and forth about the design of
the operation style (applying to an operation or a message?) and the
generality of the URI and Multipart styles (limited to in-out or
not?).

I am afraid that we ended up in a situation which isn't bulletproof.
However, it should be fairly simple to fix it.

== Issue ==

The IRI style, like all styles, applies to an operation. We made it
constrain the first message of the MEP in use in order not to
constrain it to in-out, in-only and robust-only unnecessarily in case
somebody wants to use it for say an out-in operation.

This constraint expressed in this style is for use for a serialization
as an IRI of the instance data, by the
application/x-www-form-urlencoded serialization. However, this
serialization talks about serializing an input message (section 6.9.1
Serialization as "application/x-www-form-urlencoded"):

  This serialization format is designed to allow a Web service to
  produce a IRI based on the instance data of input messages. It may
  only be used for interface operation using the IRI Style format as
  defined in 4.2 IRI Style.

With the current specification, you could use the IRI style an a
out-in operation, which would constrain the first message, the output
message, and use the application/x-www-form-urlencoded serialization
on the second message, the input message, which is not constrained
by our IRI style. This is broken.

The application/x-www-form-urlencoded can be used only for the
messages that are constrained by the IRI style, i.e. only for the
first message of an operation.

As a side note, I don't think that we mean to say limit the
serialization to a Web service; we should say "Web service or client".

== Proposal ==

Here is some new proposed text for section 6.9.1:

  This serialization format is designed to allow a client or Web
  service to produce an IRI based on the instance data of a message.
  It may only be used when binding Interface Operation components
  using the IRI Style format as defined in 4.2 IRI Style, i.e. this
  serialization format may only be used to serialize the initial
  message of an interface operation.

  Specifically, for the HTTP binding defined in this section (6. WSDL
  HTTP Binding Extension), "application/x-www-form-urlencoded" MAY be
  used as a value for the {http input serialization} property of the
  Binding Operation component, but MUST NOT be used as a value as a
  value for the {http output serialization} or {http fault
  serialization} properties.

And add the following to Table 6-3. Mapping from XML
Representation to Binding Operation component Extension Properties to
note that it's an error for {http output serialization} or {http
fault serialization} to use this value:

  {http output serialization}

     The actual value of the whttp:outputSerialization attribute
     information item, if present; otherwise, the default value as
     defined in 6.3 Default Binding Rules, computed based on the value
     of the {http method} property. It is an ERROR for this property
     to have the value "application/x-www-form-urlencoded" (see
     section 6.9.1 Serialization as
     "application/x-www-form-urlencoded").

  {http fault serialization}

     The actual value of the whttp:faultSerialization attribute
     information item, if present; otherwise "application/xml". It is
     an ERROR for this property to have the value
     "application/x-www-form-urlencoded" (see section 6.9.1
     Serialization as "application/x-www-form-urlencoded").

== Similar issue ==

A similar issue exists in section 6.9.3 Serialization as
"multipart/form-data", and similar text should fix the problem.

Transition history

raised on 24 Aug 2005 by Hugo Haas (hugo@w3.org)

agreed on 8 Sep 2005

Proposal accepted.

Acknowledgment cycle

announced by group on 15 Sep 2005

Action history

LC318: SOAP and HTTP bindings: Editorial reorganization for defaults [link to this issue]

Defaults in the bindings are inconsistently defined.

The bindings have:
- a default binding rules section:
  5. WSDL SOAP Binding Extension
     5.3 Default Binding Rules
  6. WSDL HTTP Binding Extension
     6.3 Default Binding Rules
- sections for other defaults:
     5.6 Specifying the Default SOAP MEP
     6.5 Specifying the Default HTTP Method
- other sections defining their own defaults:
     6.6 Binding Operations
       (defines queryParameterSeparatorDefault)
     6.10 Specifying the Transfer Coding
       (defines transferCodingDefault)

I would like to propose to have each @foobarDefault consistently
defined in its own subsection under 5.3 Default Binding Rules and 6.3
Default Binding Rules, or have them consistently defined in the
section where they're used for determining the value of a property
(like sections 6.6 or 6.10).

I prefer those two proposed solutions to having them as subsections of
the the binding definition (like 5.6 and 6.5) as I believe that it
gives as much important to setting a default, which does not directly
impact the component, as to say binding an operation, which is much
more substantial.

Transition history

raised on 24 Aug 2005 by Hugo Haas (hugo@w3.org)

agreed on 15 Sep 2005

Reorganize sections with *default attributes, using 6.10 as a model of excellence.

Acknowledgment cycle

announced by group on 15 Sep 2005

Action history

LC319: SOAP and HTTP binding: definition of {soap fault code} and wsoap:code [link to this issue]

This is an issue which has already been addressed (LC130[1]) and
editorially implemented incorrectly.

It therefore is editorial. Details follow.

Part 2's section 5.7 Binding Faults defines:

     * {soap fault code} OPTIONAL. A xs:QName, to the Binding Fault
       component. The value of this property identifies a possible SOAP
       fault for the operations in scope. If this property is empty, no
       assertion is made about the value of the SOAP fault code.

[...]

     * wsoap:code OPTIONAL attribute information item

          * A [local name] of code

          * A [namespace name] of "http://www.w3.org/2005/08/wsdl/soap"

          * A type of union of xs:QName and xs:token where the allowed token
            value is "#any"

[...]

   ┌───────────────────────┬───────────────────────────────────────────────┐
   │       Property        │                     Value                     │
   ├───────────────────────┼───────────────────────────────────────────────┤
   │                       │ The actual value of the code attribute        │
   │ {soap fault code}     │ information item if present and if its value  │
   │                       │ is not "#any"; otherwise empty.               │
   ├───────────────────────┼───────────────────────────────────────────────┤

Why do we need "#any" as a possible value if the wsoap:code attribute
is optional?

It turns out that the resolution to LC130 was not properly
implemented:

* Jonathan Marsh <jmarsh@microsoft.com> [2005-06-04 01:08-0700]
>   Issue LC130: Binding fault defaulting?
>     RESOLUTION: wsoap:subcode and wsoap:code will be optional,
>               wsoap:subcode and wsoap:code will allow #any as a token,
>               missing attribute will map to #any in the component model,
>               #any => no assertion is made about the value,
>               http:code will be similarly modified.

-- http://lists.w3.org/Archives/Public/www-ws-desc/2005Jun/0003

wsoap:subcode, wsoap:code and whttp:code need to be revised to reflect
the correct resolution of LC130.

  1. http://www.w3.org/2002/ws/desc/4/lc-issues/#LC130

Transition history

raised on 24 Aug 2005 by Hugo Haas (hugo@w3.org)

agreed on 26 Sep 2005

Proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/0012.html accepted.

Acknowledgment cycle

announced by group on 5 Oct 2005

Action history

LC320: SOAP and HTTP bindings: {parent} property for nested components [link to this issue]

Part 2 defines a number of new components: a SOAP Module component, a
SOAP Header Block component, a HTTP Header component.

All of those are nested components. Part 1 states:

  The component that contains a nested component is referred to as the
  parent of the nested components. Nested components have a {parent}
  property that is a reference to their parent component.
  -- http://www.w3.org/TR/2005/WD-wsdl20-20050803/#Description_details

It would be good to define a similar {parent} property for our nested
components in Part 2, especially as the concept of parent is used in
the IRI identification of those components.

Transition history

raised on 24 Aug 2005 by Hugo Haas (hugo@w3.org)

agreed on 8 Sep 2005

Proposal accepted.

Acknowledgment cycle

announced by group on 15 Sep 2005

Action history

LC321: SOAP binding: clarify that the lack {soap mep} value is an error [link to this issue]

In Table 5-4. Mapping from XML Representation to SOAP Operation
Component Properties from 5.8.4 Mapping from XML Representation to
Component Properties in Part 2, we say:

   ┌───────────────┬───────────────────────────────────────────────────────┐
   │   Property    │                         Value                         │
   ├───────────────┼───────────────────────────────────────────────────────┤
   │               │ The actual value of the wsoap:mep attribute           │
   │               │ information item, if present. If not, the actual      │
   │               │ value of the wsoap:mepDefault attribute information   │
   │ {soap mep}    │ item of the parent wsdl:binding element information   │
   │               │ item, if present. If not the value as defined by the  │
   │               │ default SOAP binding rules (for SOAP 1.2, see 5.11.3  │
   │               │ Default Binding Rules), if applicable.                │
   ├───────────────┼───────────────────────────────────────────────────────┤

We should add "Otherwise an error" to clarify that it's not OK for
{soap mep} not to have a value.

Transition history

raised on 24 Aug 2005 by Hugo Haas (hugo@w3.org)

agreed on 26 Sep 2005

Proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/0011.html accepted.

Acknowledgment cycle

announced by group on 5 Oct 2005

Action history

LC322: HTTP binding: Part 2 section 6.3 Default Binding Rules clarification [link to this issue]

This is an editorial comment.

In Part 2, section 6.3 Default Binding Rules reads:

       Note:

       The application/x-www-form-urlencoded serialization format places
       constraints on the stype of the interface operation bound (see 6.9.1
       Serialization as application/x-www-form-urlencoded ).

There's a typo ("stype"), and it would be more precise to say:

  The application/x-www-form-urlencoded serialization format places
  constraints on the XML Schema definition of the {element
  declaration} property of the Interface Message Reference components
  of the Interface Operation component bound (see 6.9.1 Serialization
  as application/x-www-form-urlencoded ).

Transition history

raised on 24 Aug 2005 by Hugo Haas (hugo@w3.org)

agreed on 1 Sep 2005

Accepted.

Acknowledgment cycle

announced by group on 15 Sep 2005

Action history

LC323: HTTP binding: Use of HTTP accept headers [link to this issue]

Part 2's section 6.3 Default Binding Rules states:

     * Accept headers. Standard HTTP accept headers (see section 14 of [IETF
       RFC 2616]) MAY be used in an HTTP request. When constructing an HTTP
       Accept header, the HTTP client MAY take into account the
       expectedMediaType information (see [MTXML]) appearing on an output
       message description to find out about the type of binary element
       content which is expected to be sent by the HTTP server.

This hints that expectedMediaType may contain a list of media types
that may be used in an HTTP response.

However, we have defined an {http output serialization} property which
declares the one media type which is being used in the HTTP response.

So how does expectedMediaType come into play here? Do Accept headers
really do anything useful?

This needs to be clarified.

For background information, see the thread starting at [1].

Should we keep the text above, "appearing on an output message
description" needs to be crisply expressed in terms of components and
properties.

  1. http://lists.w3.org/Archives/Public/www-ws-desc/2005Aug/0010.html

Transition history

raised on 24 Aug 2005 by Hugo Haas (hugo@w3.org)

agreed on 27 Sep 2005

Accept Hugo's proposal in http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/0043.html.

Acknowledgment cycle

announced by group on 5 Oct 2005

Action history

LC324: HTTP binding: error in definition of queryParameterSeparatorDefault and queryParameterSeparator [link to this issue]

This is an editorial issue.

In Part 2, section 6.5 Specifying the Default HTTP Method defines the
{http query parameter separator} property.

Section 6.6.3 XML Representation reads:

   The XML representation for binding an Operation are four attribute
   information items with the following Infoset properties:

  [...]

     * An OPTIONAL queryParameterSeparatorDefault attribute information item
       with the following Infoset properties:

          * A [local name] of queryParameterSeparatorDefault

          * A [namespace name] of "http://www.w3.org/2005/08/wsdl/http"

          * A type of xs:string whose length facet value is "1"

Not four, but six AIIs are defined.

Moreover, it's not queryParameterSeparatorDefault which is on
operation, but queryParameterSeparator.

queryParameterSeparatorDefault should still be defined, though. Before
defining it, we need to decide where (see issue about "Editorial
reorganization for defaults").

Transition history

raised on 24 Aug 2005 by Hugo Haas (hugo@w3.org)

agreed on 22 Sep 2005

Accepted.

Acknowledgment cycle

announced by group on 5 Oct 2005

Action history

LC325: HTTP binding: defaultTransferCoding typo [link to this issue]

This is a purely editorial comment.

In Part 2, section 6.10.3 XML Representation, defaultTransferCoding
should be transferCodingDefault.

Also:

  The XML representation for specifying the transfer coding is an
  OPTIONAL attribute information item with the following Infoset
  properties:

Should be:

  The XML representation for specifying the transfer coding is an
  OPTIONAL attribute information item for the input, output, infault
  and outfault EIIs with the following Infoset properties:

Transition history

raised on 24 Aug 2005 by Hugo Haas (hugo@w3.org)

agreed on 1 Sep 2005

Accepted.

Acknowledgment cycle

announced by group on 15 Sep 2005

Action history

LC326: HTTP binding: whis is {http authentication scheme} an xs:string? [link to this issue]

Section 6.12.2 Relationship to WSDL Component Model reads:

    {http authentication scheme} REQUIRED. xs:string to the Endpoint
    component, corresponding to the HTTP authentication scheme used.
    The valid values are "basic" for the "basic" authentication scheme
    defined in [IETF RFC 2617], "digest" for the Digest Access
    Authentication scheme as defined in [IETF RFC 2617], and "none"
    for no access authentication.

It would be better to have:

  A xs:token with one of the values basic, digest, or none.

and have this reflected in the schema.

Transition history

raised on 24 Aug 2005 by Hugo Haas (hugo@w3.org)

agreed on 26 Sep 2005

Proposal accepted.

Acknowledgment cycle

announced by group on 5 Oct 2005

Action history

LC327: HTTP binding: {http authentication realm} is required [link to this issue]

In Part 2's 6.12 Specifying HTTP Access Authentication, we have:

     * {http authentication realm} REQUIRED. A xs:string to the Endpoint. It
       corresponds to the realm authentication parameter defined in [IETF
       RFC 2617]. If the value of the {http authentication scheme} property
       is not "none", it MUST not be empty.

[...]

   ┌──────────────────────┬────────────────────────────────────────────────┐
   │       Property       │                     Value                      │
   ├──────────────────────┼────────────────────────────────────────────────┤
[...]
   │                      │ The actual value of the                        │
   │ {http authentication │ whttp:authenticationRealm attribute            │
   │ realm}               │ information item; otherwise, "" (the empty     │
   │                      │ value).                                        │
   └──────────────────────┴────────────────────────────────────────────────┘

Why do we have this property required and defaulting to an empty
string?

It seems to make more sense to have this property optional.

Here's a proposal for the property definition:

  {http authentication realm}, OPTIONAL.

    A xs:string. It corresponds to the realm authentication parameter
    defined in [IETF RFC 2617]. If the value of the {http
    authentication scheme} property is not "none", it MUST be present
    and not empty.

and for its mapping:

    The actual value of the whttp:authenticationRealm attribute
    information item, if present.

This is related to another comment about optional properties
defaulting to empty values.

Transition history

raised on 24 Aug 2005 by Hugo Haas (hugo@w3.org)

agreed on 26 Sep 2005

Close issue with following resolution: - make auth scheme and realm both optional - auth scheme and auth realm properties exist together - drop the value "none" from auth scheme values - we use the default value of the attribute to provide the default value for realm (of "") - editorial: clean up the wording of the "Relationship to WSDL Component Model" to properly use the word component and property correctly and carefully.

Acknowledgment cycle

announced by group on 5 Oct 2005

Action history

LC328: editorial comments on WSDL 2 part 1 last call draft [link to this issue]

Hi all,

here are some (IMHO) editorial comments on WSDL2 part 1 2005 last call
draft (it's really nifty how both last calls fall on 3 Aug 8-) ):


1) section 6.1.1 on mandatory extensions talks about extensions,
features and properties being optional or mandatory. I believe all
mentions of properties should be dropped from this section as properties
cannot be made mandatory, AFAICS.


2) section 8 (Conformance) should have at least a short introductory
paragraph before 8.1 starts; and this paragraph could describe how
section 8 (Conformance) is different from 1.2 (Document Conformance).


3) MAY is IMHO overly capitalized in many places and should be
lowercased: 2.3.1 first capitalized MAY; 2.4.1 same; 2.4.1.1 same; last
in 2.9.1; first in 3.1; 3.1.2; 4.2.1; 7.1.

My rule of thumb is to capitalize MAY where a reader could reasonably
expect MUST NOT or SHOULD NOT, like "the property MAY be empty", but not
where the may is kinda obvious, like "XML Schema MAY be used [in WSDL]".

My reason for dropping the capitalization is to make it easier for the
reader - they won't need to stop and think about the significance of
this particular MAY (like "should I have expected otherwise for some
reason?")


4) 2.8.1.1 says "IRI MAY ... be associated with AT MOST one ..." - I
don't think we should use "MAY AT MOST" in the conformance sense here;
this should be rephrased to use the standard MAY/SHOULD/MUST and other
verbiage to describe the constraint.

Transition history

raised on 6 Sep 2005 by Jacek Kopecky (jacek.kopecky@deri.org)

agreed on 22 Sep 2005

Accepted.

Acknowledgment cycle

announced by group on 5 Oct 2005

Action history

LC329: editorial comments on WSDL 2 part 2 - adjuncts - last call draft [link to this issue]

here are some (IMHO) editorial comments on WSDL2 part 2 (Adjuncts) 2005
last call draft:


1) MAY is IMHO overly capitalized in many places and should be
lowercased: 3.1 (thus the operation MAY or MAY NOT be safe 8-) ); 4.1.1;
first in Accept headers in 6.3; 6.8.1; ednote in 6.9.1.1; double curly
brace in 6.9.1.1

My rule of thumb is to capitalize MAY where a reader could reasonably
expect MUST NOT or SHOULD NOT, like "the property MAY be empty", but not
where the may is kinda obvious, like "XML Schema MAY be used [in WSDL]".

My reason for dropping the capitalization is to make it easier for the
reader - they won't need to stop and think about the significance of
this particular MAY (like "should I have expected otherwise for some
reason?")


2) in 5.9.2, in the bullet, the word "added" seems to be missing before
"to the Binding...", or something other is missing in that sentence.


3) section 5 in the beginning (fourth para) points out how no defaults
are provided for faults so if an interface contains faults, it must be
bound explicitly. That's no longer true since we made code and subcodes
optional; that fourth paragraph from section 5 should be removed.

Transition history

raised on 6 Sep 2005 by Jacek Kopecky (jacek.kopecky@deri.org)

agreed on 13 Oct 2005

Drop paragraph as requested.

Acknowledgment cycle

announced by group on 3 Nov 2005

Action history

LC330: WSDL 2: operation styles should mandate content model [link to this issue]

Hi all,

a last call comment on the 2005 last call draft of the adjuncts:

I believe operation styles should mandate that the {message content
model} of the operation's messages is "#element". This applies to
sections 4.1, 4.2 and 4.3.

All the styles mandate that the content model be defined using an
element that is a sequence, so message content models #any, #none and
#other should probably be disallowed. I don't think we will lose any
useful functionality.

Transition history

raised on 6 Sep 2005 by Jacek Kopecky (jacek.kopecky@deri.org)

agreed on 27 Sep 2005

Proposal accepted.

Acknowledgment cycle

announced by group on 5 Oct 2005

Action history

LC331: WSDL 2: adjuncts description of #any msg content model unclear [link to this issue]

Hi all, 

a last call comment on the 2005 last call draft of the adjuncts:

Sections 5.3 and 6.3 say: "if the value of the {message content model}
property is "#any" then the payload MAY be any one XML element."

I believe this MAY actually hides a hard constraint, it seems that "MUST
be a single XML element" would be more correct.

Transition history

raised on 6 Sep 2005 by Jacek Kopecky (jacek.kopecky@deri.org)

agreed on 27 Sep 2005

Accepted.

Acknowledgment cycle

announced by group on 5 Oct 2005

Action history

LC332: WSDL 2: HTTP input, output, fault serialization in the wrong place [link to this issue]

Hi all, 

a last call comment on the 2005 last call draft of the adjuncts:

Section 6.6.2 in adjuncts defines {http input serialization}, {http
output serialization} and {http fault serialization} to describe the
content type of the messages. It does so on the binding operation
component level. I believe the binding message reference and binding
fault reference components would be a better place for these properties;
and the current places could be dropped or they could carry defaults.

So instead of 

<binding ...>
  <operation ... whttp:outputSerialization="image/jpeg" />
</binding>

we'd have 

<binding ...>
  <operation ... >
    <output whttp:serialization="image/jpeg" />
  </operation>
</binding>

This would allow us to define different serializations for different
output messages (or different input messages or different faults).
Granted, none of our MEPs have multiple input messages or multiple
output messages, but there can always be multiple faults.

It doesn't seem to me that the current limitation to a single
serialization format for all inputs, other for all outputs and yet
another for all faults, is in any way useful. In fact, to me it seems
fairly strange.

Transition history

raised on 6 Sep 2005 by Jacek Kopecky (jacek.kopecky@deri.org)

declined on 27 Sep 2005

Closed without action.

Acknowledgment cycle

announced by group on 5 Oct 2005

LC333: WSDL 2: binding defaults not component model properties? [link to this issue]

Hi all,

a last call comment on the 2005 last call draft of the adjuncts:

In both bindings, SOAP and HTTP, there are a number of attributes for
specifying defaults, like transferCodingDefault, mepDefault,
methodDefault etc. These attributes are used when constructing the
component model, but they only provide the defaults for the created
operation and message reference components, for example a binding
operation will get the default HTTP transfer coding if it doesn't
specify its own.

I don't think this will work the expected way for interfaceless
bindings, i.e. bindings that don't say what interface they bind. These
bindings don't contain any operations, so the defaults are not used and
are dropped. I'm not sure what is used for those affected properties
when the binding is used on an endpoint and thus indirectly connected to
the endpoint's service's interface.

I believe we should add component properties to carry these default
values in the component model.

Transition history

raised on 6 Sep 2005 by Jacek Kopecky (jacek.kopecky@deri.org)

agreed on 11 Nov 2005

Proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2005Oct/0051.html accepted.

Acknowledgment cycle

announced by group on 14 Nov 2005

Action history

LC334: WSDL 2: HTTP binding error reason phrase unnecessary [link to this issue]

Hi all,

a last call comment on the 2005 last call draft of the adjuncts:

in our HTTP binding, we have a property {http error reason phrase} which
is IMHO unnecessary. The HTTP reason phrase is purely informative and
therefore it doesn't make much sense to specify what a service will use
for a particular fault.

To compare, we don't deal with fault reason in the SOAP binding, and I
raised a similar issue for WS Addressing (they mandated SOAP fault
reasons for their faults) and they decided to make their text the
recommended reason text, not the required one.

I believe we should drop whttp:reasonPhrase attribute and all the
corresponding property, {http error reason phrase}, from WSDL 2 HTTP
binding.

Transition history

raised on 6 Sep 2005 by Jacek Kopecky (jacek.kopecky@deri.org)

agreed on 27 Sep 2005

Accepted.

Acknowledgment cycle

announced by group on 5 Oct 2005

Action history

LC335: simple case of IRIs for Components in WSDL 2.0 [link to this issue]

Regarding...

  C. IRI References for WSDL 2.0 Components
  http://www.w3.org/TR/2005/WD-wsdl20-20050803/#wsdl-iri-references

Those URIs are much more complicated than they need to be:

http://example.org/TicketAgent.wsdl20#xmlns(xsTicketAgent=http://example.org/TicketAgent.xsd)
        wsdl.elementDeclaration(xsTicketAgent:listFlightsRequest) 

In the simple case, if there's only one component named CN in
a namespace TNS, then TNS#CN should be a standard URI for it.

e.g. given
 targetNamespace="http://www.w3.org/2005/08/sparql-protocol-query"

and

 <interface name="SparqlQuery"

Then we should be able to use
 http://www.w3.org/2005/08/sparql-protocol-query#SparqlQuery

to refer to that interface.

FYI, I think Henry made this argument in the TAG
regarding issue abstractComponentRefs-37

  http://www.w3.org/2001/tag/issues.html?type=1#abstractComponentRefs-37

... for example at our june meeting.
  http://www.w3.org/2001/tag/2005/06/14-16-minutes.html#item031


Henry should get only credit, not blame, in case I'm misrepresenting
his position.


See also similar comments on XML Schema component designators...

simple barenames for schema component designators  31 Mar 2005
http://www.w3.org/2002/02/mid/1112297140.32006.540.camel@localhost;list=www-xml-schema-comments


p.s. thanks to Bijan for helping me find the relevant part of the spec
in IRC discussion
 http://www.ilrt.bris.ac.uk/discovery/chatlogs/swig/2005-09-09#T19-51-41

Transition history

raised on 9 Sep 2005 by Dan Connolly (connolly@w3.org)

declined on 26 Sep 2005

Close with no action.

Acknowledgment cycle

announced by group on 5 Oct 2005

objection from reviewer on 12 Oct 2005

objection maintained by group on 11 Nov 2005

WG feels the commenter's proposal conflicts with the definition of barename pointer. We are defining a new scheme specific to WSDL. We should not override an existing scheme.

LC336: LC ISSUE from WSA: Clarify applicability of wsdx:Interface and wsdx:Binding [link to this issue]

Section 3.3 contains statements about "schema components that use the
xs:anyURI simple type".  Specifically mentioning this, and not
mentioning any other type, raises some doubt as to whether these
attributes may be used to annotate other types, particularly
EndpointReferences of type wsa:EndpointReferenceType.  It would be
clearer either to drop the reference to xs:anyURI specifically (leaving
"schema components"), or to soften it to something more like "schema
components, for example those that use the xs:anyURI simple type."

Transition history

raised on 12 Sep 2005 by David Hull (dmh@tibco.com)

agreed on 26 Sep 2005

Second proposal accepted (softening), plus mention WS-A EPRs here.

Acknowledgment cycle

announced by group on 5 Oct 2005

Action history

LC337: fault serialization [link to this issue]

WS-Desc,

I'm writing on behalf of DAWG, which is using WSDL 2.0 to specify the SPARQL
Protocol for RDF [1]. We have a couple of LC comments about WSDL 2.0, and
I'll be sending each one in a separate message.

We'd like to avoid having to require a particular fault serialization type
in our HTTP bindings. That is, we anticipate SPARQL services being free to
serialize fault messages in several different Media Types: plain text, HTML,
XML, RDF, etc.

If whttp:faultSerialization is a required property and the default value
doesn't describe our service, what alternative do we have?

Hugo Haas responded to my initial comments thus:

  Maybe the fault serialization should be a property of the Binding Fault
  and Binding Fault Reference components, rather than of the Binding
  Operation, which would solve your problem.

There may be other design choices as well.

Cheers, 
Kendall Clark

[1] http://www.w3.org/sw/2001/DataAccess/proto-wd/

Transition history

raised on 14 Sep 2005 by Kendall Clark (kendall@monkeyfist.com)

agreed on 27 Sep 2005

Copy the content of section 2.2 of the Describing Media Types for Binary Content note (a product of this WG) into part two, AND point the definition of whttp:inputSerialization, whttp:outputSerialization, and whttp:faultSerialization at that definition, AND check other references to these serialization properties to insure that they do not improperly restrict serialization to a single mime type.

Acknowledgment cycle

announced by group on 5 Oct 2005

agreement by reviewer on 17 Oct 2005

Action history

LC338: limitations of {http output serialization} [link to this issue]

WS-Desc,

I'm writing on behalf of DAWG, which is using WSDL 2.0 to specify the SPARQL
Protocol for RDF [1]. We have a couple of LC comments about WSDL 2.0, and
I'll be sending each one in a separate message.

In short, we'd like to have multiple values for {http output serialization}.
Well, in truth, multiple values, or some kind of MIME wildcard, or allow
that component to be optionally declared. (FWIW, I believe this issue is
related to LC323 but not identical.)

Our situation is that our protocol qua service has one interface,
SparqlQuery, and one operation, query. That operation takes a SPARQL query
and returns the results of that query. Nice, neat, and simple.

However, SPARQL queries may return different MIME types, including
application/sparql-results+xml, application/rdf+xml, as well as different
serializations of RDF (N3, Turtle, N-Triples).

We also have a POST binding for query in order to submit In Messages that
are so long as to not reliably be serializable over a GET.

If we had to declare a different operations, the total number would become
really unwieldy -- I think the total number would be 10 (number of
serialization formats, 5, times the number of HTTP methods, 2 -- eek! And,
FWIW, this will only get worse if future DAWG adds other interfaces or
operations, with the same blowup of operations. Very unwieldy!)

Much simpler, and more descriptively accurate, to be able to say:

<operation ... whttp:outputSerialization="application/sparql-results+xml, 
application/rdf+xml...">

or

<operation ... whttp:outputSerialization="*/*">

Cheers, 
Kendall Clark

[1] http://www.w3.org/sw/2001/DataAccess/proto-wd/

Transition history

raised on 15 Sep 2005 by Kendall Clark (kendall@monkeyfist.com)

agreed on 6 Oct 2005

Resolution of LC337 covers this issue as well.

Acknowledgment cycle

announced by group on 6 Oct 2005

agreement by reviewer on 17 Oct 2005

LC339: Comments on WSDL SOAP Binding Extension section of Adjuncts from WS-Addressing WG [link to this issue]

The comments below form part of the the WS-Addressing WG's review of the 
WSDL drafts (WS-A WG Meeting 19th Sept 05).  These comments refer to WSDL 
SOAP binding Extension section in the Adjuncts document.
Regards,
Katy Warr

WSDL Adjuncts Section: 5.10.3 SOAP Header Block component 
How does wsoap:header indicate required = true/false? 
There does not appear to be a way to indicate that the service 
(a) supports the header and the client may send it 
VS 
(b) supports headers and REQUIRES that the client use the described 
header? 
The mustUnderstand=true attribute part of <wsoap:header> indicates only 
whether the mustUnderstand attribute must be set on the header (and not 
whether it is mandatory for the client to send the header itself). 

Transition history

raised on 19 Sep 2005 by Katy Warr (katy_warr@uk.ibm.com)

agreed on 26 Sep 2005

Add a 'required' attribute to wsoap:header and whttp:header similar to wsoap:module and a 'required' property. Missing attribute maps to 'false'. When 'true' it means that the service expects the header to be there; when 'false' then the sender decides whether it should be there or not.

Acknowledgment cycle

announced by group on 5 Oct 2005

Action history

LC340: Comments on WSDL SOAP Binding Extension section of Adjuncts from WS-Addressing WG [link to this issue]

WSDL Adjuncts Section 5.10.3 SOAP header block component 
The following sentence switches between a SOAP Header Block representing 1 
header and representing multiple headers.
"A SOAP Header Block component describes an abstract piece of header data 
(message headers) that is associated with the exchange of messages between 
the communicating parties. The presence of a SOAP Header Block component 
in a WSDL description indicates that the service supports headers and MAY 
require a Web service consumer/client that interacts with the service to 
use the described header. Zero or more such headers may be used." 

Transition history

raised on 19 Sep 2005 by Katy Warr (katy_warr@uk.ibm.com)

agreed on 26 Sep 2005

Correct the plurals editorially, replace 0 or more with 0 or 1.

Acknowledgment cycle

announced by group on 5 Oct 2005

Action history

LC341: Comments on WSDL SOAP Binding Extension section of Adjuncts from WS-Addressing WG [<