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 [link to this issue]

WSLD Adjuncts Section 5.3 (Default Binding rules) 
Minor comment - comma required after the word 'transmitted' aids 
understanding of this sentence. 
Payload Construction. When formulating the SOAP envelope to be transmitted 
the contents of the payload (i.e., the contents of the SOAP Body element 
information item of the SOAP envelope) MUST be what is defined by the 
corresponding Interface Message Reference component. 
  
WSDL Adjuncts Section 5.10.3 SOAP Header Block component 
"{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 SOAP header block." 
"This element represents a SOAP Header block" is confusing - it 
refererences the SOAP hdr block representation but doesn't represent it 
itself.

Transition history

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

agreed on 22 Sep 2005

Accept addition of comma, {element} will be named {element declaration}, and check that this convention is adhered to elsewhere in the document, and the final sentence will be reworded for more clarity.

Acknowledgment cycle

announced by group on 5 Oct 2005

Action history

LC342: Typos (Adjuncts) [link to this issue]

A few typos courtesy of Marc:

Section 2, first paragraph after note: "define the sequence and of
abstract messages" should be "define the sequence of abstract messages"

Section 5.10.1: "ond" should be "and"

Section 5.11.2:

  "extension of the 5." should be either "extension of 5." or "extension
of section 5."

  "patterns defined in 2." should be "patterns defined in section 2" 

  "patterns defined in 6." should be "patterns defined in section 6.6" 

Section 5.9.1: "it is permissible for specification interaction to
engage" is very strange wording. I don't really have an alternative but
wanted to call attention to it.

Section 6.3 first note after table 6-1: "stype" should be "type"

Transition history

raised on 20 Sep 2005 by Jonathan Marsh (jmarsh@microsoft.com)

agreed on 13 Oct 2005

Accept proposals. Address point 3 with the text at http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/0052.html.

Acknowledgment cycle

announced by group on 3 Nov 2005

agreement by reviewer on 3 Nov 2005

Action history

LC343: Comments on Web Services Description Language (WSDL) Version 2.0 Part 0: Primer [link to this issue]

I'm puzzled at the use of a special mechanism for importing XML schemas, 
as discussed in 2.3.2. AFAIKS, the same effect can be had by just using 
a simple xs:schema wrapper element:

  <xs:schema>
    <xs:import .../>
  </xs:schema>

This is a cleaner approach than just in-lining the xs:import and 
xs:include, since it minimizes the number of different ways of doing the 
same thing. From the comment at the end of 2.3.1, it seems that there's 
a misunderstanding of how schema operates here. As I understand it, 
imported schema definitions become part of the schema and have the same 
visibility as definitions made directly under the including schema. In 
support of this interpretation, section 4.2.3 of Schema Part 1 
(http://www.w3.org/TR/xmlschema-1/#composition-schemaImport) ends with:

The ·schema components· 
<http://www.w3.org/TR/xmlschema-1/#key-component> (that is {type 
definitions} <http://www.w3.org/TR/xmlschema-1/#type_definitions>, 
{attribute declarations} 
<http://www.w3.org/TR/xmlschema-1/#attribute_declarations>, {element 
declarations} <http://www.w3.org/TR/xmlschema-1/#element_declarations>, 
{attribute group definitions} 
<http://www.w3.org/TR/xmlschema-1/#attribute_group_definitions>, {model 
group definitions} 
<http://www.w3.org/TR/xmlschema-1/#model_group_definitions>, {notation 
declarations} <http://www.w3.org/TR/xmlschema-1/#notation_declarations>) 
of a schema corresponding to a <schema> 
<http://www.w3.org/TR/xmlschema-1/#element-schema> element information 
item with one or more <import> 
<http://www.w3.org/TR/xmlschema-1/#element-import> element information 
items must include not only definitions or declarations corresponding to 
the appropriate members of its [children] 
<http://www.w3.org/TR/xml-infoset/#infoitem.element>, but also, for each 
of those <import> <http://www.w3.org/TR/xmlschema-1/#element-import> 
element information items for which clause 2 
<http://www.w3.org/TR/xmlschema-1/#c-ims> above is satisfied, a set of 
·schema components· <http://www.w3.org/TR/xmlschema-1/#key-component> 
identical to all the ·schema components· 
<http://www.w3.org/TR/xmlschema-1/#key-component> of *I*.

