WSDL 2.0 Last Call Issues List

LC1: Property Requiredness [link to this issue]

I continue to believe that the "required" flag on properties
is NOT necessary.	Property values/constraints simply make the specified
values available to the runtime.	If you think about why you would ever
want to require setting a particular property, you can achieve the same
result by simply requiring a component (feature/module/binding) which
uses that property.

Any binding or SOAP module which utilizes particular properties will be
able to pull the values/constraints for those properties out of the
component model.	Certain specs may have defined default values for
properties, so if values for those properties are not expressed in the
WSDL, they would take on the defaults.	If a property is needed by a
given feature/binding/module and NOT specified in the WSDL, then this
would be an error, but I don't think that a "required" flag on the
property value/constraint helps this situation at all.	Understanding a
particular feature/binding/module implies understanding the property set
which is required.

I propose we pull this out of the spec, which would simplify both the
prose and the model.

Transition history

raised on 26 Jul 2004 by Glen Daniels (gdaniels@sonicsoftware.com)

agreed on 4 Aug 2004

RESOLUTION: to remove the required flag on property element and make appropriate changes to the component model.

Acknowledgment cycle

announced by group on 1 Sep 2004

Action history

LC2: Editorial: Issue 177 Implementation [link to this issue]

ref: issue 177 [1]

On July 8th, we adopted [2] Jonathan's proposal [3]. I have one editorial
issue with 177 implementation.

The types of the following properties in Part 3, SOAP Binding, are defined
using prose instead of wsdls:* types. I request the following property-type
associations,

{soap underlying protocol} => wsdls:anyURI
SOAP Module.{uri}          => wsdls:anyURI
SOAP Module.{required}     => wsdls:boolean
{soap fault code}          => wsdls:QName
{soap fault subcodes}      => list of wsdls:QName
{soap mep}                 => wsdls:anyURI
{soap action}              => wsdls:anyURI

Rationale

(a) Consistent with Part 1 and HTTP Binding
(b) Otherwise, we will be using two similar types (xs:QName vs. wsdls:QName)
in the component model
(c) Equivalence in Part 1 is defined using wsdl simple types
(d) Part 3 is refuting Part 1 claim, "The component model uses a small set
of predefined simple types, such as boolean, string, token. In order to
avoid introducing a dependency on any particular serialization of the
component model, this specification provides its own definition of those
types" [5]

