WSDL 2.0 Candidate Recommendation Issues List

CR001: Suggestion Summary appendix? [link to this issue]

The WSDL 2.0 spec contains many suggestions. I'd like to propose that an 
appendix that captures the suggestions be created. This appendix will be 
similar to appendix E: assertion summary currently being created for the 
assertions. I'll propose the name "Suggestion Summary".

This appendix may be useful to WSDL 2.0 parsers that wish to include the 
suggestions outlined in the WSDL 2.0 spec on validation reports for WSDL 
2.0 instance documents. I see the suggestions being displayed as warnings 
on validation reports.

I've included below five sample suggestions from the WSDL 2.0 spec. For 
each entry I've listed a suggested id (I've used the same structure as for 
the assertions but prefixed the assertion number with the letter S), the 
suggestion, and the location of the suggestion in the spec.: 

description-S0001 
Section 2.1.2
The value of the targetNamespace attribute information item SHOULD be a 
dereferenceable IRI (see [IETF RFC 3987])

interface-fault-S0002 
Section 2.3.1
For the above reason, it is considered good practice to ensure, where 
necessary, that the local name of the {name} property of Interface Fault 
components within a namespace are unique, thus allowing such derivation to 
occur without inadvertent error.

interface-operation-S0003 
Section 2.4.1
For the above reason, it is considered good practice to ensure, where 
necessary, that the {name} property of Interface Operation components 
within a namespace are unique, thus allowing such derivation to occur 
without inadvertent error.

feature-ref-S0004
Section 2.7.1
This IRI SHOULD be dereferenceable to a document that directly or 
indirectly defines the meaning and use of the Feature that it identifies.

property-ref-S0005 
Section 2.8.1
This IRI SHOULD be dereferenceable to a document that directly or 
indirectly defines the meaning and use of the Property that it identifies.


Lawrence Mandel

Software Developer
IBM Rational Software
Phone: 905 - 413 - 3814   Fax: 905 - 413 - 4920
lmandel@ca.ibm.com

Transition history

raised on 17 Nov 2005 by Lawrence Mandel (lmandel@ca.ibm.com)

agreed on 8 Dec 2005

Agreed, using the same number space and using an attribute in the markup to indicate the SHOULD-ness.

Acknowledgment cycle

announced by group on 16 Mar 2006

agreement by reviewer on 16 Mar 2006

Action history

CR002: Do <import> and <include> support extensibility elements? [link to this issue]

I'd like to clarify which WSDL elements support extensibility elements.

Part 1, section 6.1 Element based Extensibility states:
WSDL 2.0 allows namespace-qualified *element information item*s whose
[namespace name] is NOT "http://www.w3.org/@@@@/@@/wsdl" to appear among the
[children] of specific *element information item*s whose [namespace name] is
"http://www.w3.org/@@@@/@@/wsdl".

The word 'specific' suggests some WSDL elements do not support extensibility
elements. This is backed up by the WSDL 2.0 schema at
http://www.w3.org/2005/08/wsdl/wsdl20.xsd which indicates that all
WSDL 2.0elements except <import> and <include> support extensibility
elements.

However, in Part 1 all of the sections that describe the xml representation
for each WSDL element state that the [children] of the WSDL element may
contain:
Zero or more namespace-qualified *element information item*s whose
[namespace name] is NOT "http://www.w3.org/@@@@/@@/wsdl"

i.e. this text applies to <include> and <import> too, in sections 4.1 and
4.2, which seems to contradict the schema.

Is this correct? Can <include> and <import> have extensibility elements?

Thanks,
John Kaputin.

2005-12-08: Partial resolution: change the schema to make the elements extensible.

Transition history

raised on 4 Dec 2005 by John Kaputin (gmail) (jakaputin@gmail.com)

agreed on 26 Jan 2006

Closed with proposal and proposal.

Acknowledgment cycle

announced by group on 16 Mar 2006

Action history

CR003: wsdl20-adjuncts vs RFC 4288 [link to this issue]

http://www.w3.org/TR/2005/WD-wsdl20-adjuncts-20050803 apparently
encourages use and implementation of media types that are discouraged
per RFC 4288 section 3.4. I don't think it is appropriate to do this,
the document should be changed such that it does not encourage in-
appropriate use of media types.

Transition history

raised on 13 Dec 2005 by Bjoern Hoehrmann (derhoermi@gmx.net)

declined on 26 Jan 2006

Closed with no action - based on Hugo's rationale.

Acknowledgment cycle

announced by group on 16 Mar 2006

CR004: <appInfo> for the WSDL [link to this issue]

Would it be good to have an explicit <appInfo> for the <documentation>
node for the WSDL 2.0 document?

Transition history

raised on 13 Jan 2006 by Ramkumar Menon (ramkumar.menon@gmail.com)

declined on 26 Jan 2006

Closed with no action: we have an open content model and the benefits of a closed model+appinfo have are not apparent (even after several years of deployment of this model in XSD).

Acknowledgment cycle

announced by group on 16 Mar 2006

agreement by reviewer on 12 Mar 2007

CR005: Built in XML Schema types [link to this issue]

While working on the Woden implementation of the WSDL 2.0 component model 
I came across an implementation detail that isn't spelled out in the spec. 
I'd like some input from the working group.

Section 3.1 of the WSDL 2.0 spec states that the XML schema types are 
built in to WSDL 2.0 and do not have to be imported. Should these types be 
available from the type definitions within the Description component? i.e. 
In a WSDL 2.0 component model implementation, should I be able to access 
these types from the type definitions on the Description component?

Transition history

raised on 17 Jan 2006 by Lawrence Mandel (lmandel@ca.ibm.com)

agreed on 16 Feb 2006

Accept R2 from Arthur's proposals.

Acknowledgment cycle

announced by group on 16 Mar 2006

Action history

CR006: Correction for assertion BindingFault-0058 [link to this issue]

The BindingFault-0058 assertion contains an error. The class is specified 
as compoent. It should be component. I've attached a patch that corrects 
the assertion class.

Transition history

raised on 17 Jan 2006 by Lawrence Mandel (lmandel@ca.ibm.com)

agreed on 26 Jan 2006

Accepted.

Acknowledgment cycle

announced by group on 16 Mar 2006

CR007: Assertion required for property <constraint> [link to this issue]

See - Part 1, 3.1.3 References to Element Declarations and Type Definitions

The assertions include the following rule from this section about the
'element' attribute of  <fault>, <input> and <output>:
Schema-0020. An element attribute information item MUST NOT refer to a
global xs:simpleType or xs:complexType definition.†

I think there's a similar assertion that needs to be captured in the next
paragraph:
A constraint attribute information item MUST NOT refer to a global
xs:element definition.

....although the text needs to be corrected to reflect that constraint is a
child element of <property>, not an attribute, and it's the QName within
<constraint> that must not refer to a global xs:element declaration.

Transition history

raised on 21 Jan 2006 by John Kaputin (gmail) (jakaputin@gmail.com)

agreed on 27 Feb 2006

Accept Roberto's proposal.

Acknowledgment cycle

announced by group on 16 Mar 2006

objection from reviewer on 17 Mar 2006

objection incorporated by group on 16 Apr 2006

Completed implementation.

Action history

CR008: Web Services Description Language (WSDL) Version 2.0 SOAP 1.1 Binding: example @ section 2.4 [link to this issue]

Web Services Description Language (WSDL) Version 2.0 SOAP 1.1 Binding: 
example @ section 2.4 still uses
WSDL 1.1 element <wsdl::definitions...> instead of  <wsdl::description...> .

Transition history

raised on 10 Jan 2006 by david.vanderfeesten@alcatel.be (david.vanderfeesten@alcatel.be)

agreed on 26 Jan 2006

Agreed.

Acknowledgment cycle

announced by group on 16 Mar 2006

Action history

CR009: SOAP binding: empty SOAP Action [link to this issue]

Our specification says, for specifying SOAP Action[2]:

  {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 for the initial message of the message exchange pattern of
  the Interface Operation bound, as specified in the binding rules of
  bindings to specific versions of SOAP (see 5.10.3 SOAP 1.2 Binding
  Rules for the SOAP 1.2 binding when the value of the {soap version}
  property of the Binding component is "1.2").

I.e., it doesn't allow an empty string as the value for {soap action}.

However, in SOAP 1.1, SOAPAction may be equal to ""[3], and the WS-I
BP 1.0 does allow it[1], which actually seems to be looser than what
WSDL 1.1 allows[4], but that's another story.

So I think that, in order to cover all the cases, we should allow the
empty string for {soap action} in addition to an absolute IRI.

SOAP 1.2 is not clear about whether an empty string is allowed or
not[5]. As it's not forbidden and "" is part of the value space of
xs:anyURI, I think it's fine.

So, for a concrete suggestion, I would like to proposed:

  {soap action} OPTIONAL. A xs:anyURI, which is an absolute IRI as
  defined by [IETF RFC 3987] *or an empty string*, to the Binding
  Operation component.

Cheers,

Hugo

  1. http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#Describing_SOAPAction
  2. http://www.w3.org/TR/2006/CR-wsdl20-adjuncts-20060106/#soap-operation-decl-relate
  3. http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383528
  4. http://www.w3.org/TR/2001/NOTE-wsdl-20010315#_soap:operation
  5. http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#ActionFeature

Transition history

raised on 8 Feb 2006 by Hugo Haas (hugo@w3.org)

agreed on 27 Feb 2006

Replace [quoted string value] with [quoted empty string value ("")].

Acknowledgment cycle

announced by group on 16 Mar 2006

Action history

CR010: Typo in HTTP binding [link to this issue]

In the HTTP binding, in section 6.8.1.1 Construction of the request
IRI using the {http location} property:

  Strings enclosed within single curly braces MUST be element names
  from the instance data of the input message, possibly followed by a
  slash; any other strings enclosed within single curly braces are a
  fatal error.

"possibly followed by a slash" is a remainder of the {foo/} notation
which is not in the specification anymore and should therefore be
removed.

Transition history

raised on 9 Feb 2006 by Hugo Haas (hugo@w3.org)

agreed on 27 Feb 2006

Accepted.

Acknowledgment cycle

announced by group on 16 Mar 2006

Action history

CR011: CR Comment on WSDL Version 2, part 2: Adjuncts [link to this issue]

I would like to make a CR comment regarding the Adjuncts document  
<http://www.w3.org/TR/2006/CR-wsdl20-adjuncts-20060106>. I am CC:ing  
the TAG, as custodians of the Web Architecture document.

The WSDL Adjuncts includes a "HTTP Binding" in section six. While the  
binding developed by the group is much better than previous WSDL- 
based efforts, I am very concerned that it still may harm the Web.

In particular;

* There is little HTTP expertise in the Working Group; it is composed  
primarily of Members whose interest is in enterprise messaging, not  
Web-scale systems. Individual Participants have expressed interest,  
but often don't have the full support of their Members (see next point).

* There are few (if any?) implementations of section six.

* The Working Group has not seriously explored the space of use cases  
for HTTP/Web description; there are no Web-centric use cases in their  
Scenarios document <http://www.w3.org/TR/ws-desc-usecases/>. This  
reflects the RPC/SOA focus of WG Members.

* The requirements, use cases and usage scenarios for Web description  
-- even outside the WSDL WG -- are still poorly understood.

* It is not at all clear that a format optimised describing RPC and  
SOA services is also appropriate for describing Web resources. WSDL  
has a many-operations, few-services bias; the Web is about a  
constrained number of operations (methods) over a large number of  
services (resources). As such, while it may be technically possible  
to express many Web idioms in WSDL, it will not be easy to do so,  
because WSDL is designed to encourage good RPC and SOA practice, not  
good practice on the Web (as documented by the Architecture of the  
World Wide Web). This is because the Web (or REST, if you must) is  
based on a completely different abstraction; stateful resources, not  
messaging.

* Even a cursory glance through section six shows a number of places  
where WSDL is mis-aligned with HTTP and the Web; a few (and this is  
by no means a complete list) include;

- Section 6.4 betrays a lack of understanding of how HTTP versioning  
works; there is no good reason to put this information in a  
description. See RFC2145.

- Section 6.6 constrains the data model of HTTP header field-values  
to XML Schema simple types. This is an unnecessary and crippling  
restriction; while those who are looking at the Web through a Web  
Services toolkit may not mind, it's bad for the rest of the Web.

- Section 6.6.6 puts all HTTP headers in a WSDL-specific namespace,  
thereby fracturing it from other efforts to uniquely identify HTTP  
headers.

* Section 6.9 specifies a mechanism for advertising transfer coding  
support, even though this is a hop-by-hop and dynamically negotiated  
facility. If an intermediary is interposed, this information will  
become useless and potentially harmful.

- Section 6.10 encourages the use of cookies, which makes HTTP  
interactions stateful, thereby losing substantial benefits of the Web.

* Section six fails to take into account more complete and mature  
efforts surrounding HTTP, such as WebDAV (e.g., the property model,  
WebDAV ACLs, collections), making it difficult to accommodate this  
work later.

Section six may very well be still-born; there are few (if any?)  
implementations, and already there are several Web-specific  
description format proposals available (many authored by WG  
participants themselves!). However, it still concerns me, because I  
have seen a few instances where well-meaning architects reference it,  
assuming that a W3C Recommendation-to-be is of high quality and will  
be widely implemented.

My concern is that a W3C Recommendation that purports to describe the  
Web may gain momentum because of its status alone. It may make  
development and deployment of a Web-friendly description format in  
the future more difficult. It may constrain the development of new  
(and the deployment of existing) Web capabilities and specifications  
("You can't do that; it doesn't fit into WSDL well."). These risks,  
in my judgement, are not outweighed by the benefits of section six,  
especially considering the low level of interest in it.

Generally, it would also be a shame if the W3C -- an organisation  
dedicated to "Leading the Web to its full potential" -- were to  
Recommend something so unsuited to the Web. I realise that some  
Participants in the Working Group have spent considerable time on  
this part of WSDL, and I don't mean to diminish their contribution.  
However, that effort is sunk cost, and decisions must be based upon  
future value, not past effort.

Therefore, I request that section six be deleted from the Adjuncts  
document.

Transition history

raised on 14 Feb 2006 by Mark Nottingham (mnot@mnot.net)

agreed on 27 Feb 2006

  HTTP version:
    RESOLUTION: remove section 6.4 and associated editorial work
  HTTP headers/simple types:
    RESOLUTION: we'll reject that particular comment, not make any change.
                It is not clear what other types Mark thinks are 
                appropriate. This is not a general http header description 
                language.
  Section 6.6.6 puts all HTTP headers in a WSDL-specific namespace:
    RESOLUTION: what we identify here is components as opposed to header, we
                use the restriction of wsdl which says that one component 
                per http header and we use this restriction to identify the 
                component with the header name but we do not identify the 
                header.
  Transfer Coding useless and potentially harmful
    RESOLUTION: keep transfer-encoding
  Cookie warning:
    RESOLUTION: No action.
  WebDAV:
    RESOLUTION: Have extensibility or separate binding, or use a different
                Language.

Acknowledgment cycle

announced by group on 27 Mar 2006

objection from reviewer on 27 Mar 2006

Action history

CR012: Semantics of wsdl:import [link to this issue]

I am attaching the snippet from section 5.1.2 from WS-I Basic Profile 1.0
R2001 A DESCRIPTION MUST only use the WSDL "import" statement to import
another WSDL description.
R2002 To import XML Schema Definitions, a DESCRIPTION MUST use the XML
Schema "import" statement.
R2003 A DESCRIPTION MUST use the XML Schema "import" statement only within
the xsd:schema element of the types section.

Moreover, the section 4.1 in WSDL 2.0 2.0 Part 1 [Core Language] makes a
clear statement regarding the point about "Including descriptions". See
below.
"A location *attribute information item* is of type xs:anyURI . Its actual
value is the location of some information about the namespace identified by
the targetNamespace *attribute information item* of the containing
description *element information item*.It is an error if the IRI indicated
by location does not resolve to a WSDL 2.0 document."

If I am right, it would be necessary to make a similar and explicit
statement on  "import descriptions".[Section 4.2]

Transition history

raised on 14 Feb 2006 by Ramkumar Menon (ramkumar.menon@gmail.com)

agreed on 27 Feb 2006

Text fixed since CR publication addresses this issue.

Acknowledgment cycle

announced by group on 16 Mar 2006

CR013: Relax IRI style cardinality [link to this issue]

Proposing the relevant part of Hugo's mail as a CR issue.

-----Original Message-----
From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
Behalf Of Hugo Haas
Sent: Tuesday, February 14, 2006 2:39 AM
To: www-ws-desc@w3.org
Subject: Belated comments on SPARQL Protocol for RDF 25 January 2006 LC
WD

Following Jonathan's email[6], I looked at the WSDL 2.0 use made in
SPARQL Protocol for RDF:

    SPARQL Protocol for RDF
    W3C Working Draft 25 January 2006
    http://www.w3.org/TR/2006/WD-rdf-sparql-protocol-20060125/

...

- "The sequence MUST contain only local element children. These child
  elements MAY contain the nillable attribute, and the attributes
  minOccurs and maxOccurs MUST have a value 0 or 1."

  This one is more of a problem. Having more than one element in the
  instance data with the same local name is something that we have
  never allowed as we wanted to be sure we could reconstruct the
  instance data accurately. We actually have another related
  restriction: "The sequence MUST NOT contain multiple children
  elements declared with the same local name."

  The problem is that if you have whttp:location="{b}" and the
  instance data is "<a><b>2</b><b>1</b></a>", we do not know which b
  element we are talking about. This is a limitation of our syntax.

  So they actually can't do that. The problem comes from the
  maxOccurs="unbounded" of the default-graph-uri and named-graph-uri
  attributes.

  It turns out that their use does not have the micro-syntax problem
  as default-graph-uri and named-graph-uri will be serialized as query
  parameters, but it is not very simple to allow IMO.

  It looks like this actually was already in their first draft and we
  missed it in our first review. We should probably engage in a
  discussing with the DAWG as I don't see any simple fix.

...

Cheers,

Hugo

  1.
http://www.w3.org/TR/2006/WD-rdf-sparql-protocol-20060125/#query-binding
s-http
  2.
http://www.w3.org/TR/2006/CR-wsdl20-adjuncts-20060106/#_http_x-www-form-
urlencoded
  3.
http://www.w3.org/TR/2006/WD-rdf-sparql-protocol-20060125/#SparqlQuery
  4.
http://www.w3.org/TR/2006/CR-wsdl20-adjuncts-20060106/#_operation_iri_st
yle
  5.
http://www.w3.org/TR/2006/WD-rdf-sparql-protocol-20060125/#query-binding
s-soap
  6. http://lists.w3.org/Archives/Member/w3c-ws-desc/2006Feb/0004.html
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/

Transition history

raised on 17 Feb 2006 by Jonathan Marsh (jmarsh@microsoft.com)

agreed on 27 Feb 2006

Accept proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2006Feb/0061.html.

Acknowledgment cycle

announced by group on 16 Mar 2006

Action history

CR014: CR ISSUE: Bug in SOAP binding (Section 5.5.2 of Adjuncts) [link to this issue]

As mentioned in today's F2F meeting, I would like to raise the following
issue against the Adjuncts document...

Section 5.5.2 [1] currently states that the {soap underlying protocol}
property contains an IRI *to the Binding component*.  This is not
correct, and in fact I believe we meant to say something along the lines
of:

--- begin ---

A xs:anyURI, which is an absolute IRI as defined by [IETF RFC 3987].
This IRI refers to an appropriate SOAP underlying protocol binding (see
[SOAP Binding Framework]), which is to be used for any of the SOAP
interactions described by the WSDL Binding.

---- end ----

I propose we fix this by using the above text (with editorial
discretion).

[1] http://www.w3.org/TR/2006/CR-wsdl20-adjuncts-20060106/#soap-protocol-relate

Transition history

raised on 27 Feb 2006 by Glen Daniels (gdaniels@sonicsoftware.com)

agreed on 27 Feb 2006

Accept proposal.

Acknowledgment cycle

announced by group on 16 Mar 2006

Action history

CR015: value space of "extends" attribute Info Item [2.2.2.2 WSL 2.0 Core Language] [link to this issue]

Section 2.2.2.2 of WSDL 2.0 Core Language quotes
"The type of the extends *attribute information item* is a list of *xs:QName
*.".

Would it be better to explicitly mention that the type is list of QNames
that are "whitespace separated", or the fact that the "list" used here is
congruent with the "list" type as per XML Schema.
Am I missing something here ?

Transition history

raised on 27 Feb 2006 by Ramkumar Menon (ramkumar.menon@gmail.com)

agreed on 27 Feb 2006

Add in section 2.16 that list means whitespace separated "things".

Acknowledgment cycle

announced by group on 30 Aug 2006

Action history

CR016: wrpc:signature for RPC style [link to this issue]

I had a question on the wrpc:signature extension. [section 4.1.1 - WSDL 2
Part 2:Adjuncts], in conjunction with usage of XSD substitution Groups.
In the RPC signature for the operations, would it be better in terms of
clarity, to allow specification of substitution group members in place of
the head elements, esp., in the scenario where the latter are defined to be
abstract in the type system ?

Illustrating with an example.....

<types>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="
http://www.example.org"   targetNamespace="http://www.example.org"
            elementFormDefault="qualified">
  <xsd:element name="InfoProduct" type="ProductType"/>

  <xsd:complexType name="ProductType">
    <xsd:sequence>
      <xsd:element ref="Code"/>
    </xsd:sequence>
  </xsd:complexType>

  <xsd:element name="Code" type="CodeType"/>
    <xsd:element name="ProductCode" substitutionGroup="Code">
    <xsd:complexType>
      <xsd:complexContent>
        <xsd:extension base="CodeType">
          <xsd:attribute name="zone" type="xsd:string"/>
        </xsd:extension>
      </xsd:complexContent>
    </xsd:complexType>
  </xsd:element>

  <xsd:complexType name="CodeType">
      <xsd:sequence>
        <xsd:element name="organization" type="xsd:string"/>
        <xsd:element name="value" type="xsd:string"/>
      </xsd:sequence>
    </xsd:complexType>

</xsd:schema>
</types>

Can I define my operation rpc signature to be

<interface .....>
   <operation name="ProductSearch" ....
         wrpc:signature="*ProductCode*" #in >   *<!-- "ProductCode" can
substitute "Code" as per schema -->*
       <input messageLabel="In" element="sch:InfoProduct"/>
    </operation>

rather than

<interface .....>    <operation name="ProductSearch" ....
         wrpc:signature="*Code*" #in >
       <input messageLabel="In" element="sch:InfoProduct"/>
    </operation>

The scenario becomes even more practical when the element "Code" is defined
as "abstract" in the XSD, and ProductCode/some other element is defined to
always substitute the "Code" element in the isntance..
So, the statement could be something like
"If the type system defines an element to be abstract in the definition, and
such elements are used for defining message structures within the WSDL
definition, then the rpc signature could optionally hold/substitute those
elements with alternate element definitions that are defined to be
substitutable for the former, as per the type system. "

Transition history

raised on 25 Feb 2006 by Ramkumar Menon (ramkumar.menon@gmail.com)

declined on 16 Mar 2006

Closed with no action, per this rationale.

Acknowledgment cycle

announced by group on 16 Mar 2006

agreement by reviewer on 12 Mar 2007

CR017: Action Item 2006-02-16 [link to this issue]

We decided to allow extension attributes that are not part of the
signature for RPC style. I noticed that neither the IRI style nor the
multipart style have a similar allowance. I believe we included this
allowance to RPC style to put metadata assertions as attributes for the
signature. Similar metadata may be useful for the other styles, but I do
not have any use cases.

Transition history

raised on 28 Feb 2006 by Yalcinalp, Umit (umit.yalcinalp@sap.com)

declined on 16 Mar 2006

RPC is different than IRI or multipart in that the extension attributes won't appear in the message. There is therefore no utility in such attributes, and no positive reason to change the spec at this point.

Acknowledgment cycle

announced by group on 16 Mar 2006

CR018: RE: Review of WS-A WSDL Binding [link to this issue]

I think we could make some editorial improvements re #2. I'm glad the 
intension of the spec is to allow reference to <description> elements, but 
if I as an editor forgot that, then maybe the text is unclear.  Normally, 
when the term "document" is used, it means a complete XML document rooted 
at the "document element".  I looked at the spec and I can't see where we 
define WSDL 2.0 document to be a description element. I suggest we revise 
the spec so that wherever we allow an IRI to a WSDL 2.0 document we change 
it as follows:

"The IRI is the location of a WSDL 2.0 document or a <description> element 
information items within an XML document."

Perhaps put this text in chapter 7 [1] and refer to it from elsewhere in 
the spec.

[1] http://www.w3.org/TR/2006/CR-wsdl20-20060106/#wsdllocation

Transition history

raised on 9 Mar 2006 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 16 Mar 2006

Proposal, and any editorial license required, accepted.

Acknowledgment cycle

announced by group on 30 Aug 2006

Action history

CR019: Must XML schema elements by imported in WSDL 2.0? [link to this issue]

The following question arose while developing Woden [1].

Assertion Schema-0016 (from section 3.1) states:

"A WSDL 2.0 document MUST NOT refer to XML Schema components in a given 
namespace unless an xs:import or xs:schema element information item for 
that namespace is present or the namespace is the XML Schema namespace 
which contains built-in types as defined in XML Schema Part 2: Datatypes 
Second Edition [XML Schema: Datatypes]."

The end of the sentence, "...which contains built-in types..." seems to 
imply that only XML Schema types are implicitly available in WSDL 2.0. Are 
schema elements also implicitly available in WSDL 2.0? For example, if I 
want to define an input as follows

<wsdl:input element="xsd:schema" />

do I need to import the schema namespace?

If the answer is yes, I suggest the assertion text be modified to 
explicitly state that the schema namespace must be imported if schema 
elements are to be used. As a suggestion,
"...XML Schema namespace and an XML Schema type has been referenced. XML 
Schema contains..."
If the answer is no, I suggest the assertion text be modified to make it 
clear that both elements and types are available. As a suggestion,
"...which contains elements and built-in types...".

[1] http://incubator.apache.org/woden

Transition history

raised on 14 Mar 2006 by Lawrence Mandel (lmandel@ca.ibm.com)

agreed on 30 Mar 2006

Add: "If a WSDL 2.0 document refers to any component (element, simple type, complex type, etc) of the http://www.w3.org/2001/XMLSchema namespace except the built-in simple types, then it MUST import http://www.w3.org/2001/XMLSchema."

Acknowledgment cycle

announced by group on 30 Aug 2006

Action history

CR020: Bogus assertions in 3.1.3? [link to this issue]

I was just reviewing the CR issue resolutions wrt. their impact on the
RDF mapping and I noticed what I think are bogus assertions in section
3.1.3 or part 1 [1].

In particular, it says that "An element attribute information item MUST
NOT refer to a global xs:simpleType or xs:complexType definition." and
"A constraint attribute information item MUST NOT refer to a global
xs:element definition."

First, I think that the "an element AII" and "a constraint AII" (should
be EII) should use the definite article "the element AII" and "the
constraint EII" with links to the proper part of the text.

But, I want to say that these assertions should be removed because they
give pose constraints that can never be violated.

In particular, the element AII refers, by definition, to an element
declaration, and in XML Schema the symbol spaces for element
declarations and type definitions are disjoint, therefore the element
AII cannot refer to a type definition. Even if there is a WSDL file that
contains a schema that defines a type ex:foo and declares no element
with such a name, if a message reference has element="ex:foo" on it,
this will result in "element declaration ns:foo not found" problem, not
in "ns:foo is a type defn not an element decl" problem.

Same for the constraint EII, just flip the element decls and type defns.

The assertions are not directly harmful, but indirectly they may confuse
the reader to have the wrong image of how Schema works.

I suggest we simply remove the two assertions from 3.1.3.

Jacek

[1] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-type=text/html;%20charset=utf-8#references-definitions

Transition history

raised on 14 Mar 2006 by Jacek Kopecky (jacek.kopecky@deri.org)

agreed on 16 Mar 2006

Agreed. Editor given license to correct this editorially.

Acknowledgment cycle

announced by group on 30 Aug 2006

Action history

CR021: RE: WSDL describing Interface operation safety [link to this issue]

David and WSD-WG,

Thank you for the update and for respodning to our issue.  The TAG discussed
this on 26th April [1] and actioned me to respond on its behalf.

The TAG is generally pleased with the direction the WSD WG has taken.
However, it wants continue to track this issue through actual deployment and
use of the property. 

We have a small concern about the potential for marking an unsafe operation
as safe, and we would like to encourage the WG to provide some discussion of
potential mis-uses (accidental or malicious). We would also like to
encourage that examples of correct and incorrect use of the property be
included in any test-suites the WG may be working on.

Best regards

Stuart Williams
On Behalf of W3C TAG
[1] http://www.w3.org/2004/04/26-tag-summary.html

> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] 
> On Behalf Of David Orchard
> Sent: 7 April 2004 21:22
> To: www-tag@w3.org
> Cc: www-ws-desc@w3.org
> Subject: WSDL describing Interface operation safety
> 
> 
> Dear TAG,
> 
> On behalf of the WSD Working Group, I would like to inform 
> you of the WSD WGs decision regarding description of safety 
> of operations, part of TAG issue 7.  
> 
> The recently published WSDL 2.0 Part 1: Core WD provides a 
> property called "safety" on interface operations [1].  With 
> this, we believe that we have delivered an appropriate 
> solution to the request to describe the safety of operations.
> 
> We welcome any questions, concerns, or comments regarding the 
> wsdl 2.0 description of safety of operations, including 
> support for our solution.
> 
> Cheers,
> Dave Orchard
> On behalf of the WSD WG.
> 
> [1] http://www.w3.org/TR/wsdl20/#InterfaceOperation
> 