Given this, I don't see any possible reason why xs:imported components 
of a schema would not be available for reference by QName in the WSDL.

Transition history

raised on 20 Sep 2005 by Dennis Sosnoski (dms@sosnoski.com)

agreed on 27 Sep 2005

Agreed to add a note at the bottom of table that points out that WSDL 2.0 is different that common 1.1 usage patterns. Also adding a negative example.

Acknowledgment cycle

announced by group on 5 Oct 2005

Action history

LC344: LC ISSUE: Editorial points [link to this issue]

This email collects several minor editorial points regarding the WSDL
Core specification, some more minor than others.  I apologize for the
somewhat late submission, which was due to several extraneous
circumstances too tedious to mention.

   1) In the paragraph at the beginning of section 1.3 ending "... the
      functionality implied by that extension is only optional to the
      client.  But it needs to be supported by the Web Service." the
      last sentence might better read "It must be supported by the Web
      Service."
   2) In section 2.3.1, the paragraph beginning "Note that faults other
      than the ones described in the Interface ..." seems like more than
      a mere note.
   3) In the same section, the rather long note beginning "Despite
      having a {name} property, Interface Fault components cannot be
      identified ..." seems to say, basically, that separately included
      interfaces must be consistent with each other to the extent they
      overlap.  If this is so, something to the effect of "In other
      words, interfaces must be consistent where they overlap." might
      make the situation clearer.  Also, my first reaction to this was
      "Ah, the diamond inheritance problem."  But diamond inheritance is
      not a problem, since the shared ancestor is automatically
      consistent with itself (see the note on idempotency below).  If
      I've got this right, it might be worth noting.
   4) The above note appears in very similar form in other sections. 
      I'm sure that factoring this out has been suggested, but for what
      it's worth, I'd like to weigh in in favor of having at least the
      bulk of it appear only once, possibly with a short reference where
      the mostly-repeated text presently appears
   5) In section 2.4.1.1, in "... the rules implied by that IRI (such as
      rules that govern the schemas) MUST be followed or it is an
      error", it was not clear to me what exactly should happen should
      this error occur.  The text appears to mean that the combination
      simply would not work, just as in-scope properties with an empty
      intersection won't work.  The question here is, what entity, if
      any, needs to report this error (and how, etc.).  Also, the net
      effect of all this seems to be the conjunction of the (possibly
      empty) set of constraints specified by the IRIs, but the
      separation into cases obscures this somewhat.  If there is a
      general agreement that this paragraph could be made clearer, I
      would be willing to attempt a clearer wording.
   6) In section 2.7.1, second paragraph.  Consecutive sentences start
      with "Thus," and "Hence,"  This might flow better as "Thus, by
      definition, every SOAP 1.2 abstract feature is also a WSDL 2.0
      feature, and there is no need to define a separate WSDL 2.0
      feature ..."
   7) In section 2.8.1, first paragraph, the last sentence asserts
      "Properties, and hence property values, can be shared amongst
      features/bindings/modules, and are named with IRIs precisely to
      allow this type of sharing."  This seems to emphasize that the
      names are not QNames, but it wasn't apparent to me why QNames
      wouldn't have worked equally well.  I have the distinct feeling
      the answer is blindingly obvious and I'm just missing it.
   8) In 2.8.1.1, the paragraph beginning "Many of the component types
      in the component model contain a {properties} property ..."
      produced parse errors on the first couple of readings.  The root
      problem is that "property" is badly overloaded, at least in this
      context.  Unfortunately, it's not clear how to avoid this
      painlessly, as both senses of "property" are integral to the
      spec.  The upshot seems to be to distinguish between properties
      (in the F&P sense) that are directly attached (declared
      properties) and all applicable properties, whether directly
      attached or pulled in by composition (in-scope properties).  If
      this is the intent, the wording could be clearer (and again, I
      could probably have a go at rewording it).
   9) In 2.9.1, paragraph 6, the text "Thus, it is an error for a
      binding component not to define bindings ..." again leads me to
      wonder what reports the error and when.  Also, the "Thus," made me
      wonder if I'd missed a step (quite likely).
  10) In 2.9.2, in the XML representation of Binding components, the
      word "whgse" was clearly inserted to test whether reviewers were
      awake.  I'm happy to report that I might well be.
  11) Section 2.11.2.2 seems like boilerplate in the same sense as the
      note on inheritance and overlap mentioned above.
  12) In the tables in sections 2.12.3 and 2.13.3, the descriptions of
      {interface message|fault reference}seem rather lengthy for a table
      entry.  And again, they seem to be near duplicates.  The general
      problem with such duplication is of course that it's hard to tell
      without careful inspection what's duplicated and what's not.
  13) In section 2.15.1, the {address} is given as optional.  Is there
      any guidance on when one might want to not include it?
  14) In section 2.17, the definition of equivalence is oddly
      asymmetric.  Speaking as a math major, I'd be more comfortable if
      "and the second component has no additional properties" were
      simply "and vice versa."  Similarly, "set-based values are
      considered equivalent if they contain corresponding equivalent
      values, without regard to order." feels a bit odd since on the one
      hand, sets are unordered by definition, and on the other hand they
      are also duplicate-free by definition but this is not mentioned. 
      I might reword this as "Set-based values are considered equivalent
      if for each value in the first, there is an equivalent value in
      the second, and vice versa," parallel with the proposed rewording
      for components as a whole (and the usual set-theoretic definition
      that each is a subset of the other).
  15) In the same section, in the first bullet point (simple types),
      does "contain the same value" mean "contain the same actual value"
      in the XSD sense?  If not, what does it mean?
  16) In section 2.19, first paragraph, a "tuple, consisting of two
      parts" is generally called an "ordered pair".
  17) In the following paragraph, "QName references are resolved by
      looking in the appropriate property," the appropriate property
      should be spelled out, even if the result is a bit tedious.
  18) In 4.1, the paragraph beginning "A mutual include is direct
      inclusion by one WSDL 2.0 document of another WSDL 2.0 document
      ..." the upshot seems to be that inclusion is idempotent (because
      a component is equivalent to itself and so multiple inclusion
      doesn't redefine anything).  It would be better either to mention
      idempotency explicitly, or, perhaps better, to rephrase this
      paragraph in terms of the transitive closure (which is mentioned
      earlier) to explain that everything in the transitive closure of
      the inclusion relation is thrown into the same flat space.
  19) In section 4.1, the location attribute doesn't have to be
      dereferenceable, but this may lead to unresolvable QNames down the
      line.  It would be nice to say that implementations SHOULD report
      broken location links as a root cause of the QName failures they
      cause, assuming that this is not burdensome to determine.
  20) A.3 (security considerations) is remarkably short.  This is just a
      comment -- I don't think it needs to be lengthened.