[1]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/issues/wsd-issues.html#x177
[2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0109.html
[3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0258.html
[4]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-
type=text/html;%20charset=utf-8#string_type
[5]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-
type=text/html;%20charset=utf-8#simpletypes

Transition history

raised on 2 Aug 2004 by Asir Vedamuthu (asirv@webmethods.com)

agreed on 2 Sep 2004

RESOLUTION: proposal accepted.

Acknowledgment cycle

announced by group on 2 Sep 2004

agreement by reviewer on 28 Sep 2004

Action history

LC3: {namespace name} property [link to this issue]

"2.18 QName resolution

In its serialized form WSDL makes significant use of references between 
components. Such references are made using the Qualified Name, or 
QName, of the component being referred to. QNames are a tuple, 
consisting of two parts; a namespace name and a local name. For 
example, in the case of an Interface component, the namespace name is 
represented by the {namespace name} property and the local name is 
represented by the {name} property."

I can't find any {namespace name} *property* (component). Perhaps it is 
the {targetNamespace}?

I see lots of references to [namespace name] Infoset properties.

Ah, I see in 2.17:

"Within a symbol space, all qualified names (that is, the combination 
of {name} and {target namespace} properties) are unique. Between symbol 
spaces, the combination of these two properties need not be unique. 
Thus it is perfectly coherent to have, for example, a binding and an 
interface that have the same name."

This suggests that it is {targetNamespace}.

Transition history

raised on 3 Aug 2004 by Bijan Parsia (bparsia@isr.umd.edu)

agreed on 2 Sep 2004

RESOLUTION: proposal accepted.

Acknowledgment cycle

announced by group on 2 Sep 2004

Action history

LC4: Table of components/properties [link to this issue]

I would find a table/index of components and 
component properties very handy (perhaps in the Primer).

(E.g., something like:	
	http://www.w3.org/TR/owl-ref/#appA)

Whoa, they liked it so much that the did it twice:	
	http://www.w3.org/TR/2004/REC-owl-guide-20040210/#TermIndex

If people thought it was worth having, I'd volunteer to compile such an 
index.)

Transition history

raised on 3 Aug 2004 by Bijan Parsia (bparsia@isr.umd.edu)

agreed on 2 Sep 2004

RESOLUTION: Will generate such a table automatically using a stylesheet. Subject to sufficient resources (Bijan) forthcoming.

Acknowledgment cycle

announced by group on 2 Sep 2004

Action history

LC5a: QA Review on WSDL 2.0 Part 1, intro and conformance issues (a) [link to this issue]

Document conformance
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#markup
 "Note that the WSDL language is defined in terms of the component model
defined by this specification. As such, it is explicitly NOT a
conformance requirement to be able to process documents encoded in a
particular version of XML, in particular XML 1.1 [XML 1.1]." is both
very hard to read, and probably in contradiction with the header
"document conformance"; I guess this needs clarification
It is particularly unclear to me that defining conformance for an
"element information item" has any sense at all.

Transition history

raised on 6 Aug 2004 by Dominique Hazaël-Massieux (dom@w3.org)

agreed on 2 Sep 2004

RESOLUTION: Change the above paragraph to something like: "Since this spec is defined in terms of the infoset, it is not a requirement to support any particular serialization of the infoset. For instance, a conformant processor might only support XML 1.0."

Acknowledgment cycle

announced by group on 5 May 2005

proposal from reviewer on 12 May 2005

I would have put that section in the section conformance rather than introduction, though.

proposal declined by group on 6 Jul 2005

Sustained the current design.

Action history

LC5b: QA Review on WSDL 2.0 Part 1, intro and conformance issues (b) [link to this issue]

Also, section 1.2 ("Notational conventions") adds the definition of
"valid/not valid WSDL document", with important conformance
requirements. I suggest it should be moved to the conformance section,
and the normative schema should be referenced from there. Additionally,
while using the content-negotiated URI as a namespace URI is a good
idea, I suggest referring explicitly the schema URI (with the .xsd
extension) would be better when talking about the schema itself.

Transition history

raised on 6 Aug 2004 by Dominique Hazaël-Massieux (dom@w3.org)

agreed on 2 Sep 2004

RESOLUTION: Accept proposal to remove discussion of validity from table in section 1.2, add link to schema to "Document Conformance", and add .xsd extension to all links to schemas.

Acknowledgment cycle

announced by group on 2 Sep 2004

agreement by reviewer on 3 Sep 2004

agreement incorporated by group on 5 May 2005

Additional acknowledgement requested.

agreement accepted by group on 12 May 2005

Additional acknowledgement received.

Action history

LC5c: QA Review on WSDL 2.0 Part 1, intro and conformance issues (c) [link to this issue]

It would be interesting to list (maybe in an appendix) what
constraints are not translated in the provided XML Schema

Transition history

raised on 6 Aug 2004 by Dominique Hazaël-Massieux (dom@w3.org)

declined on 2 Sep 2004

RESOLUTION: We already plan to provide this info in a Test Assertion Document. An appendix is therefore redundant and not cost effective.

Acknowledgment cycle

announced by group on 2 Sep 2004

agreement by reviewer on 3 Sep 2004

agreement incorporated by group on 5 May 2005

Additional acknowledgement requested.

agreement accepted by group on 12 May 2005

Additional acknowledgement received.

LC5d: QA Review on WSDL 2.0 Part 1, intro and conformance issues (d) [link to this issue]

Processor conformance
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#processor
"""This section defines a class of conformant WSDL processors that are
intended to act on behalf of a party that wishes to make use of a Web
service"""
I suggest that you give a specific label to this class of WSLD
processors, a la "WSDL 2.0 requesting processor" - you'll probably find
something better.

Transition history

raised on 6 Aug 2004 by Dominique Hazaël-Massieux (dom@w3.org)

agreed on 14 Sep 2004

Change the first paragraph of section 8.3 to:

This section defines conformance of a WSDL processor. In this section, the term "WSDL processor" refers to a processor that is acting on behalf of a party that wishes to make use of a Web service (i.e., the requester entity or requester agent, rather than the party that implements the Web service (i.e., the provider entity or provider agent).

Acknowledgment cycle

announced by group on 21 Sep 2004

agreement by reviewer on 22 Sep 2004

agreement incorporated by group on 5 May 2005

Additional acknowledgement requested.

agreement accepted by group on 12 May 2005

Additional acknowledgement received.

Action history

LC5e: QA Review on WSDL 2.0 Part 1, intro and conformance issues (e) [link to this issue]

"a conformant WSDL processor MUST accept any legal WSDL document":
what is a legal WSDL document? I suggest saying "conformant WSDL
document" - but I'm still unclear whether you define that at all in the
section above

Transition history

raised on 6 Aug 2004 by Dominique Hazaël-Massieux (dom@w3.org)

agreed on 9 Sep 2004

Add a definition of WSDL Document as a wsdl:definitions element and its descendents and we may want to put it in the notational conventions section (1.3) and then simplify 8.1 accordingly and we want to change "legal" to "conforming" wsdl document.

Acknowledgment cycle

announced by group on 21 Sep 2004

agreement by reviewer on 22 Sep 2004

agreement incorporated by group on 5 May 2005

Additional acknowledgement requested.

agreement accepted by group on 12 May 2005

Additional acknowledgement received.

Action history

LC5f: QA Review on WSDL 2.0 Part 1, intro and conformance issues (f) [link to this issue]

You use both the expressions "a processor MUST fault" and "a processor
MUST fail"; do they mean the same thing? In any case, I think you should
clarify what is meant by those (i.e. what consist failing/faulting in?),
and if they mean the same thing, only use one of the expressions; also,
since the name 'fault' is used in a very well defined context in the
spec, I think you should avoid using the verb 'fault' unless it relates
to the said context; more generally, I think developing the notion of
error handling for a WSDL processor would be benefitial

Transition history

raised on 6 Aug 2004 by Dominique Hazaël-Massieux (dom@w3.org)

agreed on 3 Mar 2005

Accepted proposal, including option A, at http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/0099.html, replacing point 7 with "Thus, the meaning of the element cannot be determined without understanding the attached extension" plus other editorial license as necessary. Issue LC5f Closed.

Acknowledgment cycle

announced by group on 5 May 2005

proposal from reviewer on 12 May 2005

I think dropping the notion and conformance rules for a processor is probably a loss for the specification, but maybe the group doesn't have enough implementation experience to define one or several classes of products for WSDL processors? I guess the point I'm trying to make is, when a customer wants to buy an interoperable solution using WSDL, she'll need to know how to name this or this type of software, and this naming ought to be done in the specification IMO.

FWIW, the introduction still says "It also defines criteria for a conformant processor of this language" and there are still a few places where conformance requirements are set for processors (e.g. "All WSDL 2.0 processors MUST support XML Schema type definitions").

proposal declined by group on 6 Jul 2005

Sustained the current design.

Action history

LC5g: QA Review on WSDL 2.0 Part 1, intro and conformance issues (g) [link to this issue]

"a conformant WSDL processor MUST either agree to fully abide": I
think this an abusive usage of MUST, since "agreeing" is not an
operation that a WSDL process does; I would suggest "a conformance WSDL
processor MUST immediately cease processing (fault) if it doesn't agree
to fully abide ...."

Transition history

raised on 6 Aug 2004 by Dominique Hazaël-Massieux (dom@w3.org)

agreed on 14 Sep 2004

Accept the reviewer's proposal: "a conformant WSDL processor MUST immediately cease processing (fault) if it doesn't agree to fully abide ...."

Acknowledgment cycle

announced by group on 21 Sep 2004

agreement by reviewer on 22 Sep 2004

agreement incorporated by group on 5 May 2005

Additional acknowledgement requested.

agreement accepted by group on 12 May 2005

Additional acknowledgement received.

Action history

LC5h: QA Review on WSDL 2.0 Part 1, intro and conformance issues (h) [link to this issue]

"that it does not choose to implement." -> "it chooses not to
implement", or maybe "it doesn't implement"

Transition history

raised on 6 Aug 2004 by Dominique Hazaël-Massieux (dom@w3.org)

agreed on 14 Apr 2004

Accept editor's resolution of the issue.

Acknowledgment cycle

announced by group on 5 May 2005

agreement by reviewer on 12 May 2005

Action history

LC5i: QA Review on WSDL 2.0 Part 1, intro and conformance issues (i) [link to this issue]

The "Note:" under this defines conformance requirements for a provider
agent, which is out of scope for the given section; I suggest creating a
different section, even if that's the only requirement for it

Transition history

raised on 6 Aug 2004 by Dominique Hazaël-Massieux (dom@w3.org)

agreed on 14 Sep 2004

Delete the note from the conformance section (as redundant), and promote the material on optional extensions into its own section, and add "See section ___ for further explanantion".

Acknowledgment cycle

announced by group on 21 Sep 2004

objection from reviewer on 22 Sep 2004

OK; I guess I'll wait and see what the actual implementation in the spec looks like; could you ping me when you have something I can look at? I think this shows there are still some conformance requirements needed for server processors, but this may be proved to be wrong when reading the actual text.

objection accepted by group on 5 May 2005

Changes resolving LC5f have made this point moot.

objection accepted by group on 12 May 2005

Additional acknowledgement received.

Action history

LC5j: QA Review on WSDL 2.0 Part 1, intro and conformance issues (j) [link to this issue]

The section 6.1 on mandatory extensions adds requirements both for
requesting and providing processors; most are duplicated in the
conformance section, but I think a few are not (e.g. "the provider agent
MUST support every extension, Feature or Property that is declared as
optional in the WSDL document"); I suggest they should be added to the
conformance section
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#mandatoryext

Transition history

raised on 6 Aug 2004 by Dominique Hazaël-Massieux (dom@w3.org)

agreed on 14 Sep 2004

Resolved by resolution to issue LC5i.

Acknowledgment cycle

announced by group on 21 Sep 2004

objection from reviewer on 22 Sep 2004

OK; I guess I'll wait and see what the actual implementation in the spec looks like; could you ping me when you have something I can look at? I think this shows there are still some conformance requirements needed for server processors, but this may be proved to be wrong when reading the actual text.

objection accepted by group on 5 May 2005

Changes resolving LC5f have made this point moot.

objection accepted by group on 12 May 2005

Additional acknowledgement received.

Action history

LC5k: QA Review on WSDL 2.0 Part 1, intro and conformance issues (k) [link to this issue]

Likewise, section 4.1 makes a suggestion for processors:
"Processors are encouraged to keep track of the source of component
definitions, so that multiple, mutual, and circular includes do not
require establishing identity on a component-by-component basis."
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#includes
Maybe this could be added as a SHOULD in the conformance section

Transition history

raised on 6 Aug 2004 by Dominique Hazaël-Massieux (dom@w3.org)

agreed on 14 Sep 2004

Delete the text, because it is only advice to implementers.

Acknowledgment cycle

announced by group on 21 Sep 2004

objection from reviewer on 22 Sep 2004

Please don't; I was simply suggesting this would make a useful SHOULD, but I'd rather see it in its current shape than not seeing it at all.

objection accepted by group on 5 May 2005

Changes resolving LC5f have made this point moot.

objection accepted by group on 12 May 2005

Additional acknowledgement received.

Action history

LC5l: QA Review on WSDL 2.0 Part 1, intro and conformance issues (l) [link to this issue]

Section 1.1 reads "All parts of this specification are normative, with
the EXCEPTION of notes, pseudo-schemas, examples, and sections
explicitly marked as "Non-Normative"."; some of the "Note:"s include
normative-like language, e.g. 
"Support for the W3C XML Schema Description Language [XML Schema:
Structures],[XML Schema: Datatypes] is required of all processors." 
or
"If a WSDL document declares an extension or feature as optional, then
if that extension or feature could apply to messages sent by the
provider agent as well, then the provider agent MUST NOT send any
messages that requires the requester agent to support that extension or
feature."
Please fix.

Transition history

raised on 6 Aug 2004 by Dominique Hazaël-Massieux (dom@w3.org)

agreed on 14 Sep 2004

Leave the Note, but change "processors" to "conformant processors" (and link to the conformance section), and explain this to the reviewer. Make the Note in 6.3 normative, and rephrase as "Extensibility elements SHOULD NOT alter the existing semantics in ways that are likely to confuse users."

Acknowledgment cycle

announced by group on 21 Sep 2004

agreement by reviewer on 22 Sep 2004

agreement incorporated by group on 5 May 2005

Additional acknowledgement requested.

agreement accepted by group on 12 May 2005

Additional acknowledgement received.

Action history

LC6a: QA Review on WSDL 2.0 Part 1, Technical comments (a) [link to this issue]

The {name} property of the feature and property component uses URIs,
while all the other {name} properties use QNames; I guess my preference
would be to have all the {name} properties be URIs, but at the very
least, I find it confusing to have this inconsistency in the model:
what's the reasoning behind it? maybe instead of using {name} for those,
you should use {identifier}?

Transition history

raised on 6 Aug 2004 by Dominique Hazaël-Massieux (dom@w3.org)

agreed on 14 Sep 2004

Change {name} in F&P to {uri}.

Acknowledgment cycle

announced by group on 21 Sep 2004

agreement by reviewer on 22 Sep 2004

Action history

LC6b: QA Review on WSDL 2.0 Part 1, Technical comments (b) [link to this issue]

Is there any reason why the {value constraint} in properties
components (2.8) is represented in XML as an element rather than an
attribute? given its content model (xs:QName), an attribute would look
more "natural" (and more in-line with the other representations in WSDL)

Transition history

raised on 6 Aug 2004 by Dominique Hazaël-Massieux (dom@w3.org)

declined on 14 Sep 2004

The current element syntax supports schema validation by allowing a co-constraint between 'value' and 'constraint', which would be lost if value were an attribute.

Acknowledgment cycle

announced by group on 21 Sep 2004

agreement by reviewer on 22 Sep 2004

LC6c: QA Review on WSDL 2.0 Part 1, Technical comments (c) [link to this issue]

Purely cosmetic: why 'wsdlLocation' as attribute name, rather than
simply 'Location', since the attribute is namespace qualified (in wsdli:
) ?

Transition history

raised on 6 Aug 2004 by Dominique Hazaël-Massieux (dom@w3.org)

declined on 14 Sep 2004

We follow XML Schema's convention, and it further clarifies that it is the location of a WSDL document.

Acknowledgment cycle

announced by group on 21 Sep 2004

agreement by reviewer on 22 Sep 2004

LC6d: QA Review on WSDL 2.0 Part 1, Technical comments (d) [link to this issue]

C.2 defines fragment identifiers compatible with the XPointer
Framework; I suspect this means you're defining a new scheme for
XPointer, in which case this should be said explicitly; also, it would
probably be wise to mention that at the time of this document, only the
application/wsdl+xml MIME-type references this scheme as a possible
xpointer scheme - i.e., I don't think a WSDL resource served as
application/xml can ben resolved using this XPointer scheme.

Transition history

raised on 6 Aug 2004 by Dominique Hazaël-Massieux (dom@w3.org)

agreed on 30 Sep 2004

Make explicit that we are defining a new XPointer scheme. In addition, rename the schemes to use a "wsdl." prefix to distinguish them visually from other fragment schemes and reduce the possibility of name clashes. Nothing precludes a client from processing one of our schemes on resources served up as application/xml if they so desire - that's the way XPointer works.

Acknowledgment cycle

announced by group on 30 Sep 2004

Action history