Transition history

raised on 11 May 2004 by Williams, Stuart (skw@hp.com)

agreed on 1 Mar 2007

Report to TAG on our success with the wsdlx:safe extension.

Acknowledgment cycle

announced by group on 2 Mar 2007

CR022: Component Values Must Be Context Independent [link to this issue]

Components can be brought into a component model instance through <import>
and <include>. For scalability purposes, it is highly desirable for the 
value of a component to be independent of the context that it was brought 
it.

The use case is a development tool for SOA applications that needs to 
support hundreds or thousands of services. The tool needs to validate the 
service definitions. The requirement is that the time to do this be 
linear. We are currently experiencing performance problems validating 
large sets of WSDL 1.1 documents. We need to have an spec-compliant 
optimization for WSDL 2.0.

Ideally, a tool should be able to compute the components directly defined 
in a document without looking at any of the imports or includes. There are 
two problems now that prevent this:

1. In theory, we allow extensions that could alter the semantics of 
imported or included components. However, there is no requirement or use 
case for this flexibility, much less a realistic, compelling one. Note 
that this is actually a real problem in XML Schema, e.g. due to "features" 
such as cameleon includes, and <redefine>, you need to know the context in 
which a document is included.

2. The current definition of component equivalence is recursive in the 
sense that to test if two components are equivalent, it is necessary to 
determine if all of the components they refer to are equivalent. In effect 
this means that you have to construct the entire component model instance 
in order to resolve the references to the other components.

Since WSDL documents typically include or import others, a collection of 
WSDL documents is likely to be moderately connected when viewed as a 
graph. Therefore, when you validate the collection, you end up processing 
a given document many times in general. You process it a number of times 
equal to the number of documents that refer to it directly or indirectly 
(+ 1). This is non-linear. The exact degree of non-linearity depends on 
how connected the graph is. Consider a simple chain of n WSDL documents.

A1 includes A2 includes A3 includes ... An

Validating A1 requires reading n documents.
Validating A2 requires reading n-1 documents.
...
Validating An requires reading 1 document.

Therefore validating the whole set of documents requires readiing n + 
(n-1) + ... + 1 = n(n+1)/2 = O(n^2), i.e. this is quadratic, not linear.

On the other hand, if the meaning if each document is independent of how 
it is used then a smart tool could cache the results and only read n 
documents.

The fix is as follows:

1. Add the following assertion. An extension MUST NOT affect the value of 
components that are added to the component model via <import> or 
<include>.
2. State the definition of component equivalence as follows. Two 
components are equivalent when:
A) All of their child components are equivalent.
B) All of their non-component properties are equal.
C) All of their non-child component properties refer to components 
that have the same keys (e.g. names).
The difference is that to test for equivalence, you only have to look at a 
component's value-based properties and child components. You don't have to 
traverse the component graph, which might take you into another document. 
You only have to compare referred to components via their keys.

We then add a statement to each component explicitly stating what its key 
values are. This is straight-forward. We already implicitly defined keys 
when stating uniqueness rules, i.e. each Interface component in a 
Description component must have a unique {name}. The key is usually the 
{name} property. For Features and Properties, it is the {ref} property. 
The complete list is:

1. ElementDeclaration: {name}

2. TypeDefinition: {name}

3. Interface: {name}

4. InterfaceFault: {name}

5. InterfaceOperation: {name}

6. InterfaceMessageReference: {message label}

7. InterfaceFaultReference: {interface fault}.{name}. {message label}

8. Binding: {name}

9. BindingFault: {interfaceFault}.{name}

10. BindingOperation: {interfaceOperation}.{name}

11. BindingMessageReference: {interface message reference}.{message label}

12. BindingFaultReference: {interface fault reference}.{interface 
fault}.{name}, {interface fault reference}.{message label}

13 Service: {name}

14. Endpoint: {name}

15. Feature: {ref}

16. Property: {ref}

In general, any extension component that might be refered to needs to 
define a key value, since that is how the reference is represented in the 
XML serialization.

Transition history

raised on 20 Apr 2006 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 21 Sep 2006

Closed by adopting the proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2006Jul/0079.html, and the proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2006Jul/0080.html, amended as per http://lists.w3.org/Archives/Public/www-ws-desc/2006Jul/0086.html

Acknowledgment cycle

announced by group on 20 Oct 2006

Action history

CR023: typeDefinitions property optional? [link to this issue]

Section 2.1.2 defines the typeDefinitions property as optional, but then
states that it contains the build-in simple types from Schema.  I think
the result is that it's really not optional at all.  Should we change it
to REQUIRED?

Also, we might also mention in the mapping that this is the minimum,
contrary to the minimum suggested there.

Transition history

raised on 3 May 2006 by Jonathan Marsh (jmarsh@microsoft.com)

agreed on 11 May 2006

Change OPTIONAL to REQUIRED, plus other editorial work (esp. in the mapping) to better reflect the presence of the built-in schema types.

Acknowledgment cycle

announced by group on 30 Aug 2006

Action history

CR024: Part 2 Adjuncts Comments (1 -5) [link to this issue]

1. In 4.2 IRI Style, the content model of the initial is constrained to 
have a sequence of child elements. What are the occurrence contraints? Are 
there any?

Transition history

raised on 4 May 2006 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 11 May 2006

Add clarification that there are no occurance constraints.

Acknowledgment cycle

announced by group on 30 Aug 2006

Action history

CR025: Part 2 Adjuncts Comments (1 -5) [link to this issue]

2. In 4.2 IRI Style, the last bullet says: "If the children elements of 
the sequence are defined using an XML Schema type ...". What else could 
they be defined as? Don't all elements have a type?

Transition history

raised on 4 May 2006 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 11 May 2006

Add clarification.

Acknowledgment cycle

announced by group on 30 Aug 2006

Action history

CR026: Part 2 Adjuncts Comments (1 -5) [link to this issue]

3. In 5.3 SOAP Binding Rules, the rule about mustUnderstand seems weak. If 
the SOAP Header block is marked as mustUnderstand=true in WSDL, then 
shouldn't the header in the SOAP message also have mustUnderstand=true?

Transition history

raised on 4 May 2006 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 11 May 2006

strengthen "should" to "MUST".

Acknowledgment cycle

announced by group on 30 Aug 2006

Action history

CR027: Part 2 Adjuncts Comments (1 -5) [link to this issue]

4. In 5.6.2, isn't {soap fault codes} really a set and not a list? The 
order of subcodes is irrelevant and it doesn't make sense to repeat a 
subcode. Sounds like a set. Also, is there a difference between having an 
empty set of subcodes and #any. I assume #any means any subcode may be 
used. Does an empty set mean the subcodes are never used?

Transition history

raised on 4 May 2006 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 11 May 2006

Add clarification along the lines "The value of this property identifies one or more subcodes for this SOAP fault. The list of subcodes is the nested sequence of subcodes, an empty list represents a fault code without subcodes."

Acknowledgment cycle

announced by group on 30 Aug 2006

Action history

CR028: Part 2 Adjuncts Comments (1 -5) [link to this issue]

5. Global comment on organization: Part 1 is organized by component, and 
then by properties within a component. In Part 2 this structure in not 
used. Components and properties are described together. I think it would 
be clearer is we followed the Part 1 organization, i.e. have a section for 
each Core and Extension component involved, then list and describe the 
properties that apply to each compoinent. e.g. 5.7.2 lists a set of 
properties, but some apply to Binding and some apply to Binding Operation 
- sort of confusing I think.

Transition history

raised on 4 May 2006 by Arthur Ryman (ryman@ca.ibm.com)

declined on 11 May 2006

Closed with no action - organization of Part 2 by feature rather than component is desirable. Lots more work at this point isn't.

Acknowledgment cycle

announced by group on 30 Aug 2006

CR029: Part 2 Adjuncts Comments (1 -5) [link to this issue]

6. In 5.7.2 is there any constraint between WSDL meps and SOAP meps, i.e. 
if an operation uses a given WSDL mep, then does that restrict the allowed 
SOAP mep used in the biniding?

Transition history

raised on 4 May 2006 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 8 Jun 2006

Adopt Amy's proposal.

Acknowledgment cycle

announced by group on 30 Aug 2006

Action history

CR030: Part 2 Adjuncts Comments (1 -5) [link to this issue]

7. In 5.7.2 there are defaulting rules for {soap mep} but is a value for 
the actual SOAP mep required, i.e. must the defaulting rules produce a 
definite value?

Transition history

raised on 4 May 2006 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 18 May 2006

Add a reference to 5.10.3, where the "rollup" is specified.

Acknowledgment cycle

announced by group on 30 Aug 2006

Action history

CR031: Part 2 Adjuncts Comments (1 -5) [link to this issue]

8. In 5.8.2 there should be a constraint on {soap modules} that each soap 
module component is uniquely identified by its {ref} property, i.e {ref} 
is a key. No two different soap modules in the {soap modules} property may 
have the same {ref}.

Transition history

raised on 4 May 2006 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 18 May 2006

Add a constraint to 5.8.2 that a soap module on a given binding, {ref} will be unique.

Acknowledgment cycle

announced by group on 30 Aug 2006

Action history

CR032: Part 2 Adjuncts Comments (1 -5) [link to this issue]

9. Similarly, in 5.9.2 there should be a contraints on {soap headers} that 
each soap header component is uniquely identified by is {element 
declaration} property (I assume).

Transition history

raised on 4 May 2006 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 8 Jun 2006

Require {element declaration} to be unique (i.e., can describe at most one header with a given QName.)

Acknowledgment cycle

announced by group on 30 Aug 2006

Action history

CR033: Part 2 Adjuncts Comments (1 -5) [link to this issue]

10. In 5.9.6, the design of the fragment identifier for wsoap.header is 
inconsistent since it represents the element QName as namespace#name. All 
other components use the QName and define the namespace using an xmlns 
pointer part. This should be changed to use QName too, c.f. the element 
declaration component itself.

Transition history

raised on 4 May 2006 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 18 May 2006

Change "namespace#name" to "qname".

Acknowledgment cycle

announced by group on 30 Aug 2006

Action history

CR034: Comments on Part 2, Chapter 6 [link to this issue]

1. In 6. the paragraph:

"As allowed in [WSDL 2.0 Core Language], a Binding component MAY exist 
without indicating a specific Interface component that it applies to. In 
this case, there MUST NOT be any Binding Operation or Binding Fault 
components present in the Binding component."

Is not a new requirement. It reproduces a requirement from Part 1. It 
should contain the keywords MAY, MUST NOT since it is not a new 
requirement. It should be rephrased as a note. It is equivalent to the 
Part 1 assertion:

"If a Binding component specifies any operation-specific binding details 
(by including Binding Operation components) or any fault binding details 
(by including Binding Fault components) then it MUST specify an interface 
the Binding component applies to, so as to indicate which interface the 
operations come from.? " which is Binding-0054. Perhaps include a 
reference to Part 1 here.

Transition history

raised on 6 May 2006 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 18 May 2006

Reword to avoid MUST NOT, add link to part 1.

Acknowledgment cycle

announced by group on 30 Aug 2006

Action history

CR035: Comments on Part 2, Chapter 6 [link to this issue]

2. In 6.3.1 HTTP Method Selection, there is no value specified when all 
the conditions fail. What is the default? I suggest POST.

Transition history

raised on 6 May 2006 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 18 May 2006

Add a fourth bullet to 6.3.1; "Otherwise, the value 'POST'".

Acknowledgment cycle

announced by group on 30 Aug 2006

Action history

CR036: Comments on Part 2, Chapter 6 [link to this issue]

3. In 6.5.3 HTTP Header Component the {type definition} component is 
defined as a QName reference to a Type Definition component. This is 
inconsistent with the way refrences are handled in the Core spec. This 
property should be changed to be a Type Definition component, i.e. the 
resolved value of the QName. Note that Table 6-3 correctly decsribes this 
property as a Type Definition, not a QName.

Transition history

raised on 6 May 2006 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 1 Jun 2006

Change the type of the {type definition} property to a Type Definition Component.

Acknowledgment cycle

announced by group on 30 Aug 2006

Action history

CR037: Comments on Part 2, Chapter 6 [link to this issue]

4. In 6.7 Serialization Format of Instance Data, Table 6-5, why is the 
application/xml the only mime type that can be returned on the output 
message? The other two types might also be useful in outputs. Multipart 
output seems reasonable.  URL encoded output is less likely.

Transition history

raised on 6 May 2006 by Arthur Ryman (ryman@ca.ibm.com)

declined on 6 Jul 2006

Close with no action.

Acknowledgment cycle

announced by group on 30 Aug 2006

CR038: editorial: part 2, table b-1 incomplete? [link to this issue]

Hi, it seems to me that table b-1 [1] in part 2 of WSDL 2.0 CR draft
lacks several of the {* default} properties in the lower part.

Those are {http transfer coding default}, {http query parameter
separator default}, {soap mep default} for Binding, and {http transfer
coding default} for Binding Operation.

Transition history

raised on 7 May 2006 by Jacek Kopecky (jacek.kopecky@deri.org)

agreed on 1 Jun 2006

Stylesheet problem already fixed.

Acknowledgment cycle

announced by group on 30 Aug 2006

CR039: Mentions of "error" and "fatal error" in Part 2 [link to this issue]

As per my action item:

?         2006-03-16: Hugo to check Part 2 for instances of the
terminology "fatal error". 

I looked at part 2, and have replaced those instances by MUST and MUST
NOT sentences.

I did it directly in the draft as it was simpler.

Here is the diff:

http://dev.w3.org/cvsweb/2002/ws/desc/wsdl20/wsdl20-adjuncts.xml.diff?r1=1.160&r2=1.161&f=h

And the final result:

http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.html?rev=1.132&content-type=text/html;%20charset=utf-8

Jonathan, I didn't find a CR issue associated to this. We probably
should have one, and have the WG approve the changes.
						

Transition history

raised on 5 Apr 2006 by Hugo Haas (hugo@w3.org)

agreed on 20 Apr 2006

Agreed.

Acknowledgment cycle

announced by group on 30 Aug 2006

CR040: Comment on Part 2, Section 5.9.3 [link to this issue]

The {element declaration} property of SOAP Header Block is defined as a 
QName but it should be an Element Declaration component.

Transition history

raised on 9 May 2006 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 1 Jun 2006

Change the type of the {element declaration} property to a Element Declaration Component.

Acknowledgment cycle

announced by group on 10 Oct 2006

Action history

CR041: Comment on Part 2, Section 6.5.2 [link to this issue]

In the {http headers} property, is the {name} of the HTTP Header 
component, a key? i.e., is each HTTP Header component in {http headers} 
uniquely identified by it's {name}?

This is implied by 6.5.6 IRI Identification Of An HTTP Header component 
which uses the {name} in the frag id, so it had better be unique.

Transition history

raised on 9 May 2006 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 1 Jun 2006

Add constraint that the {name} is unique within the {http headers} property.

2006-09-14: WG agrees this constraint is already there - dropping the AI.

Acknowledgment cycle

announced by group on 10 Oct 2006

CR042: Re: Uniqueness of QNames in 'extends' attribute [link to this issue]

John,

Thx for the comment. I think that we should require uniqueness of 
interfaces at the XML infoset level since it makes no sense to extend from 
an interface twice. Therefore, a duplicate would be a programming error 
and raising it would be helpful to authors who may have forgotten to edit 
a QName after a copy and paste:

"Each QName in the extends attribute information item MUST be unique."

Arthur Ryman,
----
"John Kaputin (gmail)" <jakaputin@gmail.com> 
Subject
Uniqueness of QNames in 'extends' attribute

When I implemented interface extension in Apache Woden recently I noticed 
that the WSDL 2.0 spec does not say that the QNames in the 'extends' 
attribute of the <interface> element have to be unique, although it seems 
sensible that they should be. Anyway, my implementation just checks for 
duplicate QNames before resolving them to Interface components. 

You may want to add a uniqueness constraint to this section....

2.2.2.2 extends attribute information item
The extends attribute information item lists the interfaces that this 
interface derives from. 
The extends attribute information item has the following Infoset 
properties: 
A [local name] of extends 
A [namespace name] which has no value
The type of the extends attribute information item is a 
whitespace-separated list of xs:QName.

regards,
John Kaputin

Transition history

raised on 19 May 2006 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 1 Jun 2006

Add constraint "The list of QNames in an extends attribute MUST NOT contain duplicates."

Acknowledgment cycle

announced by group on 10 Oct 2006

Action history

CR043: Part 2, 5.6.3 XML Representation of subcodes is inconsistent [link to this issue]

The pseudo BNF of wsoap:sibcodes should be:

union of (list of xs:QName), xs:token

Currently, it omits the xs:token which can take the value #any.

Transition history

raised on 19 May 2006 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 1 Jun 2006

Editorial: fix the pseudo-syntax.

Acknowledgment cycle

announced by group on 30 Oct 2006

Action history

CR044: Parts 1 and 2 Treat Defaults Inconsistently with each other [link to this issue]

In Part 1 the <interface> element has a styleDefault attribute but there 
is no corresponding property in the component model. The styleDefault 
attribute is only used to determine the {style} property on the Interface 
Operation component via the XML mapping rules