Transition history

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

declined on 10 Nov 2005

Partial resolutions recorded at http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/att-0067/20050926-ws-desc-minutes.html.

1. Proposal accepted.
2. Accept proposal to reword "Note that".
3. Close with no action (this paragraph has already been revised somewhat).
4. Close with no action (too disruptive at this time).
5. Implement proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2005Oct/0040.html, plus these amendments:Proposed sentence: "This additional information in no way affects the messages exchanged with the service and ..."s/by the interface message reference components of the/in/"If no Operation component can simultaneously satisfy all of the styles, the document is invalid."Update URI to IRI.Section 2.4.1.2 needs to be amended to include Faults and to not just be applied to the {element declarations} but to the actual components since the style MAY be dependent on direction or possibly sequence.
6. Refer to editors for cleanup. Arthur to edit 2.7.1 and capitalize feature appropriately and define "feature" somewhere.
7. Close with no action (because of precedence for IRIs)
8. Close with no action (although we agree the comment makes sense, there is no will to address it at this stage).
9. Remove last sentence of paragraph 6 of section 2.9.1.
10. Accept proposal.
11. Close with no action.
12. Close with no action other than the improvements we plan to make when adding test assertion markup.
13. Add a sentence saying {address} is optional because it could be defined by other means, such as an WS-A endpoint reference or maybe the scenario does not require an address.
14. Accept suggested wording.
15. Close without change: "actual value" is about XML, the component model is in math space.
16. Close with no action.
17. Close with no action. The majority of the WG felt it was clear enough.
18. Close with no action.
19. Close with no action. Assumption that location does not have to be dereferenceable is not accurate.
20. Thank you for the comment.

