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