However, in Part 2 there are four default attributes and they do get 
mapped to component model properties:
{soap mep default}
{http transfer coding default}
{http method default}
{http query parameter separator default}

These default properties are matched up with corresponding non-default 
properties on the component model:
{soap mep}
{http transfer coding}
{http method}
{http query parameter separator}

The "actual" values of the property in the message are defined by the 
binding rules, not the XML mapping. I find this confusing. It also has the 
disadvantage that it removes the rules from the component model  so the 
component model builder can't evaluate them. It just copies the XML 
attributes into the component model. Instead a message builder has to have 
this logic.

The Part 1 approach makes the component model simpler since the "actual" 
value of the property is computed and stored in the component model.

However, the Part 2 approach is also good because it makes WSDL generation 
simpler. For example, suppose you have the same style on several 
operations. It would be simpler to specify the default in the component 
model and serialize the WSDL with the style ommitted on the operations 
that matched the default.

I propose that we improve the spec by using the best aspects of Part 1 and 
2, and make them consistent. This requires the following changes:

1.In Part 1, add a {style default} property to the Interface component.
2. In Part 2, specify the rules for the properties in the XML mapping 
instead of the message binding, e.g. {http method} is determined by the 
actual value of the attribute if present, or the {http method default} if 
present, or is GET if the operation is safe, and it POST otherwise. This 
way, e.g. {http method} is the actual value used in the message.

Transition history

raised on 19 May 2006 by Arthur Ryman (ryman@ca.ibm.com)

declined on 1 Jun 2006

No substantial change - add rationale for why defaults are necessary in Part 2, i.e. interfaceless bindings.

2006-09-21: Additional editorial work:

• Adopted Roberto's proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2006Sep/0030.html
• Including Roberto's referenced proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2006Jul/0046.html
• Including Jacek's proposal, also referenced at http://lists.w3.org/Archives/Public/www-ws-desc/2006Jul/0046.html
• With JJM's amendments at http://lists.w3.org/Archives/Public/www-ws-desc/2006Sep/0036.html
• And with Charlton's amendments at http://lists.w3.org/Archives/Public/www-ws-desc/2006Sep/0041.html

Acknowledgment cycle

announced by group on 22 Feb 2007

Action history

CR045: Inline schemas with no target namespace [link to this issue]

Section 3.1.2.1 of the Core Langage spec says
"WSDL 2.0 modifies the XML Schema definition of the xs:schema element
information item to make this attribute information item required".

There is a scenario where I have an existing XSD that I am intending
to re-use while designing the WSDL. The XSD has no target namespace,
and has a bunch of elements and attributes defined within it. What it
also does is to import a couple of XSDs that have a non-null target
namespace. the wsdl intends to define the message parts to point to
one of the nodes defined in the imported XSDs within the nonamespace
XSD. The nodes that had been directly defined in the no-namespace XSD
are not used by the WSDL, but are consumed by other applications.
In this case, do yo think that it would be "really" invalid to inline
such an XSD into the WSDL ? I was wondering that atleast
theoretically, this should be possible. The question is - "Do we need
to make some statements around this in the spec" ?

Transition history

raised on 19 May 2006 by Ramkumar Menon (ramkumar.menon@gmail.com)

agreed on 21 Sep 2006

Remove removing assertion #Schema-0019-summary (no requirement schemas have a target namespace.)

Acknowledgment cycle

announced by group on 16 Oct 2006

Action history

CR046: Missing properties in the property summary (Core table d-1, second half) [link to this issue]

For instance, BindingOperation.{binding message references},
BindingOperation.{binding fault references}.  Probably others.

Transition history

raised on 23 May 2006 by Jonathan Marsh (jmarsh@microsoft.com)

agreed on 1 Jun 2006

Already fixed.

Acknowledgment cycle

announced by group on 16 Oct 2006

CR047: "interface" attribute info item on service component [link to this issue]

Would it be useful to add a clause for the <service> component stating
The "interface" attribute information item should point to an
interface that has non zero number of "operation" element information
items within it.

If not, we cd as well have service components that could possible be
empty, and allow them to extend other service components, reflecting
the same semantics we have defined for interface inheritance -
considering that one service component is related to exactly one
interface.

Transition history

raised on 23 May 2006 by Ramkumar Menon (ramkumar.menon@gmail.com)

declined on 8 Jun 2006

Close with no action.

Acknowledgment cycle

announced by group on 16 Oct 2006

agreement by reviewer on 12 Mar 2007

CR048: "interface" attribute info item on service component [link to this issue]

Am I right if I state that if all "binding" attribute info items that
had been defined on the endpoint node should have been associated with
an  "interface" attribute information item? What does it mean to be
otherwise ?

Transition history

raised on 23 May 2006 by Ramkumar Menon (ramkumar.menon@gmail.com)

declined on 8 Jun 2006

Close with no action. Already explained to commenter.

Acknowledgment cycle

announced by group on 16 Oct 2006

agreement by reviewer on 12 Mar 2007

CR049: "interface" attribute info item on service component [link to this issue]

Moreover, if the service component has an interface attribute info
item that extends from two other interfaces, can the endpoint defined
within it refer to bindings that were defined for the parent
interfaces ? If yes/no, should this be reflected in the core language
spec ?

Transition history

raised on 23 May 2006 by Ramkumar Menon (ramkumar.menon@gmail.com)

declined on 8 Jun 2006

Close with no action. Already explained to commenter.

Acknowledgment cycle

announced by group on 16 Oct 2006

agreement by reviewer on 12 Mar 2007

CR050: When does {safety} appear? [link to this issue]

The wsdlx:safe extension is optional "extension MAY be used", but adds
the "REQUIRED" {safety} property.  The property has a default value of
"false".

From this I assume that an implementation that supports the extension
will always have the safety property present, regardless of whether
wsdlx:safe appears in the WSDL.

I ask because the Woden interchange results don't seem to add the
property unless the attribute appears in the WSDL -- which is entirely
reasonable, and what I also prefer.  Namely, the absence of the property
should clearly be equivalent to the value "false".

I think the simple fix is to make the property OPTIONAL and remove the
defaulting to "false".  Then, if the attribute doesn't appear, the
property will be absent.

[1]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.
html?content-type=text/html;%20charset=utf-8#safety

Transition history

raised on 24 May 2006 by Jonathan Marsh (jmarsh@microsoft.com)

declined on 8 Jun 2006

Close with no action.

Acknowledgment cycle

announced by group on 16 Oct 2006

CR051: when does wsoap:code appear? [link to this issue]

Similarly to safety, it's not clear when wsoap:code and wsoap:subcode
should appear.

Both of these properties are OPTIONAL, yet the mapping defaults the
value to "#any".  Thus whether the property appears isn't deterministic
to the WSDL.  One implementation could leave it out (e.g. Woden) when
it's not in the WSDL, another could always put it in.

The fix seems to be to make the property REQUIRED when the soap binding
is in effect, or to remove the "#any" default and say that no value is
the same as "#any".

Transition history

raised on 24 May 2006 by Jonathan Marsh (jmarsh@microsoft.com)

agreed on 8 Jun 2006

Proposed fix accepted.

Acknowledgment cycle

announced by group on 16 Oct 2006

CR052: Serializing only part of the body with HTTP binding [link to this issue]

My understanding of table 6-5
(http://www.w3.org/TR/wsdl20-adjuncts/#_http_serialization) is that all
the whole instance is always transmitted when the input serialization is
"application/xml".

This seems to defeat a use case such as the following one:

I wan to create a blog system conform to the REST principles.

To create a new blog entry, I POST the following item to a generic
location (for instance http://eric.van-der-vlist.com/blog/):

+++++++++++++++++++++++++++++++++++++++++++++++++++++++
POST /blog/ HTTP/1.1
Authorization: Basic XXXsaXN0OmVpbGF0XXX=
Host: eric.van-der-vlist.com
Content-Length: XXX
Content-Type: application/xml

<item>
<title>Validatting microformats</title>
<description>
<p>This blog entry is folowing up...</p>
.../...
</description>
</titem>
+++++++++++++++++++++++++++++++++++++++++++++++++++++++

The server might answer something such a:

+++++++++++++++++++++++++++++++++++++++++++++++++++++++
HTTP/1.1 201 Created
Date: Wed, 24 May 2006 16:26:52 GMT 
Location: http://eric.van-der-vlist.com/blog/2277_Validatting_microformats
Content-Length: XXX
Content-Type: application/xml

<item id="2277">
<title>Validatting microformats</title>
<description>
<p>This blog entry is folowing up...</p>
.../...
</description>
</titem>
+++++++++++++++++++++++++++++++++++++++++++++++++++++++

I notice the typo in the first paragraph and update the item using a PUT
at http://eric.van-der-vlist.com/blog/2277_Validatting_microformats:

+++++++++++++++++++++++++++++++++++++++++++++++++++++++
PUT /blog//2277_Validatting_microformats HTTP/1.1
Authorization: Basic XXXsaXN0OmVpbGF0XXX=
Host: eric.van-der-vlist.com
Content-Length: XXX
Content-Type: application/xml

<item id="2277">
<title>Validatting microformats</title>
<description>
<p>This blog entry is following up...</p>
.../...
</description>
</titem>
+++++++++++++++++++++++++++++++++++++++++++++++++++++++

and the server returns:

+++++++++++++++++++++++++++++++++++++++++++++++++++++++
HTTP/1.1 204 No Content
Date: Wed, 24 May 2006 14:05:30 GMT
+++++++++++++++++++++++++++++++++++++++++++++++++++++++

I notice the typo in the title and update the item using a PUT at
http://eric.van-der-vlist.com/blog/2277_Validatting_microformats:

+++++++++++++++++++++++++++++++++++++++++++++++++++++++
PUT /blog//2277_Validatting_microformats HTTP/1.1
Authorization: Basic XXXsaXN0OmVpbGF0XXX=
Host: eric.van-der-vlist.com
Content-Length: XXX
Content-Type: application/xml

<item id="2277">
<title>Validating microformats</title>
<description>
<p>This blog entry is following up...</p>
.../...
</description>
</titem>
+++++++++++++++++++++++++++++++++++++++++++++++++++++++

and the server returns:

+++++++++++++++++++++++++++++++++++++++++++++++++++++++
HTTP/1.1 204 No Content
Date: Wed, 24 May 2006 14:05:45 GMT
+++++++++++++++++++++++++++++++++++++++++++++++++++++++

Of course, cool URIs don't change and the URI of this post is still
http://eric.van-der-vlist.com/blog/2277_Validatting_microformats even if
the title has changed.

This scenario creates several issues with the current Working Draft:

* In the first PUT, the rule to derive the URI from the instance
should be clever enough to map @id="2277" and <title>Validating
microformats</title> into "2277_Validatting_microformats". This
is already quite a challenge knowing that other blog systems
migth want to follow other rules and map the same value into
"2277%20Validatting%20microformats" or "2277+Validatting
+microformats" or "2277ValidattingMicroformats" or whatever. 
* In the second put we definitely run out of chance since the
information that has been used to generate the URI is no longer
in the instance document.

A suggestion to solve this problem would be to define in the WSDL
document the input instance as:

<whateverRoot>
<location>2277_Validatting_microformats</location>
<item id="2277">
<title>Validating microformats</title>
<description>
<p>This blog entry is following up...</p>
.../...
</description>
</titem>
</whateverRoot>

And to add an HTTP binding attribute to give the XPath expression (that
could be a subset of XPath) of what needs to be serialized as XML.

The binding operation could be something such as:

<operation ref="tns:retrieveByReservationQuery" 
whttp:location="{location}" 
whttp:method="PUT"
whttp:inputSerialization="application/xml"
whttp:inputPayload="/whateverRoot/item"
/> 

Transition history

raised on 26 May 2006 by Eric van der Vlist (vdv@dyomedea.com)

agreed on 7 Sep 2006

Closed with no action.

Acknowledgment cycle

announced by group on 8 Jul 2006

CR053: Allow absolute URI in {location} [link to this issue]

The second comment I have is that it should be possible to "follow an
hyperlink" and give an absolute URI in the whttp:location attribute.

There seems to be no reason why the URIs should follow a predefined
hierarchical structure and in this blog system example, we could imagine
a central server powering different domains. 

The first POST could be at  http://van-der-vlist.com/blog/ and the
server could determine from my credentials a specific (and dynamic)
domain name for the location of the blog entry
(http://eric.van-der-vlist.com/blog/2277_Validatting_microformats).

My understanding of the current WD is that whttp:location="{location}"
wouldn't work if location was containing an absolute URI.

Couldn't that behaviour be changed?

Transition history

raised on 26 May 2006 by Eric van der Vlist (vdv@dyomedea.com)

agreed on 21 Sep 2006

Adopted proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2006Sep/0034, as amended by http://lists.w3.org/Archives/Public/www-ws-desc/2006Sep/0037.

Acknowledgment cycle

announced by group on 15 Feb 2007

Action history

CR054: URIPath feedback [link to this issue]

The question I have is about the "URIPath Feedback Requested" in the WD:

"The inclusion of elements of the instance data in the path of the
request URI, whilst supported by WSDL 1.1, is not supported by XForms
1.0. Hence this mechanism MAY be removed in a future version of this
specification. Feedback on this issue from users and implementers is
highly encouraged."

Although the mechanism isn't supported by XForms as such, I am wondering
if it isn't need to support relative URIs in XForms submissions.

Imagine we have a blog system that is more conform to the current WD and
that the item is available at http://eric.van-der-vlist.com/blog/2277.
This should allow to express whttp:location as "{@id}" (BTW, are
attributes supported in these expression?).

Using content negotiation the server could send an XHTML/XForms document
to the user agents that support it and the XForm if the XForms
submissions in this document use relative URIs, the value of
the /item/@id attribute would be part of the URI even if XForms isn't
aware of that fact.

Isn't it a case where XForms would kind of implicitly support these
URIPath mechanism?

Transition history

raised on 26 May 2006 by Eric van der Vlist (vdv@dyomedea.com)

agreed on 7 Sep 2006

Closed with no action.

Acknowledgment cycle

announced by group on 8 Jul 2006

CR055: Clarification needed on HTTP Transfer Coding [link to this issue]

Can someone please clarify some points about the http transer coding
extension properties defined in Part 2 section 6.8.2 Relationship to WSDL
Component Model [1]?

It says the Binding has a {http transfer coding default} property that is
available to InterfaceMessageReference and InterfaceFaultReference
components. Is this worded correctly? Do components from the abstract
interface need http binding information?

It also says BindingOperation has a {http transfer coding default} property
that is available to BindingMessageReference and BindingFault components. Is
'BindingFault' a mistake, should this say BindingFaultReference?

There are no semantic rules about the relationship between the two {http
transfer coding default}  properties (i.e. in Binding and BindingOperation),
so they could potentially be different. I don't think this would make sense,
but it seems to be possible according to the way this section is described.

Finally, there are no semantic rules about the relationship between
BindingOperation's {http transfer coding default} property and the {http
transfer coding} properties if its two child components. As an implementor I
can infer what that relationship might be, but it would be better if the
spec stated in explicitly as it does for default and actual extension
properties elsewhere.

[1] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.html?content-type=text/html;%20charset=utf-8#http-transfer-coding-relate

Transition history

raised on 26 May 2006 by John Kaputin (gmail) (jakaputin@gmail.com)

agreed on 7 Sep 2006

Closed by adopting the proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2006Sep/0004.html, minus the sentences beginning "If this property is not present ..." on the last two bullets, plus the proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2006Sep/0008.html plus a final bullet in each list reading "Otherwise none."

Acknowledgment cycle

announced by group on 16 Oct 2006

Action history

CR056: Questions on {http method} and {safety} extension properties [link to this issue]

In 3.1 Operation Safety at [2] the {safety} property is defined as REQUIRED
with a default value of "false" if not specified in the WSDL, so is the
wording at [1] "...if a {safety} property ... is present ..." redundant (i.e.
{safety} will always be present)?

And there's a possible typo in section 3.1 at [2].  The assertion refers to
"...a safe interaction defined in Section 3.5 of [Web
Architecture<http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/wsdl20/wsdl20-adjuncts.html#webarch>
]". I think this should say Section 3.4 (i.e. section 3.4 Safe
Interactions).

[1] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.html?content-type=text/html;%20charset=utf-8#_http_binding_default_rule_method
[2] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.html#property-InterfaceOperation.safety

Transition history

raised on 23 May 2006 by John Kaputin (gmail) (jakaputin@gmail.com)

declined on 6 Jul 2006

Close with no action.

Acknowledgment cycle

announced by group on 16 Oct 2006

CR057: HTTPHeader name should be xs:string, not xs:QName [link to this issue]

I think there is an error in the HTTP Header component section 6.5.4 XML
Representation [1].  The XML representation shows the 'name' attribute as
type xs:QName, but the other sections describe it as type xs:string. I
assume xs:QName is incorrect and have implemented it as a String in Woden.

[1] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.html?content-type=text/html;%20charset=utf-8#http-transfer-coding-relate

Transition history

raised on 26 May 2006 by John Kaputin (gmail) (jakaputin@gmail.com)

agreed on 29 Jun 2006

Ensure that HTTPHeader name is of type xs:string, and not XS:Qname.

Acknowledgment cycle

announced by group on 16 Oct 2006

Action history

CR058: Suggestion to change {safety} to {safe} [link to this issue]

A bit late in the day (sorry), but I'd like to suggest renaming the
extension property {safety} to {safe} to better describe one of the binary
states (safe vs unsafe) of this property, which in turn will map neatly to a
boolean API method like isSafe(). It also reflects the discussion of this
property in the spec which talks about operations being 'safe' or 'unsafe'.
getSafety() is cumbersome and isSafety() doesn't sound quite right.

As an example, the {required} boolean property describes a binary state
(required vs not required) that maps neatly to the boolean method
isRequired().

Our options in Woden are to just adopt the isXXX() convention for a boolean
property {XXX} and not worry about how it sounds or diverge from the exact
property-to-method naming convention we have been using and construct a more
suitable boolean method name (i.e. for the boolean properties {http cookies}
and {http location ignore uncited}).

Transition history

raised on 24 May 2006 by John Kaputin (gmail) (jakaputin@gmail.com)

agreed on 20 Jul 2006

Rename property to {safe}.

Acknowledgment cycle

announced by group on 16 Oct 2006

Action history

CR059: Editorial: Where does {http location ignore uncited} appear? [link to this issue]

Part 2 Section 6.7.2.2.2 defines the {http location ignore uncited}
property.  In other definitions, it is explicit what component
properties are assigned to.  In this case it's not explicit, though the
appendix shows in on the (obvious) Binding Operation component.

Transition history

raised on 1 Jun 2006 by Jonathan Marsh (jmarsh@microsoft.com)

agreed on 7 Sep 2006

Add mention of Binding Operation to property definition.

Acknowledgment cycle

announced by group on 16 Oct 2006

Action history

CR060: Why don't whttp:authenticationType and {http authentication scheme} match? [link to this issue]

Is there a reason the attribute isn't called whttp:authenticationScheme?
Or the property {http authentication type}?

Transition history

raised on 1 Jun 2006 by Jonathan Marsh (jmarsh@microsoft.com)

agreed on 20 Jul 2006

Rename attribute to whttp:authenticationScheme.

Acknowledgment cycle

announced by group on 16 Oct 2006

Action history

CR061: service and binding name shown as QNames in example - should be NCNames [link to this issue]

The XML representation of the service component in part 1 [1]
describes the service name attribute as being of type xs:NCName.
However, example WSDL elsewhere in part 1 [2] has a service element
as:

  <service name="ns1:BankService"
           interface="tns:Bank">

i.e. with name attribute as a QName. I believe the service name should
be simply "BankService" without qualification.

The binding name in the same example suffers a similar problem.

[1] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-type=text/html;%20charset=utf-8#Service_XMLRep
[2] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-type=text/html;%20charset=utf-8#Feature_composition_model_example

Transition history

raised on 5 Jun 2006 by Jeremy Hughes (hughesj@apache.org)

agreed on 7 Sep 2006

Remove the extra namespace prefixes.

Acknowledgment cycle

announced by group on 16 Oct 2006

objection from reviewer on 17 Oct 2006

objection declined by group on 20 Oct 2006

F & P removed, this editorial point is now moot.

Action history

CR062: Re:service and binding name shown as QNames in example - should be NCNames [link to this issue]

I'm Graham Turrell, and I've recently started working with Jeremy and the
other contributors on woden development. I used the feature composition
example as a basis for quickly testing the woden wsdl2 parser, which
prompted Jeremy's mailing.

I modifed the feature composition example according to the current Core spec
(which incidentally parses successfully with woden). I've included here both
" "pseudo-wsdl2" of the form used in the example, and the "real wsdl2" from
which it is derived. The former could be used to directly update the example
if desired. Hope thats of use, at least as a starting point...

Here's a summary of changes to my copy of the pseudo-wsdl2:

- added xnlns:tns declaration
- removed xmlns:ns1 - redundant
- added xsi:schemaLocation (may wish to remove that from the pseudo-wsdl
however)
- changed interface name attribute from QName to NCName
- operation pattern attribute added (mandatory)
- binding name attribute changed from QName to NCName
- binding type attribute added - mandatory
- service nameattribute changed from QName to NCName
- endpoint name attribute added (mandatory)
- (also, endpoint binding attribute prefix changed to tns. Prefix ns1
probably redundant here).

Pseudo-wsdl2:
-------------
<description targetNamespace=" http://example.com/bank"
             xmlns="http://www.w3.org/2006/01/wsdl"
             xmlns:tns=" http://example.com/bank"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation=
             "http://www.w3.org/2006/01/wsdl
http://www.w3.org/2006/01/wsdl/wsdl20.xsd
              http://www.w3.org/2001/XMLSchema
http://www.w3.org/2001/XMLSchema.xsd">
  <interface name="Bank">
    <!-- All implementations of this interface must be secure -->
    <feature ref="http://example.com/secure-channel"
             required="true"/>
    <operation name="withdrawFunds" pattern="
http://www.w3.org/2004/03/wsdl/in-out">
      <!-- This operation must have ACID properties -->
      <feature ref=" http://example.com/transaction"
               required="true"/>
      ...
    </operation>
    <operation name="depositFunds"
pattern="http://www.w3.org/2004/03/wsdl/in-out
">
      <!-- This operation requires notarization -->
      <feature ref="http://example.com/notarization "
               required="true"/>
      ...
    </operation>
  </interface>

  <binding name="BankSOAPBinding" type=" http://www.w3.org/2005/12/wsdl/soap
">
    <!-- This particular binding requires ISO9001
         compliance to be verifiable -->
    <feature ref="http://example.com/ISO9001 "
             required="true"/>
    <!-- This binding also requires notarization -->
    <feature ref="http://example.com/notarization "
             required="true"/>
  </binding>

  <service name="BankService"
           interface="tns:Bank">
    <endpoint name="BankSOAPEndpoint" binding="tns:BankSOAPBinding">
    ...
    </endpoint>
  </service>
</description>
-----------------

real wsdl2:

<?xml version="1.0" encoding="UTF-8"?>
<description targetNamespace=" http://example.com/bank"
             xmlns="http://www.w3.org/2006/01/wsdl"
             xmlns:tns=" http://example.com/bank"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation=
             "http://www.w3.org/2006/01/wsdl
http://www.w3.org/2006/01/wsdl/wsdl20.xsd
              http://www.w3.org/2001/XMLSchema