Acknowledgment cycle

announced by group on 14 Nov 2005

agreement by reviewer on 15 Nov 2005

Action history

LC345: POST & application/x-www-form-urlencoded serialization [link to this issue]

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. This message contains the
last LC comment we intend to raise at this time.

We have added a POST binding for our sole operation, query, because we
anticipate there being SPARQL queries, perhaps autogenerated ones, that are
too long to transmit reliably over GET, serialized into a URI. Therefore, we
added a POST binding, and we'd like the serialization of the input message
for that POST operation to be application/x-www-form-urlencoded. We do not
have an XML serialization of SPARQL's surface syntax, so that we cannot POST
application/xml. 

As with our other two comments, we raise this because we'd like to use WSDL
2.0 to describe our service *accurately* and completely.

Cheers, 
Kendall Clark

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

Transition history

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

agreed on 10 Nov 2005

Implement proposals at http://www.w3.org/2002/ws/desc/5/09/wsdl20-adjuncts.html#_http_serialization and http://lists.w3.org/Archives/Public/www-ws-desc/2005Nov/0020.html, plus change the "/" syntax to an attribute.

Acknowledgment cycle

announced by group on 14 Nov 2005

Action history

LC346: Comments from WS-A on WSDL 2.0 documents [link to this issue]

These are the comments I have on the WSDL 2.0 Primer, per the request
that the WS-Addressing WG review the WSDL 2.0 documents
 
1. Typos: 
 a. section 2.3 third para, first line: "either imported nor inlined"
should be "either imported or inlined". 

 b. section 2.4.4.1 last para under third bullet "provides examples for
the URI style and Multipart style" should be "provides examples for the
IRI style and Multipart style" 

 c. section 5.1 second para: "The context that a Web service may be
deployed" should probably be: "The context in which a Web service may be
deployed". 

2. Section 5.3 contains repeated use of the term "endpoint reference" in
a sense which is not a WS-A EPR. It would be wise, particularly given
the references in 5.2 to WS-A, to make it very clear that the endpoint
reference described in 5.3 is not an End Point Reference. Or maybe a
different term would be better? Something like "endpoint URL" perhaps? 

3. WS Addressing is not included in the References, despite being
mentioned in section 5.2. 

Transition history

raised on 22 Sep 2005 by Rogers, Tony (Tony.Rogers@ca.com)

agreed on 27 Sep 2005

All typos assigned to the editors. Editors to fix endpoint references. LC346 - #3, add WS-A reference.

Acknowledgment cycle

announced by group on 5 Oct 2005

Action history

LC347: Interface definition [link to this issue]

I was reading through the WSDL 2.0 primer. I see a new
addition where the fault is defined outside the
operation but inside the interface for reusability.
This logic can be extended for other messages as well
( input and output). Quite frankly it seems redundant
to declare the fault again inside the
interface. Fundamentally faults are no different than
output messages. Only thing the service provider responds
with it when the normal processing doesnt happen. They
should be treated like output messages. Declaring the
message type ( in schemas/types) and using it in the
Operation should be good enough similar to the other messages.

