List and dispositions of issues recorded against:
Issues list for other deliverables of the WG can be found on the WS Description WG Issues List.
This document is a live document and can change at any time, in particular to update the status of issues may change over time.
Color key: error warning note
| Id: Title | State | Type | Ack. |
|---|---|---|---|
| LC2 : Editorial: Issue 177 Implementation | no decision (raised) | clarification | |
| LC5 : QA Review on WSDL 2.0 Part 1, intro and conformance issues | no decision (raised) | clarification | |
| LC8 : Permit URI References instead of URIs | no decision (raised) | clarification | |
| LC3 : {namespace name} property | no decision (raised) | editorial | |
| LC4 : Table of components/properties | no decision (raised) | editorial | |
| LC7 : QA Review on WSDL 2.0 Part 1, Editorial comments | no decision (raised) | editorial | |
| LC1 : Property Requiredness | agreed | error | No reply from reviewer |
| LC6 : QA Review on WSDL 2.0 Part 1, Technical comments | no decision (raised) | error |
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#simpletypesConformance issues (these comments have been mostly inspired from specGL
[4]):
a) 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.
b) 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.
c) it would be interesting to list (maybe in an appendix) what
constraints are not translated in the provided XML Schema
c) 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, � la "WSDL 2.0 requesting processor" - you'll probably find
something better.
e) "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
f) 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
g) "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 ...."
h) "that it does not choose to implement." -> "it chooses not to
implement", or maybe "it doesn't implement"
i) 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
j) 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
k) 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
l) 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.
4. http://www.w3.org/TR/qaframe-spec/
In sections 2.7 and 2.8, we use URIs to identify Features and
Properties. For example, section 2.7.1 says:
[[
{name} REQUIRED. A wsdls:anyURI as defined in 2.15.4 anyURI Type.
]]
and anyURI is defined as:
[[
2.15.4 anyURI Type
The value space of the wsdls:anyURI type consists of all Uniform
Resource Identifiers (URI) as defined by [IETF RFC 2396] and amended by
[IETF RFC 2732].
]]
I think we should allow these to be URI References instead restricting
them to be only URIs. (I.e., allow them to contain fragment
identifiers.) That would permit multiple, related Features or
Properties to be described in the same document, using different
fragment identifiers to distinguish them, such as:
http://example.org/my_related_features_and_properties#a
http://example.org/my_related_features_and_properties#b
http://example.org/my_related_features_and_properties#c
This would also allow conformance to the practice that some recommend
for the Semantic Web, of using fragment identifiers when identifying
things that are not documents, such as abstract concepts."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}.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.)
Editorial issues:
a) section 1.3 (WSDL terminology) has only one item; I would find
surprising that this specification only defines one new concept; e.g. a
'Web Service Component' would probably deserve to be defined here;
also, linking to the WS Glossary may be a good idea
b) section 2's title is "Component Model" and uses these phrases a few
times, but doesn't define it
c) section 2 has most of the meaty stuff (the component model), but it is
somewhat diluted by the XML serialization formalism; I wonder if moving
the XML serialization in a different section (or in an appendix) would
enhance the readability of the spec;
d) I suggest marking up and styling appropriately (or maybe
capitalizing?) words that are used in a very specific way in the
specification; e.g. in 2.1.1 "At the abstract level, the Definitions
component is just a container for two categories of components; WSDL
components and type system components." would better read IMHO as "At
the abstract level, the Definitions Component is just a container for
two categories of component: WSDL Components and Type System Components"
(I used capitalization in this case, but italicizing may work better).
e) the document introduction still calls Part 2 "Message Exchange
Patterns", although it's now called Predefined extensions
f) the document refers to the language as "WSDL"; since WSDL has been
available in several versions, I suggest using "WSDL 2.0" instead - if
not everywhere, at least in the introduction
g) in 2.1.1 "Note that it is RECOMMENDED that the value of the
targetNamespace attribute information item SHOULD be a dereferencible
URI and that it resolve to a WSDL document which provides service
description information for that namespace"; the "SHOULD" is not needed
since the sentence is preceded by "RECOMMENDED"
h) I suggest linking the XPointer scheme definition for WSDL (appendix C)
from section 2.1.1., where dereferenceability of components is mentioned
i) there are only 2 examples of complete WSDL definitions in the whole
spec (one in an appendix); adding a few simple examples in the course of
the spec may help the reader a bit more; more generally, having a bit
more illustrations of what WSDL is about would help [I see that a primer
is in preparation; still, I don't think a few included examples would
hurt]
Also, the first example (in 2.7.1.1.1) should declare that <definitions>
(and its children) are in the WSDL namespace
The second example (in C.4) uses a relative URI as its
xsi:schemaLocation; any reason to use "wsdl20.xsd" instead of
"http://www.w3.org/2004/08/wsdl/wsdl20.xsd"?
j) section 2.2.2.3 introduces the notion of style, which is only
explained later in 2.4.1.1; would be good to make a link from the former
to the latter
k) section 2.4.2 reads "If the Interface Operation component uses a
{message exchange pattern} for which there is no output element, such as
'http://www.w3.org/2004/08/wsdl/in-only'"; but according to the
paragraph above "The RPC style MUST NOT be used for Interface Operation
components whose {message exchange pattern} property has a value other
than 'http://www.w3.org/2004/08/wsdl/in-only' or
'http://www.w3.org/2004/08/wsdl/in-out'.", this should not be "such as",
but "i.e."; or did I miss something?
l) 2.4.2.1 starts with "The wrpc:signature extension AII MAY be be used":
what is AII? "be" is repeated twice
thereafter, it uses the notion of a function signature, without much
introduction; since "RPC" is never translated into "Remote Procedure
Call", it looks a bit awkward
m) in section 2.5.1 "by the global element declaration reference by the
{element} property.", "reference" should read "referenced"
n) section 2.8.2 reads "An OPTIONAL required attribute" which contradicts
the model described in 2.8.1 where {required} is REQUIRED
o) 2.17, "the combination of these two properties need not be unique" ,
"need" should read "needs"
p) in section 3, "W3C XML Schema Description Language" isn't a proper way
to refer to XML Schema; use "W3C XML Schema" or 'W3C XML Schema
language'
q) section 4.2 uses "DOES NOT" (upper case), as if it was an RFC Keyword;
IT'S NOT
r) the document references XML 1.0 Second Edition, while the third has
been published earlier this year
s) it also references outdated versions of XML Infoset and WebArch (see
[1])
t) the table of contents should use real markup, rather than &nsbp;; I've
provided a patch to xmlspec for this purpose [2]
u) a few typos: "compomnent", "dereferencible" (should be dereferenceable
AFAIK), "implicitely" (implicitly), "requestor" (requester) based on the
spell checker [3]
1. TR references checker:
http://www.w3.org/2000/06/webdata/xslt?xslfile=http%3A%2F%2Fwww.w3.org%2F2004%2F07%2Freferences-checker&xmlfile=http%3A%2F%2Fcgi.w3.org%2Fcgi-bin%2Ftidy-if%3FdocAddr%3Dhttp%253A%252F%252Fwww.w3.org%252FTR%252F2004%252FWD-wsdl20-20040803%252F&
2. http://lists.w3.org/Archives/Public/spec-prod/2004AprJun/0000.html
3.
http://www.w3.org/2002/01/spellchecker?uri=http://www.w3.org/TR/2004/WD-wsdl20-20040803/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.
a) 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}?
b) 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)
c) purely cosmetic: why 'wsdlLocation' as attribute name, rather than
simply 'Location', since the attribute is namespace qualified (in wsdli:
) ?
d) 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
Last update: $Date: 2004/09/01 18:50:30 $
This page was generated as part of the Extensible Issue Tracking System (ExIT)
Copyright © 2003, 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.