http://www.w3.org/2001/XMLSchema.xsd">

  <interface name="Bank">
    <!-- All implementations of this interface must be secure -->
    <feature ref="http://example.com/secure-channel"
             required="true"/>
    <operation name="withdrawFunds" pattern="
http://www.w3.org/2004/03/wsdl/in-out">
      <!-- This operation must have ACID properties -->
      <feature ref=" http://example.com/transaction"
               required="true"/>
    </operation>
    <operation name="depositFunds"
pattern="http://www.w3.org/2004/03/wsdl/in-out
">
      <!-- This operation requires notarization -->
      <feature ref="http://example.com/notarization "
               required="true"/>
    </operation>
  </interface>

  <binding name="BankSOAPBinding" type="http://www.w3.org/2005/12/wsdl/soap
">
    <!-- This particular binding requires ISO9001
         compliance to be verifiable -->
    <feature ref="http://example.com/ISO9001"
             required="true"/>
    <!-- This binding also requires notarization -->
    <feature ref="http://example.com/notarization"
             required="true"/>
  </binding>

  <service name="BankService"
           interface="tns:Bank">
    <endpoint name="BankSOAPEndpoint"
binding="tns:BankSOAPBinding"></endpoint>
  </service>
</description>

Transition history

raised on 6 Jun 2006 by Graham Turrell (gturrell@googlemail.com)

agreed on 19 Oct 2006

Close with no action - removal of F&P make this issue irrelevant.

Acknowledgment cycle

announced by group on 20 Oct 2006

CR063: Prefix declarations in inlined schema [link to this issue]

Hi, section 3.1.2 of part 1 [1] says about inlining XML schema:

"It may be viewed as simply cutting and pasting an existing schema
document to a location inside the types element information item."

Doing this could mean a namespace declaration, declared in the
enclosing <description> is redeclared in the <schema> element. Of
course, this won't be a problem - I'm more interested in the case
where the inlined schema relies on the enclosing <description>'s
namespace declarations. Meaning the <schema> uses prefixes only
declared in the enclosing <description> element. So ...

Is it necessary to respecify namespace declarations already specified
in the enclosing WSDL or do the default scoping rules apply?

[1] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-type=text/html;%20charset=utf-8#inlining-xsd

Transition history

raised on 7 Jun 2006 by Jeremy Hughes (hughesj@apache.org)

agreed on 7 Sep 2006

Add "Conceptually, " to the start of the quoted sentenced.

Acknowledgment cycle

announced by group on 16 Oct 2006

Action history

CR064: WSDL 2.0 primer CR comments [link to this issue]

The WSDL 2.0 Primer CR contains a number of editorial errors:

* Sections 1.3's heading says "Use of URI and IRI."  Since the section talks
about URIs and IRIs, and not about the words "URI" and "IRI," the section
title should probably say "Use of URIs and IRIs."


* Section 2.1.1 says:

... a floating point number in USD$ ...

"USD$" should be "USD" (or some other valid option).

(Also, is "floating point number" valid outside the realm of fixed-size
storage with an exponent field?)


* Section 2.2 says:

A language specification must therefore define the set sentences
in that language ...

That should be "... set of sentences ..."


* Section 2.2.2.1 says:

... how the children elements of the description element ...

That should say "child elements" instead of "children elements" (because
that use of a noun as an adjective requires the singular form).


* Section 2.2.2.1 also says:

Thus, the order of the WSDL 2.0 elements matters, in spite of
what the WSDL 2.0 schema says.

The wording "in spite of ..." implies that there is a contradiction,
namely, that the schema implies that the order does not matter, and
that what the schema implies is to be ignored.

Perhaps saying something like "... the order ... matters, even though
the schema doesn't specify that it does" would avoid implying something
false to the reader.

* Section 2.2.3 says:

(Whew!).

The period (full stop) is extraneous.  (The exclamation point already
ends the statement.)

* Section 2.3.3 says:

So far we have briefly covered both WSDL import/include and schema
import/include.

Since slash means (or usually means) "or" (recall, for example, that
"and/or," which means "and or or"), that should be written out as "...
WSDL import and include and schema import and include" (also because
text should probably be readable without having to figure out to
which word a punctuation character was intended to map).

* Section 4.4.1 says:

... is signaled by attribute wsdl:required="false" ...

That wording isn't quite right.  The construct "attribute xyz" only
works when "xyz" is the name of the attribute.

The text should say something like:

... is signaled by setting attribute wsdl:required to "false" ...

or:

... is signaled by setting wsdl:required="false" ...

or:

... is signaled by wsdl:required="false" ...

(The next paragraph has another instance of the same problem.)

* Section 4.2.3 still says:

<min 3, max 7> <!-- check schema for syntax -->

* Section 5.1 repeatedly refers to "uniquely identify[ing] a message"
when it really means uniquely identifying a message _type_.  For
example, the first sentence says:

It is desirable for a message recipient to have the capability
to uniquely identify a message in order to handle it correctly.

That makes it sound like it's about to talk about per-message IDs
(per-instance IDs).

The wording should be reworked appropriately.


* Section 5.2 says:

... a wide ranging debate ...

That should be:

... a wide-ranging debate ...




Additionally:

* Section 5.6.2 refers to RFC 2396, which has been obsolete for
over a year.  The section should probably refer to RFC 3986.
						

Transition history

raised on 12 Jun 2006 by Daniel Barclay (daniel@fgm.com)

agreed on 28 Sep 2006

Delegated to editor.

Acknowledgment cycle

announced by group on 20 Oct 2006

Action history

CR065: Re: WSDL 2.0 primer CR comments [link to this issue]

I wrote:
> 
> The WSDL 2.0 Primer CR contains a number of editorial errors:
> ...

Also:

* Section 5.5.1 says:

All relationships in WSDL 2.0 (like an Operation belonging to an
Interface ...) are ...

That should be:

All relationships in WSDL 2.0 (like an Operation's belonging to an
Interface ...) are ...

(It's not the Operation itself but its belonging (again, note the
possessive word before the word "belonging") that is the relationship.)

Transition history

raised on 13 Jun 2006 by Daniel Barclay (daniel@fgm.com)

agreed on 28 Sep 2006

Delegated to editor.

Acknowledgment cycle

announced by group on 20 Oct 2006

Action history

CR066: Endpoint component {name} property vs xml representation as a QName [link to this issue]

Section 2.15.1 makes this statement:

"Endpoint components are local to a given Service component; they
cannot be referred to by QName"

but then the XML representation section (2.15.2.1) says:

"The name attribute information item together with the targetNamespace
attribute information item of the description element information item
forms the QName of the endpoint."

surely this is inconsistent. What use is the targetNamespace of the
name attribute if it isn't exposed in the component model? In any case
you can't refer to an endpoint component uniquely by way of a QName -
you need a service component {name} (a QName) and the endpoint
component {name} (an NCName).

Transition history

raised on 14 Jun 2006 by Jeremy Hughes (hughesj@apache.org)

agreed on 7 Sep 2006

Remove the phrase about QNames: "Endpoint components are local to a given Service component (see A.2 Fragment Identifiers). "

Acknowledgment cycle

announced by group on 16 Oct 2006

Action history

CR067: {http cookies} REQUIRED? [link to this issue]

I noticed from Arthur's updates to the interchange format that
BindingOperation.{http cookies} is required when the SOAP binding is
engaged.  The text before that makes it sound optional (e.g. "may",
"allowed".)  I think Arthur's reading is probably most nearly literally
correct, but if so, the "may" and "allowed" might need to be
strengthened a little.  But I wonder if this reading is really what we
intended.

The bigger question is, whether support for the defined subset of {http
*} properties are required by all implementations of the SOAP binding or
whether the whttp:* attributes are an "optional extension" of the SOAP
binding.  The latter seems a bit strange, as we don't seem to require
implementations to support a {soap underlying protocol} value of
"http://www.w3.org/2003/05/soap/bindings/HTTP/", yet everyone is
required populate the {http cookies} property, which is called out as
specifically only having meaning when used with
"http://www.w3.org/2003/05/soap/bindings/HTTP/".

Not sure what the right solution is, but it seems like we should at
least make the {http *} properties optional in the component model
unless the right {soap underlying protocol} is in use.  More difficult
but possibly better would be to figure out how to treat this "nested"
extension the same as the top-level ones.
						

Transition history

raised on 20 Jun 2006 by Jonathan Marsh (jmarsh@microsoft.com)

agreed on 6 Jul 2006

Clarify that in the SOAP binding, the HTTP properties occur only when the transport is HTTP (e.g. override REQUIRED).

Acknowledgment cycle

announced by group on 16 Oct 2006

objection from reviewer on 16 Oct 2006

objection incorporated by group on 20 Feb 2007

Completed implementation.

Action history

CR068: WSDL 2.0 part 2 comment - 2.3.x, 2.2.x wording problems [link to this issue]

Regarding the WSDL 2.0 part 2 CR document currently at
http://www.w3.org/TR/wsdl20-adjuncts:

* The sections on the message exchange patterns (2.3.1, 2.3.2, ..., 2.3.8)
have a small wording problem.  They all begin with:

This pattern consists of ...

instead of something such as:

The in-out pattern consists of ...

(or

The In-Out message exchange pattern consists of ...

or whatever).

Specifically, the main text does not stand on its own (independent of
the headings) as it should.  Headings are not part of the text (not
supposed to be required to be read to understand the text); they are
just guides for finding or skipping portions of the text.

(For example, notice how, say, section 4.1.2, XML Representation of the
wrpc:signature Extension, starts off:

The XML representation for the RPC signature extension is an
attribute information item with ...

instead of beginning:

This is an attribute information item with ...

Also, see any professionally edited book.)

(Additionally, notice that with the current wording, nothing in the text
or header clearly indicates what the patterns' names are.  For example,
neither the text nor the header says of section 2.3.1 ever says "the
In-Only MEP."

The header text "In-Out" does indicate that "In-Out" has something to
do with the following text, and even the pattern described in it, but
doesn't make clear that is the name of the pattern.)

* More seriously, section 2.2.3 has a similar problem that does strongly
affect the semantics of the text.  The section begins:

Faults MUST NOT be propagated.

Note how that current wording clearly says that faults must not be
propagated, period (full stop).  (There is no mention that that applies
only for a/the No Faults rule, as apparently intended.)

The text should probably begin somewhat like this:

Under the No Faults fault propagation rule, faults MUST NOT be
propagated.

* Sections 2.2.1 and 2.2.2 have similar definitional problems.

* Presumably, the document is likely to have the same types of errors in
other places, so it should be reviewed and corrected as necessary.

Transition history

raised on 15 Jun 2006 by Daniel Barclay (daniel@fgm.com)

agreed on 7 Sep 2006

Accept proposals to fix (though we don't think we need to search further for similar stylistlic issues.)

Acknowledgment cycle

announced by group on 16 Oct 2006

Action history

CR069: Deconstructing MEPs [link to this issue]

There has been a practice of modeling essentially request-response
interactions (especially in the absence of WS-Addressing) as two one-way
messages.  IIRC, we recommend this strategy when the request and
response are over two different transports.

However, there seems to be a missing piece.  If I have an in-out MEP, I
should be able to deconstruct it into it's component parts fairly
easily.

  "in" of "in-out" -> "in-only"

  "out" of "in-out" -> "out-only", only, "in-out" uses the fault
propagation rulset "fault replaces message" and "out-only" uses "no
faults".

This shows our primitive in-only and out-only MEPs might not be adequate
to decompose our multi-message MEPs.  Do we want to enable such a
scenario?  If so, do we need a "fault-only" with "no-faults" MEP?  Or do
we need "out-only" with a "fault-replaces message" MEP?

Transition history

raised on 3 Jul 2006 by Jonathan Marsh (jmarsh@microsoft.com)

agreed on 7 Sep 2006

Closed with no action.

Acknowledgment cycle

announced by group on 16 Oct 2006

CR070: Request 2 clarifications for RPC style [link to this issue]

1.  "The sequence MUST contain only local element children.? " [1]

I believe this assertion refers to both input element and output element 
sequences. The other assertions for RPC style explicitly state input or 
output. I'd like to see this assertion hardened as:

"Both the input and output sequences MUST contain only local element 
children."

[1] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.html?content-type=text/html;%20charset=utf-8#RPCStyle-5013-summary

Transition history

raised on 6 Jul 2006 by Lawrence Mandel (lmandel@ca.ibm.com)

agreed on 13 Jun 2006

Proposal accepted.

Acknowledgment cycle

announced by group on 16 Oct 2006

Action history

CR071: Request 2 clarifications for RPC style [link to this issue]

2. "If elements with the same qualified name appear as children of both 
the input and output elements, then they MUST both be declared using the 
same named type.? " [2]

In this case local elements do not have qualified names only local names. 
This looks like a mistake to me. I'd like to see this corrected to avoid 
any confusion. My suggested correction is:

"If elements with the same local name appear...."

I've attached a patch for wsdl20-adjunts.xml that contains these changes.

[2] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.html?content-type=text/html;%20charset=utf-8#RPCStyle-5018-summary

Transition history

raised on 6 Jul 2006 by Lawrence Mandel (lmandel@ca.ibm.com)

declined on 13 Jun 2006

Local elements (a property of the schema) is not the same as unqualified (a property of an element).

Acknowledgment cycle

announced by group on 16 Oct 2006

CR072: Questions on {http method} and {safety} extension properties [link to this issue]

Some questions arose while implementing HTTP extensions from Part 2
Adjuncts.

In 6.3.1 HTTP Method Selection at [1]  is there a default value for {http
method} if the {safety} property is "false"?

In 3.1 Operation Safety at [2] the {safety} property is defined as REQUIRED
with a default value of "false" if not specified in the WSDL, so is the
wording at [1] "...if a {safety} property ... is present ..." redundant (i.e.
{safety} will always be present)?

And there's a possible typo in section 3.1 at [2].  The assertion refers to
"...a safe interaction defined in Section 3.5 of [Web
Architecture<http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/wsdl20/wsdl20-adjuncts.html#webarch>
]". I think this should say Section 3.4 (i.e. section 3.4 Safe
Interactions).

[1]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.html?content-type=text/html;%20charset=utf-8#_http_binding_default_rule_method
[2]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.html#property-InterfaceOperation.safety

Transition history

raised on 23 May 2006 by John Kaputin (gmail) (jakaputin@gmail.com)

agreed on 13 Jun 2006

This issue is a duplicate of CR050 and CR035, and the typo mentioned has already been fixed.

Acknowledgment cycle

announced by group on 16 Oct 2006

CR073: Suggested editorial changes to adjuncts section 4.1.1 wrpc:signature [link to this issue]

Section 4.1.1 of the WSDL adjuncts document contains some complex 
assertions. (Assertions that have two assertion statements or are 
difficult to understand.) I'd like to propose some changes. Note that I 
don't think any of my proposed changes change the meaning of the 
specification. The changes are simply editorial/formatting changes that 
should make it easier to understand the assertions and, for 
implementations and the test suite, easier to identify when an assertion 
has been violated. I've attached a patch for wsdl20-adjuncts.xml that 
contains these changes.

1. "For each child element of the input and output messages of the 
operation, a pair (q, t) whose first component q is equal to the qualified 
name of that element MUST be present in the list, with the caveat that 
elements that appear with cardinality greater than one MUST be treated as 
a single element.? "

I'd like to suggest a simple grammatical correction to make this more 
readable.

For each child element of the input and output messages of the operation, 
a pair (q, t), whose first component q is equal to the qualified name of 
that element, MUST be present in the list, with the caveat that elements 
that appear with cardinality greater than one MUST be treated as a single 
element.?

2. "For each pair (q, #in), there MUST be a child element of the input 
element with a name of q and there MUST NOT be a child element of the 
output element with the same name.?"