Transition history

raised on 8 Sep 2005 by rama krishna (crkrishna29@yahoo.com)

declined on 13 Oct 2005

Close with no action - WG already considered this option.

Acknowledgment cycle

announced by group on 3 Nov 2005

LC348: Minor errors in adjunct schema [link to this issue]

Hi,

I'd just like to point out a few minor errors in the 2005/08 versions of the adjunct schema for both SOAP and HTTP.

SOAP: Typo: mustUnderstnad -> mustUnderstand
HTTP: There is no declaration for the 'wsdl:' NS prefix.
	The type for reasonPhrase is xs:int; it should be xs:string.

Transition history

raised on 29 Sep 2005 by Thomson, Martin (Martin.Thomson@andrew.com)

agreed on 13 Oct 2005

Accept proposed edits.

Acknowledgment cycle

announced by group on 3 Nov 2005

agreement by reviewer on 3 Nov 2005

Action history

LC349: editorial: part 2 section 2 beginning [link to this issue]

Hi all,

just an editorial comment - I find the current beginning of section 2 of
part 2 (Predefined Message Exchange Patterns) kinda nasty - introducing
the term node before any introductory text that even mentions "message
exchange".

I think it would help if the introduction of the section was
reformulated.

Transition history

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

agreed on 13 Oct 2005

Swap first paragraph fro 1st 2 sentences of 2nd para.

Acknowledgment cycle

announced by group on 3 Nov 2005

Action history

LC350: Editorial: Part 1, Introduction [link to this issue]

Part 1, Introduction [1] says - "The WSDL Version 2.0 Part 2: Adjuncts
specification [WSDL 2.0 Adjuncts] describes extensions for Message
Exchange Patterns, features, SOAP modules and bindings of features, and
a language for describing such concrete details for SOAP 1.2"

Part 2 does not define "features" or "bindings of features".  The above
list should read "... extensions for Message Exchange Patterns, SOAP
modules, and a language for describing such concrete details for SOAP
1.2."

[1] http://www.w3.org/TR/2005/WD-wsdl20-20050803/#intro

Transition history

raised on 25 Sep 2005 by Asir Vedamuthu (asirveda@microsoft.com)

agreed on 13 Oct 2005

Accepted.

Acknowledgment cycle

announced by group on 3 Nov 2005

Action history

LC351: Editorial: Part 2, XML Namespace Table [link to this issue]

XML Namespace "http://www.w3.org/2005/08/wsdl/rpc" is missing in table
1-1 [1].

[1] http://www.w3.org/TR/2005/WD-wsdl20-adjuncts-20050803/#notcon

Transition history

raised on 25 Sep 2005 by Asir Vedamuthu (asirveda@microsoft.com)

agreed on 13 Oct 2005

Accepted.

Acknowledgment cycle

announced by group on 3 Nov 2005

Action history

LC352: Bug in RPC Signature Extension Schema [link to this issue]

attributeFormDefault value should be qualified at
http://www.w3.org/2005/08/wsdl/rpc.xsd because per Part 2 RPC Signature
Extension [1] is,

* A [local name] of signature

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

[1]
http://www.w3.org/TR/2005/WD-wsdl20-adjuncts-20050803/#InterfaceOperatio
n_RPC_Signature_XMLRep

Transition history

raised on 25 Sep 2005 by Asir Vedamuthu (asirveda@microsoft.com)

declined on 13 Oct 2005

Close with no action - it's a global attribute.

Acknowledgment cycle

announced by group on 3 Nov 2005

LC353: What is a valid WSDL component model? [link to this issue]

Part 1 claims, "An XML 1.0 document that is valid with respect to the
WSDL 2.0 XML Schema and that maps to a valid WSDL 2.0 Component Model is
conformant to the WSDL 2.0 specification." [1]

