WSDL 2.0 Second Last Call Issues List

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 b