For each pair (q, #in), there MUST be a child element of the input element 
with a name of q.
For each pair (q, #in), there MUST NOT be a child element of the output 
element with the name q.

3. "For each pair (q, #out), there MUST be a child element of the output 
element with a name of q and there MUST NOT be a child element of the 
input element with the same name.?"

For each pair (q, #out), there MUST be a child element of the output 
element with a name of q.
For each pair (q, #out), there MUST NOT be a child element of the input 
element with the name q.

4. "For each pair (q, #inout), there MUST be a child element of the input 
element with a name of q and there MUST be a child element of the output 
element with the same name. Furthermore, those two elements MUST have the 
same type.?"

For each pair (q, #inout), there MUST be a child element of the input 
element with a name of q and there MUST be a child element of the output 
element with the same name.

In this case I'd like to drop the "Furthermore, those two elements MUST 
have the same type." as this is redundant with assertion RPCStyle-5018. If 
it's felt that this should be kept I think the statement should be removed 
from the assertion and preferably rephrased to remove the MUST keyword 
that indicates an assertion. (I think it's potentially dangerous for the 
spec to define the same assertion twice.)

5. "For each pair (q, #return), there MUST be a child element of the 
output element with a name of q and there MUST NOT be a child element of 
the input element with the same name.? "

For each pair (q, #return), there MUST be a child element of the output 
element with a name of q.
For each pair (Q, #return), there MUST NOT be a child element of the input 
element with the name q.

Transition history

raised on 6 Jul 2006 by Lawrence Mandel (lmandel@ca.ibm.com)

agreed on 13 Jun 2006

Accept proposal, assuming the intention for #4 is also to split the sentence in two and drop the "Furthermore" sentence.

Acknowledgment cycle

announced by group on 16 Oct 2006

Action history

CR074: Assetions covered by schema validation [link to this issue]

I have noticed that the following two assertions are covered by the
schema validation itself. So i see no reason to for their explicit
declaration. May be we could get rid of them.

http://www.w3.org/TR/2006/CR-wsdl20-20060327/#InterfaceFault-0028
http://www.w3.org/TR/2006/CR-wsdl20-20060327/#InterfaceOperation-0029

Transition history

raised on 7 Jul 2006 by Chathura Herath (chathurah@gmail.com)

agreed on 13 Jun 2006

Fix those assertions by removing the assertion markup and changing "MUST be" to "is".

Acknowledgment cycle

announced by group on 16 Oct 2006

Action history

CR075: Suggested editorial changes for IRI and Multipart styles [link to this issue]

I have two editorial changes (again that are not meant to change the 
meaning of the statements) that I'd like to recommend for the IRI and 
Multipart style sections of the WSDL adjuncts. I identified these proposed 
changes while creating tests for the test suite. I've attached a patch 
that contains my suggested changes.

Section 4.2

1. "The sequence MUST contain only local element children. These child 
elements MAY contain the nillable attribute."

This assertion contains both an assertion and a suggestion. I suggest 
splitting the assertion and suggestion.

"The sequence MUST contain only local element children." "These child 
elements MAY contain the nillable attribute."

Section 4.3

2. "The sequence MUST contain only local element children. These child 
elements MAY contain the nillable attribute, and the attributes minOccurs 
and maxOccurs MUST have a value 1.? "

This assertion contains 2 assertions and a suggestion. I suggest splitting 
the assertions and suggestion.

"The sequence MUST contain only local element children." These child 
elements MAY contain the nillable attribute." "The attributes minOccurs 
and maxOccurs MUST have a value 1 for these child elements".? 

Transition history

raised on 12 Jul 2006 by Lawrence Mandel (lmandel@ca.ibm.com)

agreed on 13 Jun 2006

Split the assertions as requested, including also the last bullet in 4.2, and reword the suggestions using "Note, ..." and "may" so they aren't assertions any more.

Acknowledgment cycle

announced by group on 16 Oct 2006

Action history

CR076: {rpc signature} REQUIRED when rpc style is not specified? [link to this issue]

Section 4.1.1 of the Adjuncts specifies {rpc signature} as a required
property.  Per our recent clarifications, this will appear in the
component model whenever the implementation supports the rpc extension.
Thus, even if the {style} property does not include the rpc-style uri,
the {rpc signature} property will appear.  No default value is supplied
either.

Instead, I believe it would be cleaner to make the {rpc property}
optional, and state that when the rpc style is engaged, the property
MUST appear.

[1] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.html?content-type=text/html;%20charset=utf-8#InterfaceOperation_RPC_Signature_Definition

Transition history

raised on 12 Jul 2006 by Jonathan Marsh (jmarsh@microsoft.com)

agreed on 20 Jul 2006

Add co-occurance constraint (that must be there if the style is RPC), and make the property OPTIONAL.

Acknowledgment cycle

announced by group on 16 Oct 2006

Action history

CR077: URI comparison [link to this issue]

I dug into some of the WSDL documents for which our wsdl parser does not 
match with the baseline.
Some differences are due to the use in some documents (Echo-1G for 
instance) of the following binding URI:
wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP"
Our parser recognizes the use of the SOAP1.2 HTTP binding with the 
following URI:
wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/"
The sole difference is the last character '/'.
We currently use a simple character-by-character comparison to match the 
URI against the SOAP1.2 binding URI, as defined IIRC somewhere in part 1.
Arthur, do you know how Woden is handling URI processing and comparison ?

Transition history

raised on 24 Jul 2006 by Youenn Fablet (youenn.fablet@crf.canon.fr)

agreed on 7 Sep 2006

Add a slash to the soap1.1 binding http uri and do a consistency check in the primer and test-suite to have soap 1.2/1.1 binding http uris with the slash.

Acknowledgment cycle

announced by group on 30 Oct 2006

Action history

CR078: XML Schema requires a type in addition to name to identify an element [link to this issue]

This is implementation feedback on the Candidate Recommendation WSDL 2.0.

WSDL 2.0 uses the element name to identify a message. The example from the 
primer below uses the element names “ghns:checkAvailability” and 
“ghns:checkAvailabilityResponse” as references to messages.

<operation name="opCheckAvailability" pattern="
http://www.w3.org/2006/01/wsdl/in-out" style="
http://www.w3.org/2006/01/wsdl/style/iri" wsdlx:safe="true">
<input messageLabel="In" element="ghns:checkAvailability"/>
<output messageLabel="Out" element="
ghns:checkAvailabilityResponse"/>
<outfault ref="tns:invalidDataFault" messageLabel="Out"/>
</operation>

The problem is that the name of an element is not sufficient to identify 
the message type when using XML Schema. The type of the element must also 
be supplied in addition to the name. This is because XML Schema allows the 
type to be overridden using the xsi:type construct.

In the below example the type of the element is overridden in the root 
node by the use of xsi:type.

<FpML version="4-2" xsi:type="DataDocument" xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="
http://www.fpml.org/2005/FpML-4-2 ../fpml-main-4-2.xsd" xmlns="
http://www.fpml.org/2005/FpML-4-2">
….
</FpML>

This is an example from the FpML schema http://www.fpml.org/. FpML is the 
XML Schema standard banks, brokers, and fund managers use to communicate 
within the Financial Services industry sector. FpML is frequently extended 
and used internally by the participants in the Financial Services sector, 
so these patterns are widespread within this sector.

FpML is an example of a schema using the Universal Root pattern 
http://www.xmlpatterns.com/UniversalRootMain.shtml. 
In the FpML schema the root element is FpML and is declared as being of 
type Document. This means that the hundreds of different types of FpML 
message all use the same element as their root. This makes the root 
element name useless in distinguishing between messages because all 
messages have the same root element.

FpML is declared of type Document.

<xsd:element name="FpML" type="Document">
<xsd:annotation>
<xsd:documentation xml:lang="en">The FpML element 
forms the root for any conforming FpML instance document. The actual 
structure of the document is determined by setting the 'type' attribute to 
an appropriate derived subtype of the complex type Document.</
xsd:documentation>
</xsd:annotation>
</xsd:element>

The Document complex type is abstract. This means that as the type of the 
universal root element is abstract, then all XML instance documents must 
override the type using xsi:type.  Every XML document has the same element 
name, and only the type changes.

<xsd:complexType name="Document" abstract="true">
<xsd:annotation>
<xsd:documentation xml:lang="en">The abstract base 
type from which all FpML compliant messages and documents must be derived.
</xsd:documentation>
</xsd:annotation>
<xsd:attributeGroup ref="StandardAttributes.atts"/>
</xsd:complexType>

I suggest the type of the element is added to the Interface definition. 
This would support the usage of xsi:type in XML Schema. This would change 
the primer example to the below structure.

<operation name="opCheckAvailability" pattern="
http://www.w3.org/2006/01/wsdl/in-out" style="
http://www.w3.org/2006/01/wsdl/style/iri" wsdlx:safe="true">
<input messageLabel="In" element="ghns:checkAvailability" type
="ghns:tcheckAvailability"/>
<output messageLabel="Out" element="
ghns:checkAvailabilityResponse" type="xs:double"/>
<outfault ref="tns:invalidDataFault" messageLabel="Out"/>
</operation>

This implementation feedback is the product of using WSDL 2.0 to define 
services using the FpML messaging schema defined in XML Schema. The aim is 
to use WSDL 2 in conjunction with XML Schema and WS-CDL within the 
International Standard for Financial Services Messaging, ISO 20022 
http://www.iso20022.org/.

Transition history

raised on 6 Aug 2006 by matthew.d.rawlings@jpmchase.com (matthew.d.rawlings@jpmchase.com)

agreed on 28 Sep 2006

Close with no action. New functionality impractical to add at this stage.

Acknowledgment cycle

announced by group on 20 Oct 2006

agreement by reviewer on 20 Oct 2006

CR079: Fragment identifier syntax not XPointer Framework-compatible [link to this issue]

While participating in the TAG discussion at [1], I noticed that our
fragment syntax does not support unknown fragment schemes, or multiple
fragment schemes in general.  This prevents the fragment identifier
syntax from being crafted for use with more than just the wsdl+xml media
type.  I believe the following are not currently a legal WSDL 2.0
fragment identifiers, though IMO they should be:

  http://example.com/webservice.wsdl#ignore-me()wsdl.description()
  http://example.com/webservice.wsdl#wsdl.description()element(/1)

In effect, instead of defining a compatible subset of XPointer, we
should be defining XPointer extensions.  The offending sentence is [2]:

  A WSDL 2.0 fragment identifier consists of zero or more xmlns pointer
  parts (see 3.4 Namespace Binding Context in [XPointer Framework]) 
  followed by a WSDL 2.0 pointer part as defined below.

A fix to allow other fragment schemes would be: 

 A WSDL 2.0 fragment identifier is an XPointer [XPointer Framework], 
 augmented with WSDL 2.0 pointer parts as defined below. Note that many 
 of these parts require the pre-appearance of one or more xmlns pointer 
 parts (see 3.4 Namespace Binding Context in [XPointer Framework]).

The constraint to have only a single WSDL pointer part (plus any
necessary xmlns declarations) is still valuable, in the context of
defining a canonical WSDL 2.0 IRI, as in [3], so I'd change

 The IRI provided by the namespace name of the {name} property is 
 combined with a fragment identifier as defined in A.2 Fragment 
 Identifiers.

To 

 The IRI provided by the namespace name of the {name} property is 
 combined with a zero or more xmlns pointer parts (see 3.4 Namespace 
 Binding Context in [XPointer Framework] followed by a single
 WSDL 2.0 pointer part as defined in A.2 Fragment Identifiers.

One more thing - are these URIs supposed to be fully canonical?  If so,
we might want to constrain the order of the xmlns() parts - e.g. they
appear in the order in which the prefixes are used in the WSDL pointer
part, and ensure no unused xmlns() declarations may appear.

[1] http://lists.w3.org/Archives/Public/www-tag/2006Sep/0015.html
[2] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-type=text/html;%20charset=utf-8#frag-ids
[3] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-type=text/html;%20charset=utf-8#wsdl-iris

Transition history

raised on 5 Sep 2006 by Jonathan Marsh (jmarsh@microsoft.com)

agreed on 14 Sep 2006

Proposal accepted.

Acknowledgment cycle

announced by group on 16 Oct 2006

Action history

CR080: Canonical component designators? [link to this issue]

From issue CR079: 
  One more thing - are these URIs supposed to be fully canonical?  If so,
  we might want to constrain the order of the xmlns() parts - e.g. they
  appear in the order in which the prefixes are used in the WSDL pointer
  part, and ensure no unused xmlns() declarations may appear.
  
Arthur also noted that we don't constrain prefixes either.  What other 
aspects might we want to constrain?  Whitespace between pointer parts?

Transition history

raised on 14 Sep 2006 by Jonathan Marsh (jmarsh@microsoft.com)

agreed on 5 Oct 2006

Add (modulo editorial discretion) "For ease of comparison, Component Designators SHOULD conform to the following canonicalization rules:"

• only 0 or more xmlns() and exactly 1 wsdl.*() pointer parts appear
• all xmlns() schemes are referenced by wsdl.*() pointer parts
• multiple xmlns() parts appear in the same order as in the wsdl.* part
• prefixes are named ns1, ns2, etc., in the order of their appearance
• no whitespace appears in the XPointer
• no duplicate URIs in xmlns()

Acknowledgment cycle

announced by group on 16 Oct 2006

Action history

CR081: Synchronous v/s Asynchronous, a WSA question, and few suggestions [link to this issue]

Section 2.9.1 in the Core Language Spec states that "A Binding component
that defines bindings for an Interface component MUST define bindings for
all the operations of that Interface component".  Shouldnt a similar
assertion be made regarding the Faults declared in the interface as well?
i.e.  "A Binding component that defines bindings for an Interface component
MUST define bindings for all the faults of that Interface component"

Transition history

raised on 5 Oct 2006 by Ramkumar Menon (ramkumar.menon@gmail.com)

agreed on 12 Oct 2006

Add "A Binding component that defines bindings for an Interface component MUST define binding for all the faults of that Interface component that are referenced from any of the operations in that Interface component."

Acknowledgment cycle

announced by group on 21 Dec 2006

agreement by reviewer on 22 Dec 2006

Action history

CR082: Header blocks in wrpc:signature [link to this issue]

Several toolkits allow for the mapping of a SOAP header to a parameter,
this is not allowed by the current description of wrpc:signature in
section 4.1.1.

Would it be possible to clarify this to allow for root elements that are
out of message bounds as specified by the appropriate binding extension?
This would allow for both http and soap headers. 

Transition history

raised on 30 Aug 2006 by Jason T. Greene (jason.greene@jboss.com)

agreed on 19 Oct 2006

Close with no action - rpc:sig is an interface construct, headers are a binding construct, and it's too late in the process anyway.

Acknowledgment cycle

announced by group on 20 Oct 2006

objection from reviewer on 20 Oct 2006

objection maintained by group on 26 Oct 2006

Attempt to clarify the scope of the request.

objection accepted by group on 30 Nov 2006

Commenter accepts the time constraints in play.

CR083: Editorial >> WSDL 2.0 definitions v/s WSDL 2.0 descriptions [link to this issue]

I suggest a minor editorial change to the Part 1 [Core Language] regarding
the usage of  the terms "WSDL 2.0 definitions" and "WSDL 2.0 descriptions".
Quoting snippet from Section 2.1.2  [WSDL 2.0 definitions are represented in
XML by one or more WSDL 2.0 Information Sets (Infosets), that is one or more
description *element information item*s]

Quoting snippet from Section 4.2.1 [ Its actual value indicates that the
containing WSDL 2.0 document MAY contain qualified references to WSDL
2.0 definitions in that namespace ]
These could be changed to WSDL 2.0 "descriptions" from "definitions" -
ensures consistent terminology.

Transition history

raised on 11 Oct 2006 by Ramkumar Menon (ramkumar.menon@gmail.com)

agreed on 19 Oct 2006

Implement above suggestion.

Acknowledgment cycle

announced by group on 21 Dec 2006

agreement by reviewer on 22 Dec 2006

Action history

CR084: Re: New issue (editorial): Missing attribute/elements in syntax summary in part 2 5.1 [link to this issue]

On Thu, 2006-10-26 at 11:27 -0400, Philippe Le Hegaret wrote:
> The XML Syntax Summary in part section 5.1 is missing:
> - http location whttp:location="xs:anyURI"? on operation
> - http cookies whttp:cookies="xs:boolean"? on binding
> - http authentication scheme/realm
>     whttp:authenticationScheme="xs:token"? 
>     whttp:authenticationRealm="xs:string"? on the endpoint

scrap this.

Only the http cookies attribute is missing on the binding. The others
are there.

Transition history

raised on 26 Oct 2006 by Philippe Le Hegaret (plh@w3.org)

agreed on 30 Nov 2006

Fix as editorial.

Acknowledgment cycle

announced by group on 13 Feb 2007

Action history

CR085: RE: F&P Primer work done. [link to this issue]

I believe you're right.  I also notice that figure mentions features and
properties (invisibly to my source search :-(  ) that need removal.
_____  

From: Ramkumar Menon [mailto:ramkumar.menon@gmail.com] 

Just curious, but in the Primer, Figure 2-1 indicates that the cardinality
of the association between an interface and the operations it owns is 1-*.
Shouldnt this be 0-* ?

Transition history

raised on 31 Oct 2006 by Jonathan Marsh (jonathan@wso2.com)

agreed on 30 Nov 2006

Fix as editorial.

Acknowledgment cycle

announced by group on 3 Jan 2007

agreement by reviewer on 3 Jan 2007

Action history

CR086: {http cookies} prohibited inconsistently [link to this issue]

Section 5 of Adjuncts includes:
								
*	{http
<http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.htm
l?content-type=text/html;%20charset=utf-8#property-Binding.httpcookies#prope
rty-Binding.httpcookies>  cookies} on Binding
<http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html#compone
nt-Binding>  components, as defined in
<http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.htm
l?content-type=text/html;%20charset=utf-8#http-cookies-decl#http-cookies-dec
l> 6.9 Specifying the Use of HTTP Cookies. This property can be used only
when the underlying protocol is HTTP.

The last sentence seems to be placed strangely.  In the introduction to the
list of http properties, the spec says the properties:

"when the SOAP binding uses HTTP as the underlying protocol, for example,
when the value of the {soap
<http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.htm
l?content-type=text/html;%20charset=utf-8#property-Binding.soapunderlyingpro
tocol#property-Binding.soapunderlyingprotocol>  underlying protocol}
property of the Binding
<http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html#compone
nt-Binding>  component is "http://www.w3.org/2003/05/soap/bindings/HTTP/".

So the properties are allowed and have defined meaning when HTTP is the
underlying protocol.  The other properties are allowed when some other
underlying protocol is used, but there is no defined meaning for them.
Except for {http cookies} which is prohibited.  Why is {http cookies}
special?

Shouldn't these properties all be prohibited when the protocol isn't HTTP?
(E.g. move the sentence "These properties can be used only when the
underlying protocol is HTTP." To the introduction to the list.   Or should
this inconsistent prohibition of the {http cookies} property be simply
stricken?

Transition history

raised on 31 Oct 2006 by Jonathan Marsh (jonathan@wso2.com)

agreed on 30 Nov 2006

Move sentence and turn it into an assertion.

Acknowledgment cycle

announced by group on 21 Dec 2006

agreement by reviewer on 21 Dec 2006

Action history

CR087: Turning off http transfer coding [link to this issue]

I presume omitting the {http transfer coding} property results in no content
coding being specified.  How do I get that behavior if there is an {http
transfer coding default} in effect?

Namely, is an empty value allowed for whttp:transferCoding and
whttp:transferCodingDefault?  

<binding . whttp:transferCodingDefault="gzip">
  <operation . wtthp:transferCodingDefault="">

A literal read says the value has to be a transfer coding token (which
doesn't include an empty string).  It's also not clear whether an
implementation will attempt to specify an empty transfer coding in this
case, or whether it will simply ignore the transfer coding property
completely.

Transition history

raised on 31 Oct 2006 by Jonathan Marsh (jonathan@wso2.com)

agreed on 30 Nov 2006

Add text that says {http transfer coding} = "" means no assertion as to the transfer coding.

Acknowledgment cycle

announced by group on 16 Feb 2007

agreement by reviewer on 16 Feb 2007

Action history

CR088: Ambiguity in Part regarding built-in XML Schema types [link to this issue]

Part 1 seems to be ambiguous about which data types from the XML Schema
namespace are automatically available in the component model, without the
need to import the XML Schema namespace.

Part 1 Section 3.1 says:
"A WSDL 2.0 document that refers to any element declaration or type
definition component of the XML Schema namespace, except the built-in simple
types, MUST import http://www.w3.org/2001/XMLSchema."

Part 1 Table 2-1 says of {type definitions}:
"In addition, the built-in datatypes defined by XML Schema ... namely the
nineteen primitive datatypes .... and the twenty-five derived datatypes".

Table 2-1 uses the terms "primitive" and "derived" which are consistent with
the Built-in datatypes section in XML Schema Part 2: Datatypes at [1] and
the table implies that 44 built-in XML Schema datatypes (19 primitive plus
25 derived) are available in {type definitions} without requiring an import
of the XML Schema namespace.

Section 3.1 uses the term "built-in simple types" which is inconsistent with
Table 2-1 and is not mentioned under Built-in datatypes at [1]. I'm not sure
if "simple" means "primitive" only or "primitive" and "derived" so it's not
clear whether this section implies that 19 or 44 built-in XML Schema types
are automatically available in {type definitions}.

Can the working group please comment on this.

[1] http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#built-in-derived

Transition history

raised on 2 Nov 2006 by John Kaputin (gmail) (jakaputin@gmail.com)

agreed on 30 Nov 2006

Implement Amy's proposal.

Acknowledgment cycle

announced by group on 21 Dec 2006

Action history

CR089: Definition of Interface Message Reference [link to this issue]

Part 1 defines Interface message reference as follows.
"An Interface Message
Reference<http://www.w3.org/TR/wsdl20/#component-InterfaceMessageReference>component
associates a defined element with a message exchanged in an
operation. By default, the element is defined in the XML Infoset [XML
Information Set <http://www.w3.org/TR/wsdl20/#XMLInfoSet>]."

But it may not always associate a defined element with the message rite ? -
in case the message content model is #none, the message is not associated
with any element.

Also, in the second sentence above, what does it mean to say "by default,
the element is defined in the XML infoset" ? Where is the defaulting defined?

Transition history

raised on 31 Oct 2006 by Ramkumar Menon (ramkumar.menon@gmail.com)

agreed on 30 Nov 2006

Fix editorially.

Acknowledgment cycle

announced by group on 21 Dec 2006

agreement by reviewer on 22 Dec 2006

Action history

CR090: Ambiguity in Part regarding built-in XML Schema types [link to this issue]

Part 1 seems to be ambiguous about which data types from the XML Schema
namespace are automatically available in the component model, without the
need to import the XML Schema namespace.

Part 1 Section 3.1 says:
"A WSDL 2.0 document that refers to any element declaration or type
definition component of the XML Schema namespace, except the built-in simple
types, MUST import http://www.w3.org/2001/XMLSchema."

Part 1 Table 2-1 says of {type definitions}:
"In addition, the built-in datatypes defined by XML Schema ... namely the
nineteen primitive datatypes .... and the twenty-five derived datatypes".

Table 2-1 uses the terms "primitive" and "derived" which are consistent with
the Built-in datatypes section in XML Schema Part 2: Datatypes at [1] and
the table implies that 44 built-in XML Schema datatypes (19 primitive plus
25 derived) are available in {type definitions} without requiring an import
of the XML Schema namespace.

Section 3.1 uses the term "built-in simple types" which is inconsistent with
Table 2-1 and is not mentioned under Built-in datatypes at [1]. I'm not sure
if "simple" means "primitive" only or "primitive" and "derived" so it's not
clear whether this section implies that 19 or 44 built-in XML Schema types
are automatically available in {type definitions}.

Can the working group please comment on this.

[1] http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#built-in-derived

Transition history

raised on 2 Nov 2006 by John Kaputin (gmail) (jakaputin@gmail.com)

Subsumed by issue(s) on 30 Nov 2006

Duplicate of CR088.

CR091: WSDL 2.0 Fault Binding [link to this issue]

Assume a fault is defined in an operation, and let's assume the fault is
referring to the element foo in the types section. When a fault occurs
how would be the SOAP message looks like? Where will this Foo element go?

From my little WSDL 1.1 knowledge, Foo element comes under Detail
element, when it is a SOAP 1.2 fault. Is this the same for WSDL 2.0?

Where should this be defined? I can not find details on this in any of
the docs of the spec. Seems I am missing something some where :(

The spec mentions that one can specify about Code and Subcode to be used
inside the binding element. But there is no mentioning anywhere about
the above case.

If you want me to more clear on this, please look at the GreatH wsdl
(http://dev.w3.org/cvsweb//2002/ws/desc/test-suite/documents/good/GreatH-1G/).
When the server throws an InvalidDataFault, how will the SOAP message
coming to the client from it. What should it contain?

I presume the fault should be bound to Detail element, but like to have
a confirmation on this.

Transition history

raised on 9 Nov 2006 by Eran Chinthaka (chinthaka@wso2.com)

agreed on 30 Nov 2006

Add requested clarification editorially.

Acknowledgment cycle

announced by group on 15 Feb 2007

agreement by reviewer on 16 Feb 2007

Action history

CR092: Re: WSDL 2.0 Fault Binding [Plus two Questions] [link to this issue]

[Section 5.4.5 of SOAP 1.2 Part 1] SOAP 1.2 states the following - "All
child *element information items* of the Detail *element information
item*are called detail entries ".
This means that the "Detail" element information item  can have multiple
detail entries. Does that mean that the user shd be able to define multiple
element info items while describing a Fault in a WSDL Document, or cd the
child elements of a fault element in the WSDL be directly copied under
the <Detail> element in a SOAP Fault EII ?

Transition history

raised on 10 Nov 2006 by Ramkumar Menon (ramkumar.menon@gmail.com)

agreed on 7 Dec 2006

Add http://lists.w3.org/Archives/Public/www-ws-desc/2006Dec/0017.html and say that the soap1.2 fault details element will contain a WSDL-described element, but may also contain other stuff that is not described.

See also http://lists.w3.org/Archives/Public/www-ws-desc/2006Dec/0054.html.

Acknowledgment cycle

announced by group on 15 Feb 2007

Action history

CR093: Re: WSDL 2.0 Fault Binding [Plus two Questions] [link to this issue]

[Section 5.4.5.1 of SOAP 1.2 Part 1] states that "Each detail entry MAY
have a [namespace name] property which has a value, that is the name of the
element MAY be namespace qualified." This means that the detail entries may
alternatively come from "null/No Namespace". How wd a user be able to model
this in a WSDL description ?

Transition history

raised on 10 Nov 2006 by Ramkumar Menon (ramkumar.menon@gmail.com)

agreed on 7 Dec 2006

Editorial fixes implemented for CR092 suffice to clarify.

Acknowledgment cycle

announced by group on 15 Feb 2007

CR094: Assertion SOAPBinding-2503001 [link to this issue]

I do not see the assertion "SOAPBinding-2503001" defined in the "Assertion
Summary" section in Part 2 [http://www.w3.org/TR/wsdl20-adjuncts] . Its been
referred from the Assertion Report.

Transition history

raised on 13 Nov 2006 by Ramkumar Menon (ramkumar.menon@gmail.com)

agreed on 7 Dec 2006

Add the missing Message assertion table. (Bonus points for combining the tables into a single one.)

Acknowledgment cycle

announced by group on 21 Dec 2006

agreement by reviewer on 22 Dec 2006

Action history

CR095: Part 2 - {element declaration} property for SOAP Header Block component [link to this issue]

{element declaration} for a SOAP header block component is defined in Part 2
as follows.
"The element declaration from the {element
declarations<http://www.w3.org/TR/2006/CR-wsdl20-20060327#property-Description.elementdeclarations>}
resolved to by the value of the element *attribute information item*. It is
an error for the element *attribute information item* to have a value and
that value does not resolve to a global element declaration from the {element
declarations<http://www.w3.org/TR/2006/CR-wsdl20-20060327#property-Description.elementdeclarations>}
property of the
Description<http://www.w3.org/TR/2006/CR-wsdl20-20060327#component-Description>component.
† <http://www.w3.org/TR/wsdl20-adjuncts/#SOAPHeaderBlock-5052-summary>"
The assertion SOAPHeaderBlock-5052<http://www.w3.org/TR/2006/CR-wsdl20-adjuncts-20060327/#SOAPHeaderBlock-5052>
has been defined to enforce this.

My Question is - Does this prevent the header blocks to be defined using
"#any" as opposed to an explicit element declaration ?
If the answer is a yes, should we prevent this in first place ? If so, what
are the known issues in allowing such a definition ?

Transition history

raised on 13 Nov 2006 by Ramkumar Menon (ramkumar.menon@gmail.com)

declined on 7 Dec 2006

Close with no action. #any is not allowed in the syntax. To allow it would be redundant, since the SOAP binding already allows arbitrary SOAP headers to be described beyond those called out by the wsoap:header element.

Acknowledgment cycle

announced by group on 21 Dec 2006

agreement by reviewer on 22 Dec 2006

CR096: Assertions that are not assertions [link to this issue]

The following assertions do not appear to really be assertions at all. I 
suggest removing them from the assertions table and removing their 
assertion identifiers.

Description-1201000
WSDL 2.0 definitions are represented in XML by one or more WSDL 2.0 
Information Sets (Infosets), that is one or more description element 
information items. 

LM: I think this is too broad to be an assertion.

Transition history

raised on 14 Nov 2006 by Lawrence Mandel (lmandel@ca.ibm.com)

agreed on 7 Dec 2006

Close by removing the cited assertion.

Acknowledgment cycle

announced by group on 11 Jan 2007

Action history

CR097: Assertions that are not assertions [link to this issue]

The following assertions do not appear to really be assertions at all. I 
suggest removing them from the assertions table and removing their 
assertion identifiers.

Description-1201005
Zero or more element information items amongst its [children], in order as 
follows: 

LM: I don't think this statement contains an assertion and if this is an 
assertion there are many other instances of this statement that should be 
added to the assertions table. 

Transition history

raised on 14 Nov 2006 by Lawrence Mandel (lmandel@ca.ibm.com)

declined on 7 Dec 2006

Assertion provides information not present in the schema, namely the order of elements is not enforced in the schema, but instead using the rules described here. It differs from other similar-looking assertions in this regard. To test, write a document that passes WSDL schema validation yet has items out of order.

Acknowledgment cycle

announced by group on 11 Jan 2007

CR098: Assertions that are not assertions [link to this issue]

The following assertions do not appear to really be assertions at all. I 
suggest removing them from the assertions table and removing their 
assertion identifiers.

Types-1300002
Specifically components that the schema imports via xs:import are NOT 
referenceable. 

LM: This assertion does not use the MUST NOT convention and I think is 
covered by the other schema import assertions although I think the text is 
still useful in the WSDL spec.

Transition history

raised on 14 Nov 2006 by Lawrence Mandel (lmandel@ca.ibm.com)

agreed on 14 Dec 2006

Close by accepting proposal http://lists.w3.org/Archives/Public/www-ws-desc/2006Dec/0052.html.

Acknowledgment cycle

announced by group on 11 Jan 2007

Action history

CR099: Assertions that are not assertions [link to this issue]

The following assertions do not appear to really be assertions at all. I 
suggest removing them from the assertions table and removing their 
assertion identifiers.

Types-1300003
Similarly, components defined in an inlined XML schema are NOT 
automatically referenceable within WSDL 2.0 document that imported (using 
wsdl:import ) the WSDL 2.0 document that inlines the schema (see 4.2 
Importing Descriptions for more details). 

LM: This assertion does not use the MUST NOT convention and I think is 
covered by the other schema and WSDL import assertions although I think 
the text is still useful in the WSDL spec.

Transition history

raised on 14 Nov 2006 by Lawrence Mandel (lmandel@ca.ibm.com)

agreed on 14 Dec 2006

Close by accepting proposal http://lists.w3.org/Archives/Public/www-ws-desc/2006Dec/0052.html.

Acknowledgment cycle

announced by group on 11 Jan 2007

Action history

CR100: Duplicate assertions [link to this issue]

While creating some tests for assertions I've come across some assertions 
that I think specify the same requirement. I'll point these out here and 
suggest that a single assertion be defined for each restriction as 
multiple assertions may lead to problems interpreting the spec and will 
lead to ambiguity wrt the assertion that should be flagged as an error for 
a WSDL document that does not comply with the spec.

1. Import-0001
However, any WSDL 2.0 document that contains component definitions that 
refer by QName to WSDL 2.0 components that belong to a different namespace 
MUST contain a wsdl:import element information item for that namespace 
(see 4.2 Importing Descriptions ). 

Import-0070
As with XML schema, any WSDL 2.0 document that references a foreign 
component MUST have a wsdl:import element information item for the 
associated foreign namespace (but which does not necessarily provide a 
location attribute information item that identifies the WSDL 2.0 document 
in which the referenced component is defined).

Transition history

raised on 14 Nov 2006 by Lawrence Mandel (lmandel@ca.ibm.com)

agreed on 7 Dec 2006

Drop the assertion markup from Import-0001.

Acknowledgment cycle

announced by group on 11 Jan 2007

Action history

CR101: Duplicate assertions [link to this issue]

While creating some tests for assertions I've come across some assertions 
that I think specify the same requirement. I'll point these out here and 
suggest that a single assertion be defined for each restriction as 
multiple assertions may lead to problems interpreting the spec and will 
lead to ambiguity wrt the assertion that should be flagged as an error for 
a WSDL document that does not comply with the spec.

2. QName-0002
Furthermore, all QName references, whether to the same or to different 
namespaces MUST resolve to components (see 2.17 QName resolution ). 

QName-resolution-1219000
A Description component MUST NOT have such broken references. 

Types-1300000
Every QName reference MUST resolve (see 2.17 QName resolution). 

Transition history

raised on 14 Nov 2006 by Lawrence Mandel (lmandel@ca.ibm.com)

agreed on 7 Dec 2006

Keep the assertion markup in 121900 and remove the other assertion markup.

Acknowledgment cycle

announced by group on 11 Jan 2007

Action history

CR102: Duplicate assertions [link to this issue]

While creating some tests for assertions I've come across some assertions 
that I think specify the same requirement. I'll point these out here and 
suggest that a single assertion be defined for each restriction as 
multiple assertions may lead to problems interpreting the spec and will 
lead to ambiguity wrt the assertion that should be flagged as an error for 
a WSDL document that does not comply with the spec.

3. Import-0003
Imported components have different target namespace values from the WSDL 
2.0 document that is importing them. 

Import-0071
This value MUST NOT match the actual value of targetNamespace attribute 
information item in the enclosing WSDL 2.0 document. 

Transition history

raised on 14 Nov 2006 by Lawrence Mandel (lmandel@ca.ibm.com)

agreed on 7 Dec 2006

Remove assertion markup from Import-0003 and rewrite the assertion to avoid talking about imported components.

Acknowledgment cycle

announced by group on 11 Jan 2007

Action history

CR103: Duplicate assertions [link to this issue]

While creating some tests for assertions I've come across some assertions 
that I think specify the same requirement. I'll point these out here and 
suggest that a single assertion be defined for each restriction as 
multiple assertions may lead to problems interpreting the spec and will 
lead to ambiguity wrt the assertion that should be flagged as an error for 
a WSDL document that does not comply with the spec.

4. Schema-0016 
A WSDL 2.0 document MUST NOT refer to XML Schema components in a given 
namespace unless an xs:import or xs:schema element information item for 
that namespace is present or the namespace is the XML Schema namespace, 
http://www.w3.org/2001/XMLSchema, which contains built-in types as defined 
in XML Schema Part 2: Datatypes Second Edition [XML Schema: Datatypes]. 

Types-1300001
When resolving QNames references for schema definitions, the namespace 
MUST be imported by the referring WSDL 2.0 document. 

Transition history

raised on 14 Nov 2006 by Lawrence Mandel (lmandel@ca.ibm.com)

agreed on 7 Dec 2006

Reword the assertion Types-1300001, remove assertion markup, and add a reference to Schema-0016. Plus move the last sentence of 3.1.1.2 to Section 3.1.2.

Acknowledgment cycle

announced by group on 11 Jan 2007

Action history

CR104: One more duplicate assertion [link to this issue]

There is another assertion that I think has been duplicated or rather 
further clarified in other assertions in the WSDL 2.0 spec. According to 
the assertions, if, for example, Interface-0030 fails Description-0024 
will also fail. Although I like the broad coverage of Description-0024 I 
don't like the redundancy in the other assertions I've highlighted.

Description-0024
Each WSDL 2.0 or type system component of the same kind MUST be uniquely 
identified by its qualified name. 

Interface-0030
For each Interface component in the {interfaces} property of a Description 
component, the {name} property MUST be unique. 

Binding-0057
For each Binding component in the {bindings} property of a Description 
component, the {name} property MUST be unique. 

Endpoint-0065
For each Endpoint component in the {endpoints} property of a Service 
component, the {name} property MUST be unique. 

InterfaceOperation-0035
For each Interface Operation component in the {interface operations} 
property of an Interface component, the {name} property MUST be unique. 

Server-0063
For each Service component in the {services} property of a Description 
component, the {name} property MUST be unique. 

Schema-0018
A WSDL 2.0 document MUST NOT define the same element or type in more than 
one inlined schema. 

Transition history

raised on 14 Nov 2006 by Lawrence Mandel (lmandel@ca.ibm.com)

agreed on 7 Dec 2006

Remove markup from Description-0024.

Acknowledgment cycle

announced by group on 11 Jan 2007

Action history

CR105: More Duplicate and Non-Assertions [link to this issue]

Duplicates:

1. InterfaceOperation-1204000
This xs:anyURI MUST be an absolute IRI (see [IETF RFC 3987]). 

InterfaceOperation-1204002
Its value MUST be an absolute IRI (see [IETF RFC 3987]). 

Transition history

raised on 14 Nov 2006 by Lawrence Mandel (lmandel@ca.ibm.com)

agreed on 7 Dec 2006

Remove markup from InterfaceOperation-1204002.

Acknowledgment cycle

announced by group on 11 Jan 2007

Action history

CR106: More Duplicate and Non-Assertions [link to this issue]

Duplicates:

2. InterfaceOperation-1204001
These xs:anyURIs MUST be absolute IRIs (see [IETF RFC 3986]). 

InterfaceOperation-1204003
Its value MUST be an absolute IRI (see [IETF RFC 3987]). 

Transition history

raised on 14 Nov 2006 by Lawrence Mandel (lmandel@ca.ibm.com)

agreed on 7 Dec 2006

Remove markup from InterfaceOperation-1204003.

Acknowledgment cycle

announced by group on 11 Jan 2007

Action history

CR107: More Duplicate and Non-Assertions [link to this issue]

Non-Assertion:

1. InterfaceOpeation-0038
An Interface Operation component MUST satisfy the specification defined by 
each operation style identified by its {style} property. ? 

LM: There is nothing to check here. The styles defined in the adjuncts 
document all specify that in order to use them all the rules must be 
followed.

Transition history

raised on 14 Nov 2006 by Lawrence Mandel (lmandel@ca.ibm.com)

declined on 7 Dec 2006

Test confirms that ALL styles are applied (not just one at the implementations choosing.) This isn't captured anywere else.

Acknowledgment cycle

announced by group on 11 Jan 2007

CR108: Do MessageLabel-0006 and MessageLabel-0014 state the same requirement? [link to this issue]

MessageLabel-0006 states
The messageLabel attribute information item of a binding message reference 
element information item MUST be present if the message exchange pattern 
has more than one placeholder message with {direction} equal to the 
message direction. ? 

MessageLabel-0014 states
If the messageLabel attribute information item of a binding message 
reference element information item is absent then there MUST be a unique 
placeholder message with {direction} equal to the message direction. ? 

The way I read these assertions the first states the requirement for a 
message label in terms of the binding message reference and the second 
states the requirement in terms of the interface message reference. 

Do these two assertions state the same requirement?

Transition history

raised on 14 Nov 2006 by Lawrence Mandel (lmandel@ca.ibm.com)

agreed on 21 Dec 2006

Remove assertions MessageLabel-0004 and MessageLabel-0006.

Acknowledgment cycle

announced by group on 11 Jan 2007

Action history

CR109: SOAP Fault code issue [link to this issue]

Related to MessageTest-1G document, I have the following comment with 
the specification.

Currently, the soap fault code property can take any qname value.

It is fine for soap 1.1 but soap 1.2 constraints the qname value to be 
in a set of 5 predefined QNames.

It would be good if we could put an assertion to the spec stating that 
if soap1.2 is engaged the fault code qname must be in the predefined 
QName set.

Transition history

raised on 15 Nov 2006 by youenn fablet (youenn.fablet@crf.canon.fr)

agreed on 14 Dec 2006

Add an assertion that when using SOAP 1.2 the fault code QName is constrained to the five values from the spec.

Acknowledgment cycle

announced by group on 16 Feb 2007

Action history

CR110: Semantics of {http cookies} Property. [link to this issue]

This came up at the interop event in Dinard:

1. The spec is unclear.[1] What is the meaning of the {http cookies} property?

Does is state whether the service will send cookies or whether the
client needs to understand cookies.

I recommend that it mean that the service uses cookies in some meaning
way and that the client will be unable to use the service effectively
unless it supports cookies.

2. The spec is inconsistent. It says Binding components MAY indicate
..., and also that the property is REQUIRED.

The XML attribute is optional, but the property is REQUIRED.
Therefore, a Binding  component MUST indicate...

[1] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.html?content-type=text/html;%20charset=utf-8#http-cookies-decl

Transition history

raised on 15 Nov 2006 by Arthur Ryman (arthur.ryman@gmail.com)

agreed on 14 Dec 2006

1) Clarify that "true" means the service relies on cookies and client must understand them; 2) change "MAY indicate" to "indicates".

Acknowledgment cycle

announced by group on 15 Feb 2007

Action history

CR111: Mapping WSDL meps to the HTTP binding [link to this issue]

Reading the HTTP binding specification I have the following comment.

Currently the mapping from WSDL meps to HTTP binding  messages is 
described in section 6.4.1.

Basically it says that the wsdl input message is the http request 
message and the wsdl output message, if any is the http response message.
I wonder whether this description is sufficient for the inonly and 
especially robust-inonly wsdl meps.

At least, we might need to specify the HTTP code to use in the response, 
especially for the robust-inonly.

Should it be 200, 202 or left unspecified as it is currently?
Are there other things that need to be specified?

Transition history

raised on 15 Nov 2006 by youenn fablet (youenn.fablet@crf.canon.fr)

agreed on 21 Dec 2006

Specify 202 for the response to in-only, and 204 for the response to robust-in-only.

Acknowledgment cycle

announced by group on 15 Feb 2007

Action history

CR112: HTTP Location property definition [link to this issue]

Digging into the HTTP binding, I have the following comment, which is 
editorial IMHO.

As per section 6.4.2, the HTTP location property is currently computed 
from the HTTP location attribute (if present) and the http endpoint 
address property, which does create some issues especially with bindings 
with no or multiple endpoints.

I think we should change this part and have a direct @location to http 
location property mapping.

If this change is agreed, we should check that every part of the 
specification making reference to the http location property is not broken.
For instance, section 6.7.2.2.1 checks that no question mark is present 
in the location property to add a question mark before the generated 
query string. This check should be applied to both the location property 
and endpoint address property.

Transition history

raised on 15 Nov 2006 by youenn fablet (youenn.fablet@crf.canon.fr)

agreed on 15 Feb 2007

Accept proposal plus add a note (to {address}?) warning that ? and # in addresses can conflict with that added by the http/soap response bindings.

Acknowledgment cycle

announced by group on 20 Feb 2007

Action history

CR113: SOAP Response query string issue [link to this issue]

Continuing on the SOAP/HTTP Binding review,
I have a comment related to the SOAP binding section 5.10.4.2.1.

When using the SOAP-Response MEP, one needs to serialize the input data, 
if any, in the URI as a query string, following what is done in the HTTP 
binding (section 6.7.2).

The issue is that section 6.7.2 serialization is based on the query 
parameter separator and query parameter default separator properties. 
These properties, while present in the HTTP binding, are not brought in 
the SOAP binding.

Here are two suggestions to solve this small issue:
    - add to the soap/http binding the query parameter separator default 
property, which has the '&' value by default
    - do NOT add any of the @whttp:queryParameterSeparator and 
@whttp:queryParameterSeparatorDefault attributes, as this flexibility is 
not required by the soap binding IMHO.

This way, the serialization algorithm will always use the '&' character 
as the query parameter separator character.

Transition history

raised on 15 Nov 2006 by youenn fablet (youenn.fablet@crf.canon.fr)

agreed on 14 Dec 2006

Add the query separator and query separator default properties to the SOAP binding.

Acknowledgment cycle

announced by group on 15 Feb 2007

Action history

CR114: Mapping WSDL MEPs to SOAP MEPs [link to this issue]

Reviewing the soap binding, I have the following comments.

As of today, the SOAP binding defines how to map the inout mep to the 
request-response and soap-response meps.

The mapping from in-only and robust in-only meps to SOAP meps are not 
defined, which makes difficult or at least not very interoperable the 
use of these two WSDL meps with the SOAP binding.

It seems that the newest version of the SOAP1.2 specification 
(http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part2.html) will provide 
the SOAP/HTTP binding with the support of the request-optional response 
mep. This mep fits well with the robust-in-only mep at least.

It may therefore be interesting to add in the WSDL SOAP binding section 
a robust-inonly mep to soap mep mapping description.

Concerning the in-only mep, the situation seems less clear. Of course we 
could also bind the in-only mep to the request-optional response mep. On 
the other hand, a SOAP1.2 one way mep is under way but has no support in 
the SOAP1.2/HTTP binding.

Transition history

raised on 15 Nov 2006 by youenn fablet (youenn.fablet@crf.canon.fr)

agreed on 21 Dec 2006

Specify in section 5.10.4 the mapping of in-only and robust-in-only MEPs to the SOAP request-response MEP, taking advantage of the new 202.

Acknowledgment cycle

announced by group on 15 Feb 2007

Action history

CR115: Suggested editorial change for assertion Import-0072 [link to this issue]

I'd like to suggest a change for assertion Import-0072. The assertion 
currently contains two assertion statements. I'd like to split the 
assertion into two separate assertions.

The current Import-0072
If the location attribute in the import element information item is 
dereferencible then it MUST reference a WSDL 2.0 document and the actual 
value of the namespace attribute information item MUST be identical to the 
actual value of the targetNamespace attribute information item of the 
referenced WSDL 2.0 document. 

Suggested change
If the location attribute in the import element information item is 
dereferencible then it MUST reference a WSDL 2.0 document. The actual 
value of the namespace attribute information item of the import element 
information item MUST be identical to the actual value of the 
targetNamespace attribute information item of the referenced WSDL 2.0 
document. 

where the following assertion numbers will apply

Import-0072
If the location attribute in the import element information item is 
dereferencible then it MUST reference a WSDL 2.0 document.

Import-????
The actual value of the namespace attribute information item of the import 
element information item MUST be identical to the actual value of the 
targetNamespace attribute information item of the referenced WSDL 2.0 
document. 

Transition history

raised on 15 Nov 2006 by Lawrence Mandel (lmandel@ca.ibm.com)

agreed on 21 Dec 2006

Accept proposal, though adding "If the location attribute in the import element information item is dereferencable, then ..." to the start of the new assertion.

Acknowledgment cycle

announced by group on 11 Jan 2007

Action history

CR116: 6.7.1.1 Construction of the request IRI using the http location [link to this issue]

Given this instance data:
 <root>
   <foo>1</foo>
   <foo>2</foo>
 </root>

With http:location="t"
we should obtain "t?foo=1&foo=2"

With http:location="t/{foo}"
we should obtain "t/1?foo=2"

With http:location="t/{foo}/{foo}"
we should obtain "t/1/2"

With http:location="t/{foo}/{foo}/{foo}"
should we obtain an error (we don't have 3 foo elements in the instance
data) or, should we obtain "t/1/2/1" or "t/1/2/2" ?

As a side comment, using element names in the http:location adds an
additional message schema constraint, in addition to the ones already
defined the IRI style: those element names shouldn't be optional. If one
of those http:location element names is defined as optional in the
schema, not including it in the instance data could result in a runtime
error.

Transition history

raised on 16 Nov 2006 by Philippe Le Hegaret (plh@w3.org)

agreed on 21 Dec 2006

1) Rewrite HTTPSerialization-5073 to talk about types rather than instances.

2) Say each token SHOULD match something in the instance.

3) If there is no match, replace the token with the empty string.

4) A token may appear more than once, in which case it is replaced by corresponding repeated elements in the instance. [ednote: I think this is already in the text.]

Acknowledgment cycle

announced by group on 15 Feb 2007

Action history

CR117: Re: 6.7.1.1 Construction of the request IRI using the http location [link to this issue]

Following on philippe's message, there are also ambiguous cases that 
might happen.

Given this schema:
<element name=root>
    <sequence>
        <element name=person type=string minOccurs=0/>
        <element name=address type=string minOccurs=0/>
        <element name=surname type=string minOccurs=0/>
    </sequence>
</element>

Given this instance data:
<root>
    <person>foo</person>
    <address>/</address>
    <surname>foo</surname>
</root>
with http:location="foo/{person}/{address}/{surname}

we will obtain foo/foo///foo, which leads to ambiguous parsing on the 
server side (as address='' and surname='/foo' will also lead to the same 
uri-encoded data).

Should we prevent this case and escape the '/' character in url path 
encoded data?

There is also the case of the '?' special character that may lead to 
issues in determining when begins the query string.
Should we prevent this case and escape the '?' character in url path 
encoded data?

Transition history

raised on 22 Nov 2006 by Youenn Fablet (youenn.fablet@crf.canon.fr)

agreed on 8 Feb 2007

Resolved by accepting proposal for Option 1, plus correct placement of "/" and "?" (should be allowd in query params, not in paths), change syntax to "!" from "~", and add a constraint that the query parameter separator must be encoded.

Acknowledgment cycle

announced by group on 15 Feb 2007

Action history

CR118: Suggested removal of 2 assertions [link to this issue]

I'd like to request that the following 2 assertions be removed from the 
WSDL 2.0 spec. as they are all handled by the WSDL 2.0 schema and schema 
validation.

Endpoint-0065
For each Endpoint component in the endpoints property of a Service 
component, the name property MUST be unique.

InterfaceFault-0032
For each Interface Fault component in the interface faults property of an 
Interface component, the name property must be unique.

Transition history

raised on 17 Nov 2006 by Lawrence Mandel (lmandel@ca.ibm.com)

agreed on 18 Jan 2007

Remove assertion markup from Endpoint-0065, InterfaceFault-0032, and InterfaceOperation-0035.

Acknowledgment cycle

announced by group on 8 Feb 2007

Action history

CR119: Missing attribute in section 6.2 [link to this issue]

I assume this is editorial but it seems that 
wsdl:binding/wsdl:operation/@whttp:queryParameterSeparator is missing in 
the HTTP binding syntax summary while present in section 6.4.4.

Transition history

raised on 22 Nov 2006 by Youenn Fablet (youenn.fablet@crf.canon.fr)

agreed on 11 Jan 2007

Fix editorially.

Acknowledgment cycle

announced by group on 15 Feb 2007

Action history

CR120: SOAP Response and IRI style [link to this issue]

When the soap response MEP is used to bound an in-out operation, the 
input being defined by a schema,
the input is serialized in the URI following the url-encoded 
serialization (section 6.7.2).

This serialization requires the use of the IRI style which puts a 
constraint on the kind of operations that can be bound to the soap 
response mep.

It seems sensible to me that inout operations can be bound to the 
soap-response mep if:
    - the input message is a #none kind of message (I did not found any 
text about this case by the way, I may have missed something)
    - the input message is a #element kind of message with the element 
schema following the IRI style constraints

Does this make sense?

Should we add some text in the specification to clarify this?

Transition history

raised on 22 Nov 2006 by Youenn Fablet (youenn.fablet@crf.canon.fr)

agreed on 11 Jan 2007

Agreed, allow #none in addition to IRI style.

Acknowledgment cycle

announced by group on 20 Feb 2007

Action history

CR121: WSDL enhancement request [link to this issue]

We would like the WSDL format to support deprecation.   If I deprecate a
web method in my java middleware I would like it to show up as obsolete
in my .Net client.

Transition history

raised on 7 Nov 2006 by Eric Foutz (eric_foutz@symantec.com)

declined on 11 Jan 2007

Schedule prevents us from adding new capabilities at this point. Extensibility mechanisms can be used to add support for deprecation.

Acknowledgment cycle

announced by group on 11 Jan 2007

CR122: Clarification about ignoreUncited behaviour [link to this issue]

Reading section 6.7.2, I am not entirely sure of the right behaviour of 
the whttp:ignoreUncited property.
Here is my current understanding. Can someone verify and correct it if 
needed?

Input parameters not cited in whttp:location are serialized to build a 
query string.
This query string is then added to the message body or the request IRI

If the operation is POST or PUT, the query string value is serialized in 
the message body, no matter the value of whttp:ignoreUncited.
It is unclear then whether section 6.7.2.2.2 should be considered in 
that case.
If we do consider it, then if ignoreUncited=false, we are requested to 
serialize the data in the request IRI according section 6.7.2.2.3.
This section dealing only with GET/DELETE requests, we can conclude that 
the data is not serialized in the request IRI (?)
The example in section 6.7.2.2.4 follows that rule.
If my understanding is right, then we should maybe clearly state that 
section 6.7.2.2.2 is only applicable to requests that have no body.

If the operation is GET or DELETE, we have two cases:
- If ignoreUncited=false, the query string is serialized in the 
request IRI
- If ignoreUncited=true, the query string is not serialized in the 
request IRI.
In the latter case, part of the input data is not serialized at all in 
the request. Is it the expected behaviour?

Transition history

raised on 7 Dec 2006 by Youenn Fablet (youenn.fablet@crf.canon.fr)

declined on 11 Jan 2007

Yes, this is the expected behavior. It is possible to bind some XML data in such a way that parts of that data are omitted from the message. It is also possible that this may cause problems in some cases. But adding a constraint about using these features together is somewhat unnatural and may constrain away useful behavior in other cases. WG did not change the spec in response to this issue.

Acknowledgment cycle

announced by group on 11 Jan 2007

CR123: HTTP Method selection [link to this issue]

Reading section 6.3.1 of the latest draft, the presence of the safe 
property may change the selected HTTP method (GET or POST typically).
If we have operation foo that is marked as safe:
- a processor supporting the HTTP binding and the safety extension 
will select the GET method for operation foo
- a processor supporting the HTTP binding but not the safety 
extension will select the POST method for operation foo
This may prevent interoperability.
To ensure interoperability, the engagement of the HTTP binding extension 
should in fact generally imply the engagement of the safety extension.
The cost of the safety extension being low, I think it makes sense to 
tighten the link between the safety and HTTP extensions.

Transition history

raised on 7 Dec 2006 by Youenn Fablet (youenn.fablet@crf.canon.fr)

agreed on 18 Jan 2007

Add the dependency on the safety extension from the HTTP binding.

Acknowledgment cycle

announced by group on 15 Feb 2007

Action history

CR124: editorial: features and properties in "xml representation" sections [link to this issue]

Features and properties are gone, correct?  They seem to have disappeared from the component model in part one, but still seem to be there (in the editor's copy) in the XML representations.

Transition history

raised on 7 Dec 2006 by Amelia A Lewis (alewis@tibco.com)

agreed on 18 Jan 2007

Close with editorial actions already performed.

Acknowledgment cycle

announced by group on 16 Feb 2007

Action history

CR125: problem with pattern attribute definition? [link to this issue]

So, the pattern AII is REQUIRED (2.4.2 ed copy, bullet 3).  But if it 
*doesn't exist*, we supply a default value (2.4.2.2, final sentence).
							
If that's the way that we always describe defaults (required attribute, which 
if it isn't there has a value anyway), then our description is really painfully 
awkward.  Is this a consequence of describing the "XML representation" via the 
infoset?  Is it boneheaded of me to think that if I see "the pattern attribute 
information item is required" that @pattern will always appear on operation?

Heh.  Can XPath retrieve the value of a defaulted attribute?  That's not apropos 
of much of anything, mind.

Transition history

raised on 7 Dec 2006 by Amelia A Lewis (alewis@tibco.com)

agreed on 18 Jan 2007

Adopt proposal: http://lists.w3.org/Archives/Public/www-ws-desc/2006Dec/0038.html + add ? to the pseudo-syntax + change the schema.

Acknowledgment cycle

announced by group on 16 Feb 2007

Action history

CR126: Re: New interchange results [link to this issue]

Recall that the interchange format now declares the set of extensions that 
it has engaged. 

If an unengaged extension is encountered then two cases occur.

1. The extension is marked as wsdl:required="false" either explicitly or 
by default. In this case the component model is valid and omits all the 
extension properties and components.

2. The extension is marked as wsdl:required="true". In this case the 
component model is invalid. However, I just checked the spec and we don't 
spell this out. I think we need an issue.

Jonathan, I proposed we add an assertion:

A WSDL 2.0 document that contains a required unengaged extension is 
invalid.
						

Transition history

raised on 30 Nov 2006 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 18 Jan 2007

Proposal accepted.

Acknowledgment cycle

announced by group on 16 Feb 2007

Action history

CR127: Message Dispatching Primer Section [link to this issue]

Reading section 5.1 in the primer, it is written that assigning unique 
QNames of GED as inputs within the interface of the service is 
sufficient to disambiguate the types of the messages that are received.

While this is certainly true for a typical SOAP service that uses the 
Request/Response mep, this is not the case when the SOAP/Response mep is 
used.
In that case, the GED QName is not sent in the message, only the 
subchildren local names are sent in the url.
It would be easy to have two different GED QNames with the same 
subchildren local names.
I do not know whether we should improve the primer, but this might be 
worth noting it anyway.

The same kind of issue also arises with the HTTP binding.
In this case, the dispatching may be done according the url, the method, 
the content-type and possibly other bits of information.
This flexibility is good if we are going from a service to a WSDL document.
In a typical WSDL first situation, it may however be hard for authors 
and tools to check that message dispatching will never be ambiguous.
A few guidelines may help with that respect.
						

Transition history

raised on 13 Dec 2006 by Youenn Fablet (youenn.fablet@crf.canon.fr)

agreed on 18 Jan 2007

Close with proposal in CR134.

Acknowledgment cycle

announced by group on 1 Feb 2007

CR128: Interface Inheritance Clarification [link to this issue]

I believe a clarification is waranted within part 1: core language re: 
interface inheritance.

The following sentence appears to imply that an interface inherits faults 
and operations from interfaces defined within the extends attribute AND from 
interfaces extended indirectly, i.e. interfaces defined within the extends 
attribute of extended interfaces, etc ...

"To avoid circular definitions, an interface MUST NOT appear as an element 
of the set of interfaces it extends, either directly or indirectly."

The next sentence, however, seems to imply that an interface inherits 
content only from the interfaces listed within its extends attribute:

"The set of operations available in an interface includes all the operations 
defined by the interfaces it extends, along with any operations it directly 
defines. "

If the first supposition is correct, then what is the use case for being 
able to list more than one extended interface within the extends attribute?

Please advise.  Thanks.

Transition history

raised on 14 Dec 2006 by Cindy McNally (cindymcnally_6@hotmail.com)

agreed on 18 Jan 2007

Reword as: "The set of operations available in an interface includes all the operations defined by the interfaces it extends directly or indirectly, together with any operations it directly defines."

Acknowledgment cycle

announced by group on 16 Feb 2007

Action history

CR129: RE: Comment on Fragment Identifiers [link to this issue]

As you may know, the WS-Policy WG has been doing some work on defining
element identifiers for WSDL 1.1 elements.  We are trying to align this
work with the WSDL 2.0 fragment identifiers described in Appendix A.2 of
the WSDL 2.0 Candidate Recommendation draft of 2006-03-27.

In looking at Appendix A.2 I came across two situations where I think the 
syntax can be improved.  Consider
  wsdl.interfaceMessageReference(interface/operation/message)
this fragment identifier takes 3 parameters.  The first two take names as 
values while the third takes a message label whose value can only be 
"input" or "output".  Having a parameter that takes a keyword as value 
seems foreign to the general design in which parameters take names as 
values.  Thus, I suggest that the label be added to the name of the 
fragment identifier and it have only two parameters, thus:
  wsdl.interfaceMessageInput(interface/operation)
  wsdl.interfaceMessageOutput(interface/operation)

The following row in the table can also be improved.
  wsdl.interfaceFaultReference(interface/operation/message/fault)
can be replaced by two identifiers
  wsdl.interfaceInFault(interface/operation/fault)
  wsdl.interfaceInFault(interface/operation/fault)

Similar suggestions apply to 
  wsdl.bindingMessageReference(binding/operation/message) and
  wsdl.bindingFaultReference(binding/operation/message/fault)

Transition history

raised on 13 Dec 2006 by Ashok Malhotra (ashok.malhotra@oracle.com)

declined on 8 Feb 2007

Close with no action.

Acknowledgment cycle

announced by group on 21 Dec 2006

CR130: Question on double curly braces with HTTP Location [link to this issue]

Part 2 section 6.7.1.1 which describes the curly brace template syntax used
for {http location} contains the sentence:

"A double curly brace (i.e. "{{" or "}}") MAY be used to include a single,
literal curly brace in the request IRI."

I am a bit confused about why this sentence is here. I assume it is not
describing how to include a literal curly brace within the string enclosed
by matching curly braces in the WSDL because this string must be the local
name of an element, which by definition cannot contain a curly brace.

E.g.   whttp:location="?first={First{{Name}" is meaningless because
'First{Name' is not a valid local name.

So instead it seems to describe how to include a curly brace within the
value substituted for the local name enclosed within matching curly braces
during the construction of the request IRI.

E.g. for whttp:location="?first={FirstName}", FirstName might be substituted
with the value 'Marvin{{' in the request IRI which represents the literal
value 'Marvin{'

Is this correct? If so, does this need to be specified here in Part 2 - it
seems it belongs in the specification that describes how to construct the
message (e.g. HTTP spec for an HTTP request)? If my understanding is
incorrect could someone please explain with some examples.

Transition history

raised on 18 Dec 2006 by John Kaputin (gmail) (jakaputin@gmail.com)

agreed on 18 Jan 2007

httpLocation ::= CharData? (( openBrace | closeBrace | elementName ) CharData?)*
CharData ::= [^{}]*
openBrace ::= '{{'
closeBrace ::= '}}'
elementName ::= '{' NCName '}'

Plus reference to EBNF syntax in XML spec.

Acknowledgment cycle

announced by group on 15 Feb 2007

Action history

CR131: Clarifying assertion for HTTP Location [link to this issue]

Part 2 section 6.7.1.1 Construction of the request IRI using the {http
location} property.

This section contains the assertion:

"Strings enclosed within single curly braces MUST be element names from the
instance data of the input message."

I assume 'input message' here refers generically to any input data for the
HTTP request (i.e. to a WSDL input, output or fault message element).   To
make this clearer and to keep it consistent with the description at
hyperlink "instance data", perhaps you could restate this something like:

"Strings enclosed within single curly braces MUST be element names from the
instance data of the input, output or fault message."

Transition history

raised on 18 Dec 2006 by John Kaputin (gmail) (jakaputin@gmail.com)

declined on 11 Jan 2007

Neither the HTTP binding nor the SOAP binding support any MEPs beyond in-out, in-only, and robust-in-only.

Acknowledgment cycle

announced by group on 11 Jan 2007

CR132: RE: Proposal for CR108 [link to this issue]

Per this morning's call, CR108 is closed, but Arthur's suggestion will
become a new issue.

AIUI, he is proposing something along the lines of these four new
assertions, which while they may be (I'm still not sure) strictly redundant
with the existing assertions, would provide more intelligible error messages
to users:

Add to 2.5.3:

- If the local name is "input" then the message exchange pattern
MUST have at least one placeholder message with direction "In".

- If the local name is "output" then the message exchange pattern
MUST have at least one placeholder message with direction "Out".

- If the local name is "infault" then the message exchange pattern
MUST either have at least one placeholder message with direction "In" and
use the Fault Replaces Message propagation rule, or have no placeholder
message with direction "Out" and use the Message Triggers Fault propagation
rule.

- If the local name is "outfault" then the message exchange pattern
MUST either have at least one placeholder message with direction "In" and
use the Message Triggers Fault propagation rule, or have at least one
placeholder message with direction "Out" and use the Fault Replaces Message
propagation rule.

However, I'm not at all sure the last two are 1) correctly stated, 2) don't
overconstrain the development of extended MEPs, or 3) any less confusing
then what we've got already.

Transition history

raised on 21 Dec 2006 by Jonathan Marsh (jonathan@wso2.com)

agreed on 8 Feb 2007

First two bullets above, plus:

- If the local name is "infault" then the message exchange pattern MUST support at least one fault in the "In" direction.

- If the local name is "outfault" then the message exchange pattern MUST support at least one fault in the "Out" direction.

Acknowledgment cycle

announced by group on 16 Feb 2007

agreement by reviewer on 16 Feb 2007

Action history

CR133: {http location} ignored on SOAP request-response MEP? [link to this issue]

I was just looking at Adjuncts 5.10.4 [1], and see that for the SOAP
request-response MEP the immediate destination is "the value of the WSDL
{address} property of the Endpoint component."

For the SOAP response MEP the immediate destination is "the value of the
WSDL {address} property, modified by the {http location} property following the
rules described in section 6.7.2 Serialization as
application/x-www-form-urlencoded."

From this I infer the {http location} is ignored for the SOAP
request-response MEP, including (after CR114 closure) the use of in-only and
robust-in-only WSDL MEPs.

Is this intentional?  I recall discussing using URI templates with POST,
where the body would contain the full data and the URI might carry some
duplicates.  Also, disabling {http location} for POST seems quite unRESTful.

If this is simply an editorial mistake, then we should copy the {http
location} handling text above into the SOAP request-response MEP
description.

[1] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.html?foo=:;content-type=text/html;%20charset=utf-8#wsdl-mep-soap-mep

Transition history

raised on 21 Dec 2006 by Jonathan Marsh (jonathan@wso2.com)

agreed on 11 Jan 2007

Clone the text from soap-response MEP to request-response MEP.

Acknowledgment cycle

announced by group on 15 Feb 2007

Action history

CR134: Operation dispatch when there isn't a SOAP body. [link to this issue]

Axis2 has encountered some issues with operation dispatch using the HTTP
binding.

For SOAP messages, Axis2 supports a variety of operation dispatch
mechanisms, including out-of-the-box support for wsa:Action, soap action,
and unique body QNames.  Both wsa:Action and unique body QNames are noted as
mechanisms enabling easy operation dispatch in the WSDL 2.0 primer [1].
Unique QNames and soap actions are used for tests in our test suite, to
eliminate the need for operation dispatch extensions (such as wsa:Action).

However, when the HTTP binding is in use, the SOAP-specific mechanisms
generally aren't sufficient.  There is no wsa:Action header or soap action
parameter.  When using GET, there is no body and thus no unique body QName
appearing in the message.  The same is true in the SOAP binding when using
the soap-response MEP.  The primer doesn't give any advice on what to do
here.

For an HTTP service, the obvious choice of mechanism for message dispatch
would be the URL of the service - defining a unique combination of the
{address} and the {http location} for each operation.  It would be desirable
to document something along this line in the primer.

There is a twist though - {http location} templating means there isn't a
fixed set of URLs to dispatch on - the URL is dependent upon the instance
data, and there is always the possibility that different data inserted into
different templates results in the same URL.  In general dealing with
templating in operation dispatch is somewhat complex.

To support various styles of URI generation, yet avoid the complexities of
messing with templates, I propose an operation dispatch mechanism that
considers the {address} and the part of the {http location} property
preceding the first unescaped "{" as a unique dispatching string.  This
supports the following scenarios:

1) absolute {http location} values
2) {http location} values that begin with the operation name
3) {http location} values that are unique per operation (but don't
   quote the operation name verbatim)
4) {http location} values that begin with a fixed set of path segments
   or query parameters unique to the operation.

While this mechanism it something Axis2 could implement independent of the
specification, it seems to me worthwhile to document the mechanism in the
Primer.

Proposed text:to append to [1].

  When using the HTTP Binding, or when using the SOAP Binding with the
  soap-response MEP, there is no SOAP envelope in a request message, and thus
  mechanisms other than unique qualified names of global element declarations,
  or headers such as wsa:Action, must be considered.  In these cases, the
  {address} and {http location} properties may be constructed so as to provide
  a location that can be correlated uniquely with an operation.  For instance,
  one could prefix the {http location} property with the operation name, or
  one could ensure that the portion of the {http location} preceding the first
  unescaped "{" character be unique per operation.
  
[1] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-primer.html#adv-message-dispatch

Transition history

raised on 2 Jan 2007 by Jonathan Marsh (jonathan@wso2.com)

agreed on 18 Jan 2007

Proposal accepted.

Acknowledgment cycle

announced by group on 1 Feb 2007

agreement by reviewer on 1 Feb 2007

Action history

CR135: Operation dispatch when there isn't a SOAP body. [link to this issue]

Furthermore, when a unique {http location} property is required for
operation dispatch, one must specify this per-operation detail, which
conflicts with the desire to define generic (interfaceless) HTTP bindings.
A potential solution would be to add another feature enabling unique
per-operation effective {http binding} values without specifying them at the
level of individual operations.  Here is a facility that might help:

Add a new whttp:locationDefault attribute to the binding element, which
would populate (conceptually) the {http location} property of each binding
operation without an {http location} specified.  In addition, a new token,
#operation, is introduced which is essentially a variable expanding to the
local part of the operation name.  Thus:

  <binding type=".../http" whttp:locationDefault="{#operation}?p={p1}"/>

Would be equivalent to:

  <binding type=".../http">
    <operation ref="firstOperation"
                  whttp:location="firstOperation?p={p1}"/>
    <operation ref="secondOperation"
                  whttp:location="secondOperation?p={p1}"/>
  </binding>

[1] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-primer.html#adv-message-dispatch

Transition history

raised on 2 Jan 2007 by Jonathan Marsh (jonathan@wso2.com)

declined on 1 Feb 2007

Too late to consider such a proposal. Close with no action.

Acknowledgment cycle

announced by group on 1 Feb 2007

agreement by reviewer on 1 Feb 2007

CR136: What does this table row mean? [link to this issue]

The first row of Core Table D-1 [1] lists "-" as a component with name and
parent properties.  What does this mean?  I thought maybe it meant they were
common to all components, but other rows list name and parent where
appropriate.

[1] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-
type=text/html;%20charset=utf-8#component-summary

Transition history

raised on 3 Jan 2007 by Jonathan Marsh (jonathan@wso2.com)

agreed on 8 Feb 2007

Add clarification about what the cell value "-" means.

Acknowledgment cycle

announced by group on 8 Mar 2007

Action history

CR137: Spelling mistake in Part 2 [link to this issue]

A minor typo error - the word 'component' is mispelt as 'compoment' in two
places in Part 2:

5. WSDL SOAP Binding Extension and

6. WSDL HTTP Binding Extension

Transition history

raised on 4 Jan 2007 by John Kaputin (gmail) (jakaputin@gmail.com)

agreed on 8 Feb 2007

Accepted.

Acknowledgment cycle

announced by group on 15 Feb 2007

Action history

CR138: {element declaration} for Interface Fault component [link to this issue]

The XML Representation of the Interface Fault Component [section 2.3.2 -
Part 1] defines the {element declaration} property to be of type xs:QName.
This maybe changed to acommodate a union of xs:QName and xs:token.

Transition history

raised on 5 Jan 2007 by Ramkumar Menon (ramkumar.menon@gmail.com)

agreed on 8 Feb 2007

Make faults the same as message references (add {message content model} property, #any, #other, #element, #none values.)

Acknowledgment cycle

announced by group on 22 Feb 2007

agreement by reviewer on 22 Feb 2007

Action history

CR139: Suggestion on Part - 2 : Adjuncts [link to this issue]

The Abstract section of Part 2 defines WSDL 2.0 as follows:-

"WSDL 2.0 is an XML format for describing network services as a set of
endpoints operating on messages containing either document-oriented or
procedure-oriented information"

I had a suggestion - apologies if its not worth it :-)
Maybe we could
i) Rephrase this definition,  and
ii) Perhaps have one common definition that can be inlined in all parts of
the spec if necessary. [Primer, Part 1 and Part 2]


In any case,  w.r.t the current definition, I had a few thoughts.
a) "network services" maybe a non-standard term. The term "web services"
itself cd be used.
b)  The latter part of the definition states --> operating on messages
containing "document oriented information" ---- the usage "document oriented
information" is not very clear to the reader. [though I can understand the
same :-).]