What is a valid WSDL 2.0 Component Model? Part 1 does not describe this.

[1] http://www.w3.org/TR/2005/WD-wsdl20-20050803/#markup

Transition history

raised on 25 Sep 2005 by Asir Vedamuthu (asirveda@microsoft.com)

agreed on 10 Nov 2005

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

Acknowledgment cycle

announced by group on 14 Nov 2005

Action history

LC354: typo in http://www.w3.org/TR/wsdl20/#rfc2119keywords [link to this issue]

EQUIRED/REQUIRED

Transition history

raised on 27 Sep 2005 by Pat Hayes (phayes@ihmc.us)

agreed on 20 Oct 2005

Proposal accepted.

Acknowledgment cycle

announced by group on 3 Nov 2005

Action history

LC355: Error in Part 2, BindingFault [link to this issue]

In Part 2 section "2.10.3 Mapping Binding Fault's XML Representation to
Component Properties" table 2-10 has an error:

{interface fault} The Interface Component corresponding to the actual value
of the ref attribute information item.

should say:

{interface fault} The InterfaceFault Component corresponding to the actual
value of the ref attribute information item.

Transition history

raised on 9 Oct 2005 by John Kaputin (KAPUTIN@uk.ibm.com)

agreed on 20 Oct 2005

Proposal accepted.

Acknowledgment cycle

announced by group on 3 Nov 2005

Action history

LC356: Comments on WSDL 2.0 (Core, Adjuncts, Soap 1.1 Binding) from the i18n core wg (2) [link to this issue]

In sec. 2.1.2 you write: "The value of the targetNamespace attribute information item SHOULD be a dereferenceable IRI (see [IETF RFC 3987])." In sec. 2.1.2.1 you write: "The type of the targetNamespace attribute information item is xs:anyURI. Its value MUST be an absolute IRI (see [IETF RFC 3987])." Why do you have a SHOULD vs. a MUST? If the SHOULD is because of "dereferencable", I would propose: "The value of the targetNamespace attribute information item MUST be an IRI (see [IETF RFC 3987]) and SHOULD be dereferenceable."

Transition history

raised on 9 Oct 2005 by Felix Sasaki (fsasaki@w3.org)

agreed on 20 Oct 2005

Proposal accepted.

Acknowledgment cycle

announced by group on 14 Nov 2005

Action history

LC357: Comments on WSDL 2.0 (Core, Adjuncts, Soap 1.1 Binding) from the i18n core wg (3) [link to this issue]

In Core: On reference of xs:anyURI: It would be good if you could mention that although xs:anyURI allows for IRIs (see LC74a), the mapping from IRI to URI in xs:anyURI is currently not defined in terms of IRI. This comment relates also for example to the reference of xs:anyURI in sec. 2.1.2.1 and sec. 3.1.2.1, and to the Adjuncts specification.

Transition history

raised on 9 Oct 2005 by Felix Sasaki (fsasaki@w3.org)

agreed on 10 Nov 2005

Add "Note: The xs:anyURI type is defined so that xs:anyURI values are essentially IRIs [RFC 3987]. The conversion from xs:anyURI values to an actual URI is via an escaping procedure defined by [XLink 1.0], which is identical in most respects to IRI Section 3.1. For interoperability, WSDL authors are advised to avoid the characters "<", ">", '"', space, "{", "}", "|", "\", "^", and "`", which are allowed by the xs:anyURI type but disallowed in IRIs.

Acknowledgment cycle

announced by group on 14 Nov 2005

agreement by reviewer on 15 Nov 2005

agreement agreement by reviewer on 15 Nov 2005

Action history

LC358: Comments on WSDL 2.0 (Core, Adjuncts, Soap 1.1 Binding) from the i18n core wg (4) [link to this issue]

Core sec. C.2, Binding sec. 2.4 Some examples need better formatting.

Transition history

raised on 9 Oct 2005 by Felix Sasaki (fsasaki@w3.org)

agreed on 20 Oct 2005