Transition history

raised on 6 Jan 2007 by Ramkumar Menon (ramkumar.menon@gmail.com)

agreed on 8 Feb 2007

Make the part 2 sentence the same as the part 1 sentence. Fix "network service" in the intro.

Acknowledgment cycle

announced by group on 15 Feb 2007

Action history

CR140: Re: Spec Issue - associating local names in HTTP location with element declarations [link to this issue]

Sorry folks, I have just realized that I had misinterpreted the element
local name enclosed in curly braces when I made the previous post.  The
element referred to by the local name does not correspond directly to the
name of the element declaration in the interface input message as I stated,
but rather it corresponds to some element within the internal tree
representation of that input message, as defined by the element declaration.
So, please ignore the stuff about matching the local name to some Element
Declaration's qname.

However, I think the question about user-defined MEPs still applies. What
happens if the MEP allows multiple input messages or infaults as well as
input messages?  Could the element local names used in the binding
operation's {http location} relate to different messages or faults,
potentially referring to different element declarations. If so, how are the
local names in the http location template mapped to the correct message or
fault instance data?

thanks,
John Kaputin.


On 1/4/07, John Kaputin (gmail) <jakaputin@gmail.com> wrote:
>
> Part 2, 6.7.1.1 Construction of the request IRI using the {http location}
> property
>
> This section contains the following assertion concerning the element whose
> local name is enclosed by curly braces:
> This element MUST NOT carry an xs:nil attribute whose value is "true".
>
> To check this assertion we need to be able to identify the corresponding
> element declaration within an XML schema so we can then check if it has a
> xs:nil attribute. However, I foresee some problems in identifying the
> corresponding element declaration. I think these problems arise because the
> element's local name is used in the enclosing curly braces (rather than its
> qname) or because the {http location} property is associated with the
> binding operation (rather than with a binding message reference).
>
> I'll try to explain ... I need to find the Interface Operation associated
> with the Binding Operation containing the {http location} and then locate an
> Interface Message Reference that refers to an Element Declaration with the
> same name that was specified within the curly braces in the {http location}.
> But {http location} specifies the element local name, not qname. This is not
> a problem for the 3 MEPs now defined in Part 2 because for those MEPs there
> can be only 1 input message and no infaults. So, all I need to do is find
> the Interface Message Reference with direction 'in', get its Element
> Declaration's qname and check that the local part matches the local name
> used in the {http location}, then find the corresponding element declaration
> in an XML schema to check for the xs:nil attribute.
>
> However, user-defined MEPs could specify multiple input messages or both
> input and infault messages, where the Interface Message References or
> Interface Faults associated with the Interface Fault References could refer
> to different Element Declarations whose qnames have different namespaces but
> the same local part. In this case, I cannot uniquely associate the element
> local name used in the {http location} with an Element Declaration referred
> to by a message in the Interface Operation. I am not sure how likely this
> scenario is, but I believe it is possible.
>
> One solution might be to use a qname (i.e. a string of type xs:qname)
> within the enclosing curly braces. Another could be to associate the {http
> location} property with the Binding Message Reference and Binding Fault
> Reference (or Binding Fault) components, rather than with Binding Operation.
>
> Please advise how to resolve this issue or let me know if I have
> misunderstood the requirements.
>
> Thanks,
> John Kaputin.
>
>

Transition history

raised on 7 Jan 2007 by John Kaputin (gmail) (jakaputin@gmail.com)

declined on 11 Jan 2007

Neither the HTTP binding nore the SOAP binding support any MEPs beyond in-out, in-only, and robust-in-only.

Acknowledgment cycle

announced by group on 11 Jan 2007

CR141: Re: Spec Issue - unmatched single curly braces in HTTP Location [link to this issue]

Here's another example that highlights the need to decide on precedence when
parsing curly braces in the HTTP location template. It might be better if
the spec made this choice clear.

Consider the template (or a template fragment) "{{{town}}}". If inner-most
matching pairs of single braces take precedence this is interpreted as
{{,{town},}} and after substitution of element values and literals it
becomes something like "{London}".  However if, as in the case of Woden, the
double curly brace notation takes precedence over any potentially matching
single braces, then this is interpreted as {{,{,town,}},} which is invalid
because it has unmatched single curly braces (i.e. it has a left and a right
brace that enclose the string "town}}" which cannot be an element local
name, even after the double brace is replaced by a single brace).  If the
first interpretation seems more reasonalbe, the spec should probably be
clearer about how the double curly brace syntax is applied.

regards,
John Kaputin.

On 1/4/07, John Kaputin (gmail) <jakaputin@gmail.com> wrote:
>
> In defining the {http location} property the spec describes enclosing an
> element local name within curly braces and it describes using double curly
> braces to specify a single literal curly brace, but it is silent on the
> possibility of extraneous, unmatched single curly braces appearing in the
> HTTP location template. For example, "temperature/{town}" is okay but what
> about "temp{era{ture/{town}"?
>
> One option is to do nothing - just include these unmatched curly braces in
> any derived HTTP location value after any valid element and literal
> substitution has occurred (e.g. the derived location becomes
> "temp{era{ture/London"), but this may result in a meaningless value in which
> case this option is not very helpful.
>
> A second option is to treat such unmatched single curly braces as an error
> and add a suitable assertion to the spec so that implementations can catch
> this as an error and report it in a standard way.
>
> Currently, my implementation in Apache Woden flags these unmatched braces
> as an error but I don't have an assertion to base the validation logic and
> an error message on.
>
> Perhaps the first question in this situation is which of the multiple
> single curly braces to use for the 'pair' - e.g. left-most, inner-most or
> outer-most.  My Woden implementation assumes inner-most, so if multiple left
> braces precede a right brace, the right most one will be paired with the
> right brace and the others will be considered extraneous and unmatched. So
> in "temp{era{ture/{town}" the 1st and 2nd left braces are extraneous and the
> 3rd is paired with the right brace (e.g. "temp{era{ture/London").
> Likewise, if multiple right braces follow a left brace the left most one is
> paired with the left brace.
>
> I'm not sure if the spec actually needs to say anything about the pairing
> strategy. The Woden implementation does not stop processing on an error, but
> continues to process the entire WSDL, returning a possibly invalid WSDL
> model and reporting all errors. So for this continue-on-error approach a
> pairing strategy much be chosen. Other implementations may stop-on-error, in
> which case it's sufficient just to detect that extraneous, unmatched curly
> braces exist without considering how to pair them off with the opposite
> brace. I do wonder though if different implementations adopting the
> continue-on-error approach chose different pairing strategies, if this could
> lead to interoperability problems.
>
> The relevant section of the spec is Part 2, 6.7.1.1 Construction of the
> request IRI using the {http location} property.
>
> regards,
> John Kaputin.
>