Proposal accepted.

Acknowledgment cycle

announced by group on 14 Nov 2005

Action history

LC359: binding fault property placement inconsistencies [link to this issue]

Hi all,

while working on the RDF binding, I've noticed an inconsistency in where
fault properties are placed in bindings: 

SOAP binding puts wsoap:code and subcodes and wsoap:header on binding
fault, and the same does HTTP mapping with whttp:code and whttp:header.
This basically shows that most specific binding fault properties are put
on the bindings faults.

Inconsistently, HTTP binding puts whttp:transferCoding on the fault
reference within operations - do we have a use case for different
transferCodings for the same faults when used in different operations?
If not, I suggest that transferCoding is moved from operation/infault
and outfault to binding/fault.

Transition history

raised on 9 Oct 2005 by Jacek Kopecky (jacek.kopecky@deri.org)

agreed on 20 Oct 2005

Proposal accepted.

Acknowledgment cycle

announced by group on 3 Nov 2005

Action history

LC360: describing a service that returns an image/jpg (for example) [link to this issue]

Consider a service that takes a URI and returns a picture. 

Input message:

<element name="input">
  <complexType>
    <sequence>
      <element name="id" type="xsd:string"/>
    </sequence>
  </complexType>
</element>

Output message:

<element name="output">
  <complexType>
    <sequence>
      <element name="image" type="xsd:base64"
               xmime:expectedContentType="image/*"/>
    </sequence>
  </complexType>
</element>

Operation:

<operation name="gimme-image"
           style="style/iri style/one-binary-thing">
  <input message="tns:input"/>
  <output message="tns:output"/>
</operation>

Note that the use of the style "style/iri" on /operation effectively
constrains the input element. The addition of the style
"style/one-binary-thing" constrains the output schema to be of the
pattern above: exactly one child in the sequence and it must be declared
as xsd:base64 along with the xmime:expectedContentType attribute.

And now the all important binding:

<binding name="foo" interface="..">
  <operation name="gimme-image" whttp:operation="GET"
        whttp:outputSerialization="image/jpg"/>
</binding>

When we document the "one-binary-thing" style we say that that if that
style is used then the output serialization must be set to something
that conforms to the expected content type given in the schema.

This obviously needs to be spec'ized to become real, but is it really
that simple?

Sanjiva.

Transition history

raised on 13 Oct 2005 by Sanjiva Weerawarana (sanjiva@opensource.lk)

declined on 10 Nov 2005

Close with no action (see also LC304).

Acknowledgment cycle

announced by group on 14 Nov 2005

agreement by reviewer on 15 Nov 2005

LC361: What should be declared as a Fault in a WSDL [link to this issue]

I am trying to get a clear understanding of what actually should be 
declared as a fault in the WSDL.  Looking at the various types of things 
that could occur, some based on recent proposals, it appears there could 
be:
1. Anomalies specific to the operation to be performed such as the 
client failing to supply a mandatory value.
2. A generic anomaly such as the XML data supplied to the client being 
malformed.
3. A generic anomaly such as the faults described in the WS-Addressing 
proposal.
4. A generic anomaly such as an inconsistent SOAP envelope "Client" 
soapFault ( Basic Profile R2724 ).
6. An HTTP 4xx error.
7. An HTTP timeout.

Should the WSDL only declare Faults for the cases covered by (1)? The 
argument for this would be that the abstract WSDL defines the Operation 
and others are generic, existing for all operations, and for 4, 5, and 6 
the particular "faults" depend on the protocols of the bindings and if 
multiple bindings were used would be different for each case.

The use of an In-Only mode for an operation would also appear to require 
that the lower level faults are not explicitly declared for the 
operation as that would appear to violate the rules for declaring an 
In-Only operation.