Transition history

raised on 7 Jan 2007 by John Kaputin (gmail) (jakaputin@gmail.com)

Subsumed by issue(s) on 11 Jan 2007

Resolved as duplicate of 130.

CR142: Leftovers of trailing slashes in replacement parameters [link to this issue]

Example 6-3 in the latest revision of "WSDL 2.0 Part 2: Adjuncts" quotes the following code:

<operation ref='t:data'
whttp:inputSerialization='application/x-www-form-urlencoded'
whttp:location='temperature/{town/}'
whttp:method='POST' />

As the trailing slash in replacement parameters is not legal
"{town/}" should accordingly be changed to "{town}".

Transition history

raised on 10 Jan 2007 by georgi.georgiev.pv@hitachi.com (georgi.georgiev.pv@hitachi.com)

agreed on 15 Feb 2007

Fix editorially.

Acknowledgment cycle

announced by group on 16 Feb 2007

Action history

CR143: Tranfer-Encoding vs Content-Encoding [link to this issue]

I talked to Yves Lafon and it looks like we want to reconsider this
indeed.

Transfer-Encoding is hop-by-hop, while Content-Encoding is end-to-end.

This means that if the HTTP implementation is using a proxy, the proxy
will see the Transfer-Encoding: gzip, will unzip it, and not necessarily
forward the request as TE gzip. I don't think this is what we intended
in the WSDL specification. That wouldn't be the case for
Content-Encoding. 

So, we should consider binding the {http transfer coding} property to
the HTTP Content-Encoding header. Both can work for SOAP and HTTP
binding. The XML Protocol Working Group even considered defining a new
content encoding for MTOM instead of a mime type but gave up given the
difficulties of introducing a new TE in HTTP.

Philippe

On Fri, 2007-01-12 at 10:49 -0500, Philippe Le Hegaret wrote:
> On Fri, 2007-01-12 at 14:30 +0530, keith chapman wrote:
> > Hi,
> > 
> > Does the spec state the HTTP header to use when a message is encoded
> > as gzip. I  had a look at section "6.3.2 HTTP Transfer Coding
> > Selection" it does not state anything to this regard. The test
> > framework looks for the header "Transfer-Encoding=gzip" but axis2 uses
> > the header "Content-Encoding: gzip" .
> 
> Given
> [[
>   This [Transfer-Encoding] differs from the content-coding in that the
> transfer-coding is a property of the message, not of the entity.
> ]]
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.41
> 
> I believe Transfer-Encoding is the one to use. With the set of value
> available in section 3.6 of the HTTP RFC [1]. Note that "identity" can't
> be used anymore in as a transfer codings, according to the latest
> editors version of the HTTP RFC that includes errata [2].
> 
> Given your question, the spec needs clarification.
> 
> Philippe
> 
> 
> [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6
> [2]
> http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/draft-lafon-rfc2616bis-latest.html#transfer.codings
> 
						

Transition history

raised on 16 Jan 2007 by Philippe Le Hegaret (plh@w3.org)

agreed on 8 Feb 2007

Rename transfer coding property and attribute to content encoding, ensure the description is clear that it sets the Content-Encoding HTTP header and makes corresponding changes to the body.

Acknowledgment cycle

announced by group on 20 Feb 2007

Action history

CR144: RE: LocationTemplate-1G totally hosed ;-) [link to this issue]

> Section 5.10.4.2 tells that when soap-response is in use, section 6.7.2
> and the x-www-form-urlencoded serialization should be followed. This
> section describes how to build the request URL from whttp:location,
> whttp:ignoreUncited and the message parameters.


{http ignore
uncited} isn't among the parameters listed as supported by the SOAP binding.
It doesn't appear in the interchange format, so it shouldn't really have
been available for you to use to pass that testcase!  

Also, with CR133 we made the request-response MEP correspond to the
soap-response MEP, apparently including (with the above change) auto-adding
query params and honoring ignoreUncited.  However, it seems to me much
better to keep SOAP request-response parallel to serializing as
application/xml under the HTTP binding, which would not add query parameters
automatically and thus there's no need for ignoreUncited.

> In any case, if the current state is as you describe, is it a clear
> decision from the working group?

I'm just trying to interpret the status quo, but perhaps that's not as clear
as I thought it was...  I'll back out the changes (looks like part of the
checkin failed anyway).
							
So here's a concrete proposal to fix the spec rather than the testcase:

In Section 5 change:
*  {http location} on Binding Operation components, as defined in 
6.4 Binding Operations
to:
*  {http location} and {http location ignore uncited} on Binding Operation
components, as defined in _6.4 Binding Operations_ and _6.7.2.2.2 
Controlling the serialization of the query string in the request IRI_,
respectively.

In Section 5.10.4.1.1 change (pre-CR133 text):
The SOAP "http://www.w3.org/2003/05/soap/mep/ImmediateDestination"
property takes the value of the WSDL {address} property of the Endpoint
component.

to:
The SOAP "http://www.w3.org/2003/05/soap/mep/ImmediateDestination"
property takes the value of the WSDL {address} property, modified by 
the {http location} property following the rules described in section
_6.7.1 Serialization of the instance data in parts of the HTTP request_.

Transition history

raised on 16 Jan 2007 by Jonathan Marsh (jonathan@wso2.com)

agreed on 1 Feb 2007

Proposal accepted.

Acknowledgment cycle

announced by group on 15 Feb 2007

Action history

CR145: Clarify 'scope' of {element declarations} and {type definitions} re SparqlQuerySimplified-1G [link to this issue]

I would like clarification the WSDL 2.0 testcase SparqlQuerySimplified-1G
and which schema element declarations should be present in the {element
declarations} property of the Description component. I think I had a
conversation about this issue with Jonathan and Arthur driving out to Niagra
Falls at the July interop.

The baseline component model interchange format for this testcase includes
an element declaration whose namespace is not inlined or imported within the
WSDL document's <types> element.

Baseline sparql-protocol-query.canonical.wsdlcm contains this item:

<elementDeclarationComponent xml:id="c22">
  <name>
    <base:namespaceName>
http://www.w3.org/1999/02/22-rdf-syntax-ns#</base:namespaceName>
    <base:localName>RDF</base:localName>
  </name>
  <system>http://www.w3.org/2001/XMLSchema</system>
</elementDeclarationComponent>

This element declaration is defined in a schema which is imported by the
<xs:schema> element inlined within the <types> element of
sparql-protocol-query.wsdl. However, the namespace
http://www.w3.org/1999/02/22-rdf-syntax-ns# is not xs:imported directly
within the <types> element.

According to Part 1, section 3.1 Using W3C XML Schema Description Language:
Schema-0016 "A WSDL 2.0 document MUST NOT refer to XML Schema components in
a given namespace unless an xs:import or xs:schema element information item
for that namespace is present ..."

In implementing Woden, I interpreted this to mean that {element
declarations} and {type definitions} only contain schema components whose
namespace is inlined or imported directly within the <types> element. The
Woden sparql-protocol-query.canonical.wsdlcm file refects this, in that the
element declaration mentioned above is not present (and Woden is failing the
testcase accordingly).

However, it may be that the intention of the WSDL 2.0 authors is that ALL
global element declarations and type definitions referenceable by XML Schema
MUST be included in {element declarations} and {type definitions},
regardless of whether they are inlined or imported directly within <types>
or whether they are 'nested' imports within those directly inlined or
imported schemas, and that assertions like Schema-0016 only apply when WSDL
2.0 components like InterfaceFault and InterfaceMessageReference resolve
their 'element' QNames to ElementDeclarations (but not to the contents of
{element declarations} and {type definitions} themselves).

Can someone from the working group please explain which interpretation is
correct?

Transition history

raised on 9 Jan 2007 by John Kaputin (gmail) (jakaputin@gmail.com)

agreed on 1 Feb 2007

proposal plus amendment plus some editorial license, accepted.

Acknowledgment cycle

announced by group on 22 Feb 2007

Action history

CR146: Ignoring uncited and nillable [link to this issue]

{http location ignore uncited} is primarily designed to force query
parameters to be inserted into the body of an x-www-form-urlencoded message
instead of appended to the URI.  When there is no body (GET), this simply
drops those parameters on the floor.

When reconstituting an XML message on the receiving end (as Axis2 does), it
is important not to drop parameters that affect the service's ability to
reconstitute a schema-valid message.  Having parameters that will be dropped
marked as nillable allows such a reconstruction.

Codifying this as a new assertion in section 6.7.2.2.2 would aid
interoperability:

  When serializing an HTTP request method that does not allow an HTTP 
  message body, and when {http location ignore uncited} is true, any 
  element not cited in the {http location} property MUST be defined in 
  the schema as nillable.

Transition history

raised on 23 Jan 2007 by Jonathan Marsh (jonathan@wso2.com)

agreed on 8 Feb 2007

"When serializing an HTTP request method that does not allow an HTTP message body, and when {http location ignore uncited} is true, any element not cited in the {http location} property MUST be defined in the schema as nillable, or have a default value, or appear no less frequently than specified by the minOccurs value. The element declaration SHOULD NOT combine a default value with nillable." + editorial license as necessary.

Acknowledgment cycle

announced by group on 15 Feb 2007

Action history

CR147: RFC: operation safety as semantic annotation? [link to this issue]

As you may know, the specification for Semantic Annotations for WSDL and
XML Schema [1] (SAWSDL) moving to CR. In our institute (my W3C hats are
off), we work on Semantic Web Services, and we plan to use SAWSDL as the
glue between our semantic description language and WSDL.

For my work, I will need to know the semantic description, i.e. what the
various service operations and data mean and do. One piece that I need
is operation safety. Currently, that is realized in WSDL as an extension
attribute, wsdlx:safe="boolean", with the default being false.

Operation safety is, at least to me, a clear semantic annotation. It
says nothing about the structure of the interface, instead it indicates
what the operation does (or rather, what it doesn't do - any side
effects or additional obligations in Web Architecture speak).

I would propose that we change the syntax from wsdlx:safe="true"  to 
sawsdl:modelReference="http://www.w3.org/2006/01/wsdl-extensions#SafeInteraction"
I know it's much longer, but please bear with me. 8-)

The WSDL Interface Operation {safety} property can stay as it is, only
its XML representation would change to "the IRI for SafeInteraction (as
above) will be included among the IRIs that are the value of
sawsdl:modelReference". The URI above is currently used in the RDF
mapping of WSDL to represent the safety property.

At worst, the people hand-writing and reading WSDL would have their
lives just a bit harder. At best, this would blend right in with the
plethora of other semantic annotations. Certainly, from my own point of
view, having safety as a semantic annotation as opposed to an extension
attribute would make my life just a bit easier.

[1] http://w3.org/tr/sawsdl

Transition history

raised on 29 Jan 2007 by Jacek Kopecky (jacek.kopecky@deri.org)

declined on 1 Mar 2007

No change.

Acknowledgment cycle

announced by group on 2 Mar 2007

CR148: Re: LocationTemplate-1G totally hosed ;-) [link to this issue]

Jonathan Marsh wrote:
> I found this in the SOAP spec:
>
> If the http://www.w3.org/2003/05/soap/features/action/Action property has a
> value at a SOAP sender utilizing a binding supporting this feature, the
> sender MUST use the property value as the value of the action parameter in
> the media type designator. [1]
>
> So to answer my own question, I think there's a pretty strong implication
> that the Content-Type header should be set to application/soap+xml, and
> include the action parameter, when the soap-response mep is used and the
> action is specified, for instance in MessageTest-4G:
>   
I agree with the implication and think it makes a lot of sense, although 
I am unclear about the MAY/SHOULD/MUST state of the implication.

>   <operation ref="tns:EchoString2"
>     wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response/"
>     wsoap:action="http://example.org/message-test/action/EchoString2">
>
> FWIW, (and after I'd concluded the above) I found that Axis2 currently
> inserts the media type with action as above, although as of now it doesn't
> correctly dispatch using the action in this case.
>   
Canon and Axis2 implementations seem to have the same behaviour on this 
one :)
Should we add an assertion in the exchange test-suite checking that if 
content-type is set in the GET request,
it must be application/soap+xml and action value equal to the specified 
value ?
> [1] http://www.w3.org/TR/soap12-part2/#actionstatemachine

Transition history

raised on 22 Jan 2007 by Youenn Fablet (youenn.fablet@crf.canon.fr)

agreed on 15 Feb 2007

Add a note to 5.10.3 telling that setting action has no effect when soap response is in use.

Acknowledgment cycle

announced by group on 16 Feb 2007

Action history

CR149: Re: rpc:signature question. [link to this issue]

Jonathan,

The word "input" in "child of the input element" should have been 
written in regular type, as opposed to fixed-width.

The expression means more than what you describe (“element declaration 
in the complexType declared by the {element declaration} of the Message 
Reference component with {direction} ‘in’”) because there are many ways 
to declare child elements in schema, e.g. with model groups.

It is true though that "the input element" means the "{element 
declaration} of the Message Reference component with {direction} ‘in’". 
It's stating the other half which is hard. It'd be much easier if XML 
Schema had a core language like Relax NG (<insert favorite rant on this 
topic here/>), because then we could compile away model groups and other 
oddities.

There may be an indirect way of saying this. What the assertion in 
question is really saying is that, for each valid instance of the 
“element declaration in the complexType declared by the {element 
declaration} of the Message Reference component with {direction} ‘in’”, 
it MUST be the case that the corresponding EII has among its [children] 
one EII whose qualified name matches the given one. A similar 
constraint, but negative, should be placed on the output element. 
Indirectly, such a universally quantified constraint on all valid EIIs 
would reflect back into a constraint at the schema level for which, 
alas, there appears to be no concise expression.

Thanks,
Roberto

Jonathan Marsh wrote:
> Assertion WRPC-0053 [1] states:
> 
>  
> 
> For each pair //(q, #in)//, there MUST be a child element of the |input| 
> element with a name of //q//. There MUST NOT be a child element of the 
> |output| element with the name of //q//.
> 
>  
> 
> What is “child of the input element” supposed to mean?  The <wsdl:input> 
> element doesn’t have significant children (extensions and 
> documentation).  So it could instead mean an “element declaration in the 
> complexType declared by the {element declaration} of the Message 
> Reference component with {direction} ‘in’”.  Is that the intention?
> 
> The assertions immediately following this one also suffer generally from 
> this malaise.
> 
>  
> 
> [1] 
> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.html?content-type=text/html;%20charset=utf-8#WRPC-5023
> 
>  
> 
> **Jonathan Marsh** - http://www.wso2.com - 
> http://auburnmarshes.spaces.live.com

Transition history

raised on 24 Jan 2007 by Roberto Chinnici (Roberto.Chinnici@Sun.COM)

agreed on 15 Feb 2007

Remove fixed-width formatting from "input".

Acknowledgment cycle

announced by group on 20 Feb 2007

Action history

CR150: Assertion Summary Texts in Part 1 [link to this issue]

One suggestion.Part 1 - Appendix E [Assertion Summary] is a great view of
all assertions about component models and documents.
I would appreciate if the Summary text be a complete English sentence that
contains the complete text about the assertion.

For instance, see the following assertion.

-----------------------------------------------
Assertion Id                 Summary
-----------------------------------------------
Description-1201005     Zero or more element information items amongst its
[children], in order as follows:

If the User were reading this in soft copy, he/she could click on the
Assertion Id hyperlink to navigate to the section that states the assertion.
But if the User were reading the specification on a hard print, it would not
be possible for he/she to get a clear understanding on what it means.  Note
that there are other assertions in this section which depict similar
behaviour.

Transition history

raised on 5 Feb 2007 by Ramkumar Menon (ramkumar.menon@gmail.com)

agreed on 15 Feb 2007

Close with no action.

Acknowledgment cycle

announced by group on 15 Feb 2007

CR151: XML Syntax Summary in Part 1 [link to this issue]

Section 9 of Part 1 shows the XML syntax summary for a WSDL document.

I am attaching a snippet of the XML.

<description targetNamespace="*xs:anyURI*" >
<documentation />?

<import namespace="*xs:anyURI*" location="*xs:anyURI*"? >
<documentation />*
</import>*

<include location="*xs:anyURI*" >
<documentation />*
</include>*

. . . . .
<binding name="*xs:NCName*" interface="*xs:QName*"? type="*xs:anyURI*" >
<documentation />*
. . . . .

You can note that "description" can possess only zero or one "documentation"
element [as indicated by "?"], whereas other components can have zero or
more documentation elements within them. [as indicated by "*"]
Is this correct ?

Secondly, am I right if I state that multiple documentation tags have been
provisioned only to provide for documentation in different languages using
the "xml:lang" property? Are there any other use-cases for this ?

Transition history

raised on 7 Feb 2007 by Ramkumar Menon (ramkumar.menon@gmail.com)

agreed on 8 Feb 2007

Fixed by editor.

Acknowledgment cycle

announced by group on 8 Feb 2007

CR152: Assertion on Bindings for Interface that only define faults [link to this issue]

I assume that it does not make sense, and is an error to define a Binding
component for an Interface Component that defines only Faults. Does this
call for a new assertion ?

Transition history

raised on 7 Feb 2007 by Ramkumar Menon (ramkumar.menon@gmail.com)

agreed on 15 Feb 2007

Close with no action.

Acknowledgment cycle

announced by group on 15 Feb 2007

CR153: The WSDL 2.0 namespace - will it change? [link to this issue]

Hi, I have a recollection that since the spec is CR, the namespace
http://www.w3.org/2006/01/wsdl won't change through PR and REC. Is
this right, or will the namespace change again - if so will it change
at PR, REC or both?

Transition history

raised on 6 Feb 2007 by Jeremy Hughes (hughesj@apache.org)

agreed on 22 Feb 2007

Namespaces and identifiers will be based off of http://www.w3.org/ns/wsdl.

Acknowledgment cycle

announced by group on 2 Mar 2007

CR154: InterfaceMessageReference-1205002 [link to this issue]

Wouldn't Assertion InterfaceMessageReference-1205002 be verified through the
schema itself?

Transition history

raised on 15 Feb 2007 by Ramkumar Menon (ramkumar.menon@gmail.com)

agreed on 22 Feb 2007

Remove assertion markup from this text.

Acknowledgment cycle

announced by group on 22 Feb 2007

agreement by reviewer on 22 Feb 2007

Action history

CR155: Proposal for Assertion InterfaceMessageReference-0042 [link to this issue]

The mentioned assertion states "For each Interface Message Reference
component in the {interface message references} property of an Interface
Operation component, its {message label} property MUST be unique.".

Correct me if I am wrong, but can we have the XSD capture this constraint
explicitly ?

For instance,

<xs:element name="operation" type="wsdl:BindingOperationType">
  <xs:unique name="messageLabel">
    <xs:selector
xpath="(wsdl:input|wsdl:output:wsdl:infault|wsdl:outfault)">
     <xs:field xpath="@messageLabel">
    </xs:selectpr>
  </xs:unique>
</xs:element>

Transition history

raised on 15 Feb 2007 by Ramkumar Menon (ramkumar.menon@gmail.com)

moved on 1 Mar 2007

Move to potential errata list.

Acknowledgment cycle

announced by group on 7 Mar 2007

CR156: Query parameter separator value [link to this issue]

Reading the specification, it seems that the only constraint on the 
separator value is to be a xml string of length 1.
It would therefore be possible to have a separator value that needs to 
be %-encoded in the URL (e.g. queryParameterSeparator="é").
I do not know whether that was intended but in this case, the query 
string may become ambiguous: if the separator value appears in a 
parameter value, it will be %-encoded exactly like the separator value. 
It might be safer to restrict the separator value range.

In any case, the most sensible values are '&' and ';'. Is there any 
other obvious possibility?
While '&' is the default value, ';' does not appear AFAIKT neither in 
the spec nor in the primer.
It might therefore be good to add a statement that tells a word about 
these values, maybe as a SHOULD.

Transition history

raised on 21 Feb 2007 by Youenn Fablet (youenn.fablet@crf.canon.fr)

agreed on 1 Mar 2007

Restrict query parameter separator to the characters: "&" / ";" / ALPHA / DIGIT / "-" / "." / "_" / "~" / "!" / "$" / "'" / "(" / ")" / ":" / "@" / "/" / "?" / "*" / "+" / ",". Add a schema pattern [&;a-zA-Z0-9\-\._~!$'\(\):@/\?\*\+,]{1,1}. Add a note that & and ; are the common cases.

Acknowledgment cycle

announced by group on 16 Mar 2007

Action history

CR157: RE: LocationTemplate-1G test [link to this issue]

- [QUESTION 1] The spec says what characters MUST be encoded, but there are
also characters that MAY be encoded such as * (and pretty much any other
character except %).  Our test suite assumes only the characters that MUST
be are.  Should we change this?  (I think we should do this
opportunistically, that is, if a testcase is proven to be correct, we simply
add an alternative that matches that implementation's encoding strategy.  I
don't think we have any failures because of this at present.)

- [QUESTION 2] Is this sufficiently clear in the spec?  (I think so.)

- [QUESTION 3] Are there additional editorial improvements possible?  (I
think so, as reported in
http://lists.w3.org/Archives/Public/www-ws-desc/2007Feb/0193.html).
		
- [QUESTION 4] Is "&" a harmful character before the "?".  If not, we should
add it to the excluded list.

- [QUESTION 5] Are ";" and "=" harmful characters before the "?".  If so, we
should remove them from the excluded list.

Transition history

raised on 22 Feb 2007 by Jonathan Marsh (jonathan@wso2.com)

agreed on 1 Mar 2007

Split the MUST encode after "~" (both cases) and make the remainder a SHOULD.

Jonathan's editorial improvements to 6.8.1.1 adopted.

Add "&" to the list of characters that SHOULD be encoded.

Acknowledgment cycle

announced by group on 13 Mar 2007

agreement by reviewer on 13 Mar 2007

Action history