For example say there is an op where the service reserves the right to 
discard calls in busy periods without telling the client that a discard 
has occurred.  This is best defined in the WSDL as an In-Only MEP op. 
Now Basic Profile R2724 still requires a SOAP fault be sent back if the 
SOAP envelope is corrupt, even if you wanted to you can't decide not to 
do this because the op is In-Only as the corruption may mean you can't 
identify which op was invoked.  So in the WSDL the op has no faults 
because it is In-Only but in fact the consumer can receive SOAP faults ( 
and possibly WS-* faults ).

So this seems to me that there are explicit Faults declared for the 
operation and implicit faults resulting from the binding to WS-* 
protocols, SOAP and so on.  There seem to be two issues here:
1. How are the implicit faults defined / listed?  Should this be part of 
the definition of the binding?
2. What about cases where WSDLs are used as input to toolkits, is there 
a separate binding-independent set of explicitly declared Faults and a 
concrete binding-dependent set of faults that have to be derived or put 
in a derived concrete WSDL that can have Faults even in In-Only ops or 
that converts the In-Only to an In-Optional-Fault pattern?

Any help in clarifying whether I am completely off track here would be 
much appreciated.

Transition history

raised on 31 Oct 2005 by Neil Hudson (nahudson@sqc.co.uk)

agreed on 10 Nov 2005

Text at http://lists.w3.org/Archives/Public/www-ws-desc/2005Nov/0017.html accepted.

Acknowledgment cycle

announced by group on 14 Nov 2005

Action history

LC362: Re: new section 2.4.1.1 [link to this issue]

In Part 1 we refer to the fault propagation 
rulesets (FPR) by names like "message-triggers-fault" but these names are 
not used in Part 2, i.e. Part 2 just says "Message Triggers Fault". Also, 
FPRs are an extension point. Should we introduce IRIs for the FPRs? These 
IRIs wouldn't appear in any WSDL 2.0 document. However, it seems 
consistent to use IRIs for them since we do this for other extension 
points. The MEP templates have a slot [fault ruleset reference] which 
would be used to specify the IRI for the FPR. The obvious choices for the 
IRIs are:

http://www.w3.org/2005/08/wsdl/fault-replaces-message
http://www.w3.org/2005/08/wsdl/message-triggers-fault
http://www.w3.org/2005/08/wsdl/no-faults

These would tie in better with the names we use in Part 1.

Transition history

raised on 1 Nov 2005 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 10 Nov 2005

Proposal accepted.

Acknowledgment cycle

announced by group on 14 Nov 2005

Action history

LC363: WSDL message to SOAP message mapping [link to this issue]

This is *not* by any means a spec-ready proposal, but I'm sending it so
we can discuss general direction, and perhaps move forward modulo
editorial work.




5.11.3 Binding WSDL MEPs to SOAP MEPs

This section briefly describes the relationships between WSDL components
and SOAP 1.2 MEP properties as described in {SOAP 1.2 Part 2}.  We
define these relationships for the WSDL {in-out} pattern bound to a SOAP
{request-response MEP} (as would be the case for a usual SOAP In-Out
operation).  Extensions (such as {WS-Addressing}) MAY alter these
mappings.

5.11.3.1 The Client

As the client, the property
"http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role"
takes the value "RequestingSOAPNode".

The WSDL "In" message is mapped to the SOAP
"http://www.w3.org/2003/05/soap/mep/OutboundMessage" property.

The WSDL "Out" message maps to the SOAP
"http://www.w3.org/2003/05/soap/mep/InboundMessage" property.

5.11.3.2 The Service

As the service, the property
"http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role"
takes the value "RespondingSOAPNode".

The WSDL "In" message is mapped to the SOAP
"http://www.w3.org/2003/05/soap/mep/InboundMessage" property.

The WSDL "Out" message maps to the SOAP
"http://www.w3.org/2003/05/soap/mep/OutboundMessage" property.

Transition history

raised on 10 Nov 2005 by Glen Daniels

agreed on 11 Nov 2005

Proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2005Nov/0022.html accepted, plus sentence on extensions from original proposal.

Acknowledgment cycle

announced by group on 14 Nov 2005

Action history