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

LC7: QA Review on WSDL 2.0 Part 1, Editorial comments [link to this issue]

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%2F
tidy-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/

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 29 Apr 2005

agreement by reviewer on 12 May 2005

Action history

LC8: Permit URI References instead of URIs [link to this issue]

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.

Transition history

raised on 27 Aug 2004 by David Booth (dbooth@w3.org)

agreed on 15 Sep 2004

Allow # (URI -> URI Reference) everywhere but targetNamespace.

Acknowledgment cycle

announced by group on 21 Sep 2004

agreement by reviewer on 21 Sep 2004

Action history

LC9: How does the Operation Name Mapping Requirement (Part 1, section 2.2.1.1) relate to interface inheritance? [link to this issue]

I'd like to see further clarification of the relationship between the
Operation Name Mapping Requirement (Part 1, section 2.2.1.1) and
interface inheritance (Part 1, section 2.2.1). Specifically, I have
three questions:
 
Can a derived interface meet the Operation Name Mapping Requirement
using a mechanism different from the mechanism(s) used by its base
interface(s)?
 
If not, is it a requirement that a derived interface only extend base
interfaces that use the same mechanism to meet the Operation Name
Mapping Requirement?
 
If so, is it then the case that a single derived interface can not
extend multiple base interfaces that use different mechanisms to meet
the Operation Name Mapping Requirement?

Transition history

raised on 6 Sep 2004 by Tim Ewald (tewald@microsoft.com)

agreed on 15 Sep 2004

The answer to the first question is yes, see section 6 which should make this clear. For the last question, we'll move paragraph preceeding section 2.2.1.1 and whole 2.2.1.1 to service section, make clear that this applies to the interface component of the service component, and indicate that any in-scope feature or extension (scoping of extensions left as an exercise to the author) may satisfy the ONR. The prose in list item 1 of "2.2.1.1 Operation Name Mapping Requirement" should NOT refer only to properties of the interface component, due to the F&P inheritance rules defined in e.g. "2.7.1.1 Feature Composition Model".

Acknowledgment cycle

announced by group on 15 Sep 2005

objection from reviewer on 16 Sep 2004

I'm not sure whether this really addresses my concern or not. I see two obvious ways to handle the ONM: a unique GED for every operation or the WS-Addressing Action header (wsa:Action). Obviously other approaches are possible.

In my perfect world, people would do both, but there's certainly not reason why they have to. What I worry about, though, is that some interfaces may use unique GEDs but the same action (maybe none or "") and others may use duplicate GEDs and different actions (this is mandatory if you use #any or #element for any operations). What happens if a service wants to implement interfaces of both sorts? Because a service can only specify one mechanism to meet the ONM requirement, will it even be possible out of the box? Or will someone have to make up a new mechanism that relies on some weird combination of GED and action header?

In short, I'm afraid that ONM may leave us in a world where there are different types of interfaces and a service can't derive from two different types. Worse, the difference between the types will be subtle indeed. As far as I can tell, specifying the ONM mapping on the service doesn't solve that problem. It just moves it away from the interfaces.

objection declined by group on 6 Jan 2005

Additional explanation.

objection incorporated by group on 28 Jun 2005

Subsumed by the removal of the Operation Name Mapping Requirement.

Action history

LC10: Two typos in Bindings [link to this issue]

Hi, two typos (maybe) in WD-wsdl20-bindings-20040803 :

In 3,2 you say "whttp:methodDefault", but later you use
"whttp:defaultMethod" (3.3 and 3.5.3).

In example 3.3 you forgot an empty line in both parts
of multipart/form-data after the header Content-Type:

Transition history

raised on 6 Sep 2004 by Frank Ellermann (nobody@xyzzy.claranet.de)

agreed on 23 Sep 2004

Fixed by editors.

Acknowledgment cycle

announced by group on 29 Sep 2004

Action history

LC11: Consistent naming of fooDefault/defaultFoo [link to this issue]

In preparation for discussing LC10 in today's call, I have noticed
that we are inconsistent in our naming of elements for default values.

Frank Ellerman points out at [1]:

> In 3,2 you say "whttp:methodDefault", but later you use
> "whttp:defaultMethod" (3.3 and 3.5.3).

Putting this one aside, we also have:
- wsoap:mepDefault
- whttp:defaultTransferCoding

I guess that the typo Frank is reporting reflects this lack of
consistency. It would be good if we were using the same convention in
all the bindings: wbinding:fooDefault or wbinding:defaultFoo. I have a
very slight preference for the former FWIW.

1. http://lists.w3.org/Archives/Public/public-ws-desc-comments/2004Sep/0006

Transition history

raised on 9 Sep 2004 by Hugo Haas (hugo@w3.org)

agreed on 9 Sep 2004

Rename defaultTransferCoding to transferCodingDefault and fix any typos to do with defaultFoo.

Acknowledgment cycle

announced by group on 9 Sep 2004

agreement by reviewer on 15 Sep 2004

Action history

LC12: "whttp:location" attribute is missing [link to this issue]

Ref: http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803/#soap-syntax ..in the XML Syntax Summary

Editorial concerning

Part 3

Transition history

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

agreed on 16 Sep 2004

Add whttp:location to section 2.1, the binding operation element (same place as whttp:defaultTransferCoding)

Acknowledgment cycle

announced by group on 21 Sep 2004

agreement by reviewer on 28 Sep 2004

Action history

LC13: HTTP Operation Component ? [link to this issue]

ref: http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803/#http-operation-decl-xml Actually, there isn't anything close to HTTP Operation Component in Part 3. I found 5 occurrences of the phrase "HTTP Operation Component". These are just remains from the old text. AFAIK, there is a binding operation component. And, HTTP binding adds a set of properties - {http location}, {http method}, {http input serialization}, {http output serialization}, {http fault serialization}- to this binding operation component.

Transition history

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

agreed on 16 Sep 2004

Editors to change use of HTTP Operation Component to something like Binding Operation Component augmented by HTTP properties.

Acknowledgment cycle

announced by group on 21 Sep 2004

agreement by reviewer on 28 Sep 2004

Action history

LC14: Mapping ref attribute to {fault reference} - Type Mismatch [link to this issue]

ref: http://www.w3.org/TR/2004/WD-wsdl20-20040803/#FaultReference_Mapping, http://www.w3.org/TR/2004/WD-wsdl20-20040803/#FaultReference_details Mapping, "{fault reference} = The actual value of the ref attribute information item" Component description, "{fault reference} REQUIRED. An Interface Fault component in the {faults} property of the parent Interface Operation component's parent Interface component. Identifying the Interface Fault component therefore indirectly defines the actual content or payload of the fault message." Actual value is a QName. But, {fault reference} is a component. Hence, the mismatch.

Transition history

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

agreed on 16 Sep 2004

Fix the mapping to say the value is the component.

Acknowledgment cycle

announced by group on 21 Sep 2004

agreement by reviewer on 28 Sep 2004

Action history

LC15: Editorial: {http location} feature [link to this issue]

This is an editorial issue. I am writing it on behalf of Wes Moulder, webMethods. ref: http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803/#soap-binding The last para in this section describes the use of {http location} feature within SOAP binding: "When the SOAP Message Exchange Pattern is the SOAP Response MEP, the Binding Operation may use the {http location} property defined in 3.6 Binding Operations. When such a location is specified, the Endpoint component also follows the rules for constructing the address from the {address} property and the {http location} property values."

To avoid confusion, we request you to list {http location} as the fifth bullet along with, {http version} {http transfer coding} {http cookies} {http authentication scheme}

Transition history

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

agreed on 1 Oct 2004

Delegated to editors.

Acknowledgment cycle

announced by group on 4 Oct 2004

agreement by reviewer on 4 Oct 2004

Action history

LC16: Interface = design of the application ?? [link to this issue]

I am writing this issue on behalf of Christopher St. John, webMethods. ref: http://www.w3.org/TR/2004/WD-wsdl20-20040803/#Interface_details "2.2.1 The Interface Component An Interface component describes sequences of messages that a service sends and/or receives. It does this by grouping related messages into operations. An operation is a sequence of input and output messages, and an interface is a set of operations. Thus, an interface defines the design of the application." This paragraph defines the design of the application. It appears that this para is moving too fast. It provides some evidence. But, its conclusion - "Thus, .." - does not carry sufficient evidence. Then again, WSDL does not have to say anything about the design of the application. Perhaps, the design of an interface. We suggest getting rid of the last sentence.

Transition history

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

agreed on 16 Sep 2004

Accept the proposal to remove the sentence: "Thus, an interface defines the design of the application."

Acknowledgment cycle

announced by group on 21 Sep 2004

agreement by reviewer on 28 Sep 2004

Action history

LC17: URI Serialization: Order may be Lost [link to this issue]

I am writing this e-mail on behalf of Wes Moulder, webMethods. ref: http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803/#_http_operation_location_notcited_uri "Uncited elements with list values are serialized as one name-value parameter pair per list value. The name of each parameter is the name of the uncited element, and the value of each parameter is the corresponding value in the list."

Is the order of the list value significant? If it is, this is a problem for a class of implementations: say implementations that use certain frameworks, such as servlet. Servlet framework does not capture the order. Particularly, this is an issue if my SOAP node is an intermediary and MEP is response pattern.

Proposed resolution from Sept 16 FTF: Clarify section 3.8.1.2.1 to state that for list values, the order of the values in the list are preserved in the url parameters. Same for auto-generated params.

Transition history

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

agreed on 7 Oct 2004

Accept the proposed resolution above.

Acknowledgment cycle

announced by group on 7 Oct 2004

Action history

LC18: Relationship between Features and SOAP Modules ?? [link to this issue]

ref: [1] http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803/#soap-module-decl [2] http://www.w3.org/TR/2004/WD-wsdl20-20040803/#Feature [3] http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#app-data [4] http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#adf-mu-att [5] http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#adf-module

Reading thru parts 1, 2 and 3, my question is what is the relationship between Features and SOAP Modules? I do not see any concrete text that establishes any relationship between Features and SOAP Modules. However, the application data feature and application data module [3][4][5] assumes that there is a relationship. If there is a relationship, shall we describe it clearly in part 1 and 3? As an implementer, I would like to see it.

Transition history

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

agreed on 9 Dec 2004

Add text stating that a SOAP abstract feature is also (by definition) an abstract WSDL feature).

Acknowledgment cycle

announced by group on 2 Feb 2005

Action history

LC19: Fault Component Re-usable Across Interfaces [link to this issue]

I am writing this issue on behalf of Christopher St. John, webMethods ref: http://www.w3.org/TR/2004/WD-wsdl20-20040803/#InterfaceFault Today, fault components are scoped to an interface component, aka interface component.{faults} Similar to element declaration components in message reference component.{element}, we would like to re-use fault components across interfaces. This usage naturally maps to many programming languages. We request the WG to elevate fault components as first class daughters of definition components. This will also eliminate unnecessary best practice statements such as, "For the above reason, it is considered good practice to ensure, where necessary, that the {name} property of Interface Fault components within a namespace are unique, thus allowing such derivation to occur without inadvertent error."

Transition history

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

declined on 10 Nov 2004

Unable to reach consensus to adopt the proposal. Closed without action.

Acknowledgment cycle

announced by group on 2 Feb 2005

LC20: Feature Composition Edge Cases [link to this issue]

ref: http://www.w3.org/TR/2004/WD-wsdl20-20040803/#Feature_composition_model Does our feature composition model capture all possible cases? I am not sure.

Here is a sample edge case,

	<interface name="Bank">
		<!-- All implementations of this interface must be secure -->
		<feature uri="http://example.com/secure-channel" required="true"/>
			..
	</interface>
	<interface name="OpenBank" extends="Bank">
		<!-- we don't give a damn -->
		<feature uri="http://example.com/secure-channel" required="false"/>
			..
	</interface>

According to Interface Component, "{features} = The set of Feature components corresponding to the feature element information items in [children], if any, plus the set of Feature components in the {features} property of the Interface components in {extended interfaces}, if any." According to our equivalence rules, feature declared in Bank interface is not equivalent to the feature declared in Open Bank interface. Because, the value of {required} property is different. If these two feature components are present in interface component.{features}, what is the net effect? Secure channel is an optional feature! That confuses me. Please revisit our feature composition model and flush out all such edge cases. Also, shall we provide a special rule for computing the equivalence of feature components?

Partial Resolution from 2005-01-19: "true" values intersect, that is, "true" trumps.

Transition history

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

agreed on 10 Mar 2005

"true" values intersect, that is, "true" trumps. No further edge cases discovered.

Acknowledgment cycle

announced by group on 3 May 2005

agreement by reviewer on 6 May 2005

LC21: Multipart Style and {direction}=out [link to this issue]

ref: http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803/#_operation_multipart_style "The Multipart style is selected by assigning the Interface Operation component's {style} property the value http://www.w3.org/2004/08/wsdl/style/multipart. The Multipart style may only be used for Interface Operation components whose {message exchange pattern} property has the value 'http://www.w3.org/2004/08/wsdl/in-only', 'http://www.w3.org/2004/08/wsdl/robust-in-only' or 'http://www.w3.org/2004/08/wsdl/in-out'. Use of this value indicates that XML Schema [XML Schema Structures] was used to define the schemas of the {element} properties of all Message Reference components of the Interface Operation component with {direction} property in. Those schemas MUST adhere to the rules below"

Why is multipart style limited to {direction}=in? Shall we allow multipart style for all message reference components with {direction}=out? If positive, then proposed change is, <proposed> Use of this value indicates that XML Schema [XML Schema Structures] was used to define the schemas of the {element} properties of all Message Reference components of the Interface Operation component. Those schemas MUST adhere to the rules below. .., </proposed>

Transition history

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

agreed on 14 Oct 2004

The Working Group found that there is utility in specifying the Multipart style on both inputs and outputs, and that separate control was desirable. It also envisions that this capability might be useful to style developers. Accordingly it agreed to: 1) move {style} from operations to message reference components, 2) change operation/@style to operation/@styleDefault and update the infoset mapping for message reference {style} to combine the value of this attribute with messageReference/@style, 3) change the Multipart and URI styles to be direction independent, and 4) make corresponding changes elsewhere in the documents.

Note that this issue was revisited in LC106.

Acknowledgment cycle

announced by group on 14 Oct 2004

agreement by reviewer on 21 Oct 2004

Action history

LC22: URI Style and SOAP Response Pattern [link to this issue]

ref: [1] http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803/#soap-defaults, [2] http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803/#_http_x-www-form-urlencoded "If the {soap mep} property of the Binding Operation component has the value "http://www.w3.org/2003/05/soap/mep/soap-response/" then the URI to execute the HTTP GET against MUST be generated using the HTTP binding's rules for generating a URI for HTTP GET (see 3. WSDL HTTP Binding). The input serialization format of x-www-form-urlencoded is the only supported serialization format for HTTP GET in the SOAP Response Message Exchange Pattern." [1] "This serialization format is designed to allow a Web Service to produce a URI based on the instance data of input messages. It may only be used for interface operation using the URI Style format as defined in 3.9.1 URI Style."

It appears to me that there is a strong relationship between the value of Message Reference.{style} and {soap mep} properties. Particularly, if {soap mep} has the value "http://www.w3.org/2003/05/soap/mep/soap-response/" then {style} must be http://www.w3.org/2004/08/wsdl/style/uri Is that true? If so, shall we state it? And, shall we establish a default binding rule? Are there too many iffs?

Transition history

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

Subsumed by issue(s) on 28 Oct 2004

This issue subsumed by the resolution to LC21.

LC23: Elaborate: Cannot be Serialized as XML 1.0 [link to this issue]

I am writing this issue on behalf of Christopher St. John, webMethods. ref: http://www.w3.org/TR/2004/WD-wsdl20-20040803/#component_model, http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/issues/wsd-issues.html#x177 "This document does not specify a means of producing an XML Infoset representation from a given set of WSDL components. Furthermore, given a particular serialization, not all valid sets of components need be serializable to it. For instance, due to the use in the component model of types that cannot be described using XML schema (.e.g wsdls:string), it is possible to come up with a valid set of WSDL components that cannot be serialized as an XML 1.0 document."

Last two sentences (above) sound very serious. I understand the issue and reasoning behind it. But, this paragraph does not provide sufficient information to first time readers. I request the editors to elaborate on why components cannot be serialized as an XML 1.0 doc and provide a link to the section that describes wsdl simple types.

Transition history

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

agreed on 28 Oct 2004

We will rework this text to make it clear that we are talking about the version of XML, and to clarify that this is due to unserializable constructs in the XML itself, and not related to validity under a particular version of XML Schema.

Acknowledgment cycle

announced by group on 29 Oct 2004

Action history

LC24: "ad:mustUnderstand" - ?? [link to this issue]

ref: http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#adf-mu-att, http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#adf-http-serial "You may choose to decorate your application data element declarations with an attribute with the namespace 'http://www.w3.org/2004/08/wsdl/feature/AD' and the local name "mustUnderstand". This indicates at the abstract level that the particular element thus decorated is mandatory, and implementations of this feature which support expression of mandatory data (i.e. the Application Data SOAP Module, see 3.2 Application Data Module) should mark them as mandatory in an appropriate way." I haven't come across any use case where a receiver would say thou must say that I must understand. Are there any use cases? I heard someone say 'versioning'. Powerful keyword! Doesn't connect in this context tho'. Also, how does ad:mustUnderstand annotation map to HTTP feature-binding, http://www.w3.org/2004/08/wsdl/feature/AD-HTTP ? What is a feature-binding? That is another issue. I request the WG to remove ad:mustUnderstand annotation attribute.

Transition history

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

Subsumed by issue(s) on 3 Mar 2005

See LC76d.

LC25: What is a feature-binding? [link to this issue]

ref: http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#adf-http-serial "3.3 Application data serialization as HTTP headers 3.3.1 Name This feature-binding is identified with the URI 'http://www.w3.org/2004/08/wsdl/feature/AD-HTTP'"

Part 2 introduces a new concept, feature-binding. This is in addition to Features and SOAP Modules. What is a feature-binding? Please clarify.

Transition history

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

agreed on 28 Oct 2004

Add a formal definition of feature-binding in the spec; and check on consistent use of the term feature-binding and module throughout the section.

Acknowledgment cycle

announced by group on 29 Oct 2004

Action history

LC26: wsdlLocation on the chopping block ? [link to this issue]

I am writing this issue on behalf of Wes Moulder, webMethods. ref: http://www.w3.org/TR/2004/WD-wsdl20-20040803/#wsdllocation wsdlLocation [1] looks and smells like xsi:schemaLocation. But, I do not have any concrete use cases. Are there any? I read thru some of the other WS specifications - BPEL4WS [2], Choreography [3] and WS-Addressing [4] - mentioned at the F2F meeting [5]. None of these specs have use cases for wsdlLocation. WS-Message Delivery [6] uses wsdlLocation. But, this functionality will be replaced with parts from WS-Addressing. Plus, the opening statement in Section 7, "WSDL documents or fragments or references to WSDL components (via QNames) MAY appear within other XML documents" [ref] - do we allow WSDL component references via wsdlLocation? In the absence of concrete use cases, this appears to be a cool solution looking for a killer problem. We request the WG to re-consider wsdlLocation.

[1] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0257.html [2] http://www-106.ibm.com/developerworks/webservices/library/ws-bpel/ [3] http://www.w3.org/2002/ws/chor/edcopies/cdl/cdl.html [4] http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/ [5] http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0039.html [6] http://www.w3.org/Submission/2004/SUBM-ws-messagedelivery-20040426/

Transition history

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

declined on 28 Oct 2004

The Working Group still sees a use for wsdlLocation and so it will remain. We will reword the first paragraph of Section 7 so that it's clear, esp. in terms of using WSDL component designators in wsdlLocation - wsdlLocation locates a WSDL document, aka <wsdl:definitions>, so component identifiers (which point to something else) are not presumed to work.

Acknowledgment cycle

announced by group on 29 Oct 2004

Action history

LC27: Property Composition Edge Cases [link to this issue]

ref: http://www.w3.org/TR/2004/WD-wsdl20-20040803/#Property_composition_model Does our property composition model capture all possible cases? I am not sure.

Here is a sample edge case,

	<interface name="Bank">
		<!-- capable of accepting Kerberos v5 token -->
		<property uri="http://example.com/secure-channel#tokenType">
			<value>wsse:Kerberosv5TGT</value>
		</property>
		 .. 
	</interface>
	<interface name="OpenBank" extends="Bank">
		<!-- capable of accepting x509 certificate -->
		<property uri="http://example.com/secure-channel#tokenType">
			<value>wsse:X509v3</value>
		</property>
		 ..
	</interface>

According to Interface Component, "The set of Property components corresponding to the property element information items in [children], if any, plus the set of Property components in the {properties} property of the Interface components in {extended interfaces}, if any." According to our equivalence rules, property declared in Bank interface is not equivalent to the property declared in Open Bank interface. Because, the value of {value} property is different. If these two property components are present in interface component.{properties}, what is the net effect? This will be further complicated if I use {value constraint}. Do we have a notion of type equivalence (for {value constraint})? Please revisit our property composition model and flush out all such edge cases. Also, shall we provide a special rule for computing the equivalence of property components?

Partial Resolution from 2005-01-19: value sets intersect.

Transition history

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

agreed on 10 Mar 2005

Value sets intersect. No further edge cases discovered.

Acknowledgment cycle

announced by group on 3 May 2005

agreement by reviewer on 6 May 2005

LC28: HTTP Transfer Coding and 1.0 [link to this issue]

ref: http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803/#http-transfer-coding-decl "3.10.1 Description Every Binding Message Reference component MAY indicate which transfer codings, as defined in section 3.6 of [IETF RFC 2616], are available for this particular message." This feature does not apply to HTTP 1.0 And, when {http version}="1.0" and {http transfer coding} claim is made, is that an error or should the processors safely ignore it? I prefer the latter. Please clarify.

Transition history

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

agreed on 31 Mar 2005

Adopted proposal.

Acknowledgment cycle

announced by group on 3 May 2005

agreement by reviewer on 6 May 2005

Action history

LC29a: Review of WSDL 2.0 Pt 3 Last Call WD (a) [link to this issue]

Section 2 WSDL SOAP Binding "Notice that there are no 
default binding rules defined for Interface Fault components by this binding. 
Thus, if a given Interface component has any Fault components, then such 
Interface components MUST be bound via Binding components which indicate a 
specific interface and contain as many Binding Fault components as there are 
Fault components in the Interface Fault component."

Comment: It's unclear why default binding rules are not defined for fault 
components. The additional information that would be required is minimal 
and this feature would be useful.

Transition history

raised on 9 Sep 2004 by Marc Hadley (Marc.Hadley@Sun.COM) on behalf of XMLP WG

agreed on 15 Sep 2004

Add a rationale to the spec explaining there is no good default value for code and subcode.

Acknowledgment cycle

announced by group on 7 Oct 2004

Action history

LC29b: Review of WSDL 2.0 Pt 3 Last Call WD (b) [link to this issue]

Section 2.6 Declaring SOAP Modules 

Comment: The relationship between SOAP Modules declared in the binding and 
features declared in the interface is unclear. From the SOAP 1.2 Rec 
(section 3.3): "A SOAP module realizes zero or more SOAP features". 
I would expect a similar relationship in WSDL such that a SOAP module in 
a binding would reference one or more features in the interface, a module 
being the binding of those features to the protocol.

Transition history

raised on 9 Sep 2004 by Marc Hadley (Marc.Hadley@Sun.COM) on behalf of XMLP WG

agreed on 9 Dec 2004

Add text stating that a SOAP abstract feature is also (by definition) an abstract WSDL feature).

Acknowledgment cycle

announced by group on 2 Feb 2005

Action history

LC29c: Review of WSDL 2.0 Pt 3 Last Call WD (c) [link to this issue]

Section 3 WSDL HTTP Binding "Notice that there 
are no default binding rules defined for Fault components by this binding." 

Comment: Similar to the case for the SOAP binding, it's unclear why the extra 
step was not taken to define such default binding rules. 

Transition history

raised on 9 Sep 2004 by Marc Hadley (Marc.Hadley@Sun.COM) on behalf of XMLP WG

agreed on 15 Sep 2004

Similar fix as LC29a.

Acknowledgment cycle

announced by group on 7 Oct 2004

Action history

LC29d: Review of WSDL 2.0 Pt 3 Last Call WD (d) [link to this issue]

Section 3.3 Default Binding Rules "Mechanisms that are 
outside the scope of this specification MAY modify the serialization format 
of the instance data corresponding to the output message. An example of such 
modification is the combination of the serialization as 
application/x-www-form-urlencoded and the SOAP-Response Message Exchange 
Pattern ([SOAP 1.2 Part 2: Adjuncts], Section 6.3)." 

Comment: More detail required here, it's not clear what the example is 
trying to illustrate.

Transition history

raised on 9 Sep 2004 by Marc Hadley (Marc.Hadley@Sun.COM) on behalf of XMLP WG

agreed on 4 Nov 2004

Adopted clarified wording as proposed in DaveO's proposal.

Acknowledgment cycle

announced by group on 4 Nov 2004

Action history

LC29e: Review of WSDL 2.0 Pt 3 Last Call WD (e) [link to this issue]

Section 3.8.1.1 Case of elements cited in whttp:location attribute 
"When constructing the request URI, each pair of curly braces (and enclosed 
element name) is replaced by the corresponding content of the element." 

Comment: What is the expected behavior when the element is not present in 
the instance data or is nil. The rules in section 3.9.1 appear to allow 
both things to happen.

Transition history

raised on 9 Sep 2004 by Marc Hadley (Marc.Hadley@Sun.COM) on behalf of XMLP WG

agreed on 15 Sep 2004

Make it an error for instance documents to have elements with xsi:nil=true. Make it an error to have nil values when trying to auto-generate parameters.

Acknowledgment cycle

announced by group on 7 Oct 2004

Action history

LC29f: Review of WSDL 2.0 Pt 3 Last Call WD (f) [link to this issue]

Section 3.8.3 Serialization as "multipart/form-data" 
						
Comment: What is the expected serialization of an element that is nil in the 
instance data ? An empty part, an omitted part ? 

Transition history

raised on 9 Sep 2004 by Marc Hadley (Marc.Hadley@Sun.COM) on behalf of XMLP WG

agreed on 15 Sep 2004

Close 29f with the same resolution as 29e (add bullet to 3.8.3).

Acknowledgment cycle

announced by group on 7 Oct 2004

Action history

LC29g: Review of WSDL 2.0 Pt 3 Last Call WD (g) [link to this issue]

Section 3.9 Operation Styles 
						
Comment: The relationship between the operation styles defined in this section 
to the serializations defined in section 3.8 would be clarified by listing the 
permitted serializations for each style. Currently the serializations list the 
allowed style but not the other way round. Consider switching the order of 3.8 
and 3.9.

Transition history

raised on 9 Sep 2004 by Marc Hadley (Marc.Hadley@Sun.COM) on behalf of XMLP WG

agreed on 1 Oct 2004

Delegated to editors.

Acknowledgment cycle

announced by group on 7 Oct 2004

Action history

LC29h: Review of WSDL 2.0 Pt 3 Last Call WD (h) [link to this issue]

Section 3.9 Operation Styles 
						
Comment: Should there be a style defined to match the serialization defined 
in 3.8.2 ? 

Transition history

raised on 9 Sep 2004 by Marc Hadley (Marc.Hadley@Sun.COM) on behalf of XMLP WG

declined on 15 Sep 2004

No compelling reason to do so.

Acknowledgment cycle

announced by group on 7 Oct 2004

LC30: use of provider agent & requestor agent terms in the spec [link to this issue]

The part1 spec (in the mandatory extensions section and the conformance section) 
uses the terms "provider agent" and "requestor" agent. IBM would like to see 
these terms removed as they are not used elsewhere in the specs.

Transition history

raised on 14 Sep 2004 by Sanjiva Weerawarana (sanjiva@watson.ibm.com)

agreed on 7 Oct 2004

Use the terms "Web service" and "consumer"/"client" consistently throughout.

Acknowledgment cycle

announced by group on 7 Oct 2004

Action history

LC31: WSDL conformance & XML Schema conformance [link to this issue]

Part 1 says, talking about the WSDL 2.0 XML Schema in Table 1-1: WSDL documents 
that do NOT conform to this schema are not valid WSDL documents. It then says 
in section 2: it is possible to come up with a valid set of WSDL components 
that cannot be serialized as an XML 1.0 document. It is therefore possible to 
have a document which does not conform to the schema, such as an valid XML 1.1 
serialization, and is yet a valid WSDL document. I think that the following 
in section 8 may also be an issue for XML 1.1 serializations: An element 
information item whose namespace name is "http://www.w3.org/2004/08/wsdl" 
and whose local part is definitions conforms to this specification if it 
conforms to the XML Schema for that element as defined by this specification 
family and additionally adheres to all the constraints contained in this 
specification. We need to make it clearer that XML Schema conformance only 
works for documents for which XML Schema 1.0 is applicable, i.e. XML 1.0 
documents. This comment also applies to section 1.1 Part 3, which is basically 
similar to Part 1's Table 1-1.

Transition history

raised on 14 Sep 2004 by Hugo Haas (hugo@w3.org)

agreed on 16 Sep 2004

Remove text regarding schema validity from section 1.2 and add text to describe schema is for the conformance of XML 1.0 serialisation and the intent is it may be applied to other future serialisations such as XML 1.1

Make clear that mapping to XML is 1.0 specific.

Acknowledgment cycle

announced by group on 29 Sep 2004

Action history

LC32: Part 3 examples 3-1, 3-2 and 3-3 errors [link to this issue]

Because the URI and Multipart styles both say: The localPart of input element's 
QName MUST be the same as the Interface operation component's name. examples 3-1,
3-2 and 3-3 are wrong. They say, taking example 3-1 as an example: The following 
instance data of an input message
	<data>
		 <town>Frejus</town>
		 <date>2004-01-16</date>
		 <unit>C</unit>
	</data>
with the following operation element
	<operation ref='t:io' whttp:location='temperature/{town}' 
								whttp:method='GET' /> 
The operation element's ref attribute should be t:data. 

Transition history

raised on 14 Sep 2004 by Hugo Haas (hugo@w3.org)

agreed on 23 Sep 2004

Fixed by editors.

Acknowledgment cycle

announced by group on 4 Nov 2004

Action history

LC33: Part 3 SOAP Binding: default HTTP method [link to this issue]

Section 2.3 says: HTTP Method Selection. This default binding rule is applicable 
when the value of the {soap underlying protocol} property of the Binding component
is "http://www.w3.org/2003/05/soap/bindings/HTTP/". If the {soap mep} property 
of the Binding Operation component has the value 
"http://www.w3.org/2003/05/soap/mep/request-response/" then the default value 
of the {http method} property is POST. If the {soap mep} property of the 
Binding Operation component has the value 
"http://www.w3.org/2003/05/soap/mep/soap-response/" then the default value of the 
{http method} property is GET.

The binding doesn't provide HTTP method selection as I read it. Therefore, 
those values are not defaults and fixed values.

Transition history

raised on 14 Sep 2004 by Hugo Haas (hugo@w3.org)

agreed on 16 Sep 2004

Remove 'default' from text in bullet item "HTTP Method Selection"

Acknowledgment cycle

announced by group on 21 Sep 2004

Action history

LC34a: Completing Part 1 Appendix C: URI References for WSDL constructs (a) [link to this issue]

First, I believe that we should point to Appendix C every time we talk about not 
being able to a component by a simple QName, such as in sections 2.3.1, 2.4.1 
and 2.14.1, but there may be others that I have missed.

Transition history

raised on 14 Sep 2004 by Hugo Haas (hugo@w3.org)

agreed on 16 Sep 2004

Add links to sections of specification where we note that QName is insufficient to identify a component.

Acknowledgment cycle

announced by group on 21 Sep 2004

Action history

LC34b: Completing Part 1 Appendix C: URI References for WSDL constructs (b) [link to this issue]

Second, section C.2 is lacking references for the following components in order 
for us to fulfill R120, "The description language MUST ensure that all conceptual 
elements in the description of Messages are addressable by a URI reference"; 
I am proposing some solutions:
- message reference: messageref(interface/operation/direction/label); 
- fault reference: faultref(interface/operation/direction/label/ref); 
- binding fault: bindingfault(binding/ref); 
- binding operation: bindingoperation(binding/ref); 
- binding message reference: bindingmessageref(binding/operation/direction/label). 

Transition history

raised on 14 Sep 2004 by Hugo Haas (hugo@w3.org)

agreed on 16 Sep 2004

Accept proposal in general, include F&P additions too.

Acknowledgment cycle

announced by group on 21 Sep 2004

Action history

LC34c: Completing Part 1 Appendix C: URI References for WSDL constructs (c) [link to this issue]

Third, some of the construct names in the first column are not corresponding 
exactly to components names:
- s/operation/interface operation/;
- s/fault/interface fault/.

Transition history

raised on 14 Sep 2004 by Hugo Haas (hugo@w3.org)

agreed on 16 Sep 2004

Accept the proposal - change names to match component names in table C-1.

Acknowledgment cycle

announced by group on 21 Sep 2004

Action history

LC34d: Completing Part 1 Appendix C: URI References for WSDL constructs (d) [link to this issue]

Finally, I find the the x / y convention hard to read. What about something 
like: endpoint: _endpoint_ being the {name} property of endpoint 
and _service_ being the {name} property of parent service: 
endpoint(_service_/_endpoint_) with _foo_ being typographically different, 
e.g. in italic?

Transition history

raised on 14 Sep 2004 by Hugo Haas (hugo@w3.org)

agreed on 16 Sep 2004

Table will be reworked to be more readable when new components are added.

Acknowledgment cycle

announced by group on 21 Sep 2004

Action history

LC35: Part 1 editorial comments [link to this issue]

Below is a list of typos and editorial fixes I noted in Part 1: 

- section 2: s/.e.g/e.g./. 
- section 2.1.1: s/and that it resolve/and that it resolves/. 
- section 2.4.2: s/such as 'http://www.w3.org/2004/08/wsdl/in-only'/i.e. 
	when ''http://www.w3.org/2004/08/wsdl/in-only' is in use/; indeed, 
	this is the only possibility. 
- section 2.4.2.1: s/AII/&AII;/ and s/be be/be/.
- section 2.4.3.4: s/whether the operation is safe or not/whether the 
	operation is declared to be safe or not/; indeed, safe='false' doesn't 
	mean that the operation isn't safe, but that it hasn't been 
	declared as such as per 2.4.1. 
- section 2.5.1: s/wsdls:token/wsdls:Token/. 
- section 2.6.2.1: s/fault attribute information item/ref attribute 
	information item/. 
- section 2.7.1.1.1: the example is missing the WSDL default namespace. 
- section 10.1: I don't think that the RDF mapping is a normative reference; 
	it is an informative one. 
- sections A and A.2: there are editor's notes remaining that should be 
	removed. 
- section D.1: "This section will provide some rationale for it and 
	provide hints on how to work around some scenarios."; they are missing.

Transition history

raised on 14 Sep 2004 by Hugo Haas (hugo@w3.org)

agreed on 14 Apr 2004

Accept editor's resolution of the issue.

Acknowledgment cycle

announced by group on 29 Apr 2005

Action history

LC36: Part 3 organization: wsdls:* versus xs:* [link to this issue]

The following is editorial. Part 1 does a good job of presenting properties 
and their types in the Relationship to WSDL Component Model section, and an 
XML 1.0 serialization using XML Schema types in the XML Representation section. 
This isn't the case of Part 3, which uses wsdls:* in the XML Representation 
section, and uses xs:* in the pseudo-schema only. This needs to be fixed by: 
- adding wsdls:* types in the Relationship to WSDL Component Model section. 
- changing wsdls:* by xs:* in the XML Representation section.

Transition history

raised on 14 Sep 2004 by Hugo Haas (hugo@w3.org)

agreed on 23 Sep 2004

Fixed by editors.

Acknowledgment cycle

announced by group on 29 Sep 2004

Action history

LC37: Part 3 3.6.4 Mapping Between HTTP Operation's XML Representation to Component Properties and default values [link to this issue]

Section 3.6.4 doesn't talk about default values in the mapping: 
- {http method}: should use whttp:methodDefault as a default, if it is present. 
- {http input serialization} and {http output serialization}: should use the default 
	corresponding to the given HTTP method as the default.

Transition history

raised on 14 Sep 2004 by Hugo Haas (hugo@w3.org)

agreed on 16 Sep 2004

Accommodate the method default and input serialization default in part 3, section 3.6.4

Acknowledgment cycle

announced by group on 29 Sep 2004

Action history

LC38: Part 1: DTD as the schema language for WSDL [link to this issue]

Section E.1 reads: A DTD may be used as the schema language for WSDL. 
and then: The prefix, dtd, used throughout the following is mapped to the 
namespace URI "http://www.example.org/dtd/". It is not clear whether this 
whole section is provided for real use, which seems like it according to the 
level of details, or as an example, which the example namespace URI suggests. 
I would suggest picking a real URI on www.w3.org for this section.

Transition history

raised on 14 Sep 2004 by Hugo Haas (hugo@w3.org)

agreed on 16 Sep 2004

Use a www.com URI instead of example.org.

Acknowledgment cycle

announced by group on 29 Sep 2004

Action history

LC39: Part 2 editorial comment [link to this issue]

Section 3.2 says: This module is identified with the URI... I would suggest 
s/module/SOAP module/ as this isn't any kind of module that is defined here, 
but a SOAP 1.2 module.

Transition history

raised on 14 Sep 2004 by Hugo Haas (hugo@w3.org)

agreed on 14 Apr 2004

Accept editor's resolution of the issue.

Acknowledgment cycle

announced by group on 29 Apr 2005

Action history

LC40: typo [link to this issue]

Part 2, Section 3.1.2: s/The senders/The sender/ 

Transition history

raised on 15 Sep 2004 by David Booth (dbooth@w3.org)

agreed on 14 Apr 2004

Accept editor's resolution of the issue.

Acknowledgment cycle

announced by group on 29 Apr 2005

agreement by reviewer on 17 May 2005

Action history

LC41: Clarification for use of xs:include [link to this issue]

Part 1 section 3.1.2 states:
"Inside an embedded XML schema, the xs:import and xs:include element 
information items MAY be used to refer to other XML schemas embedded 
in the same WSDL description, provided that an appropriate value is 
specified for their schemaLocation attribute information items. The s
emantics of such element information items are governed solely by the 
XML Schema specification [XML Schema:	<http://www.w3.org/TR/2004/WD-wsdl20-20040803/#XMLSchemaP1> Structures]." It doesn't say anything about what's the "appropriate value" and implies that it's the question for schema spec. 
 
I searched our mail archival, there were many messages exchanged about 
this but seems no conclusion was drawn about what the "appropriate 
value" should be for @schemalocations in the following example?	
 
<type>
		<xs:schema targetNamespace = "a"> ....</schema>
 
		<xs:schema targetNamespace = "b">
				<xs:import namespace = "a" schemalocation = "???"/> ...
		</schema>
 
		<xs:schema targetNamespace = "a"> 
				<xs:include	schemalocation = "???"/> ...
		</schema>
 
<type>
 
Some suggested that for the xs:import in "b", the @schemalocation should 
not present (it's optional anyway).	But nothing has been said about the 
case for the second "a" which xs:includes the first "a". is it legal 
(the spec quoted above implies yes)? if so, what's the right value for
 xs:include@schemaLocation(not it's a required attribute ) ?	

Any one can help? Since this a confusing area, I am thinking to 
include something in the Primer.

Transition history

raised on 9 Sep 2004 by Liu, Kevin (kevin.liu@sap.com)

agreed on 23 Sep 2004

Add ", such as fragment identifiers (see Schema 4.3.1)," and a similar statement to section 3.1.1 about importing schema.

Acknowledgment cycle

announced by group on 29 Sep 2004

agreement by reviewer on 29 Sep 2004

Action history

LC42: error in part 2, section 3.1.4 [link to this issue]

The namespace value of "myDataType" is inconsistent in the example 
(see bold text).

Proposal: change the second case to : xmlns:foo="http://example.com/ws/wsdl20/my-ws"
<types>

 <schema targetNamespace="http://example.com/ws/wsdl20/my-ws"
				 xmlns:xs="http://www.w3.org/2001/XMLSchema"
				 xmlns="http://www.w3.org/2001/XMLSchema"
				 xmlns:ad="http://www.w3.org/2004/08/wsdl/feature/AD">
	<!-- Define the data type we'll use later -->
	<complexType name="myDataType">
	 <sequence>
		<!-- These elements are our data -->
		<element name="isGoldClubMember" type="xs:boolean"
						 ad:mustUnderstand="true" />
		<element name="promotionalCode"
						 type="xs:string"
						 minOccurs="0"/>
	 </sequence>
	</complexType>
 </schema>
</types>
<interface name="customerService">
 <operation name="reserveCar">
	<input element="myNS:reserveCarRequest">
	 <property uri="http://www.w3.org/2004/08/wsdl/feature/AD/data">
		<constraint xmlns:foo="http://example.com/">
		 foo:myDataType
		</constraint>
	 </property>
	</input>
 </operation>
</interface>

Transition history

raised on 10 Sep 2004 by Liu, Kevin (kevin.liu@sap.com)

agreed on 23 Sep 2004

Make namespaces consistent as proposed.

Acknowledgment cycle

announced by group on 29 Sep 2004

agreement by reviewer on 29 Sep 2004

Action history

LC43: Rename <definitions> to <description> [link to this issue]

Since WSDL is the Web Services Description Language, it is 
natural to make its root element <description>. A WSDL document 
describes a Web service. The document is therefore a description. 
This change would make our names more consistent with XSD, i.e 
it is XML Schema language its root element is <schema>. 
The Definitions component should be called the Description 
component.

Transition history

raised on 16 Sep 2004 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 23 Sep 2004

Proposal accepted.

Acknowledgment cycle

announced by group on 29 Sep 2004

Action history

LC44: Part 3 editorial comment: 3.8.1 not written in terms of component model [link to this issue]

I noticed an editorial issue with Part 3 section 3.8.1 Serialization 
as "application/x-www-form-urlencoded". It talks about the 
whttp:location attribute and the location attribute information item 
when I think it should be talking about the {http location} property.

Transition history

raised on 20 Sep 2004 by Hugo Haas (hugo@w3.org)

agreed on 27 Oct 2004

Resolved by editor.

Acknowledgment cycle

announced by group on 29 Oct 2004

Action history

LC45: Part 3 section 3.6.2: {http location} not necessarily a template [link to this issue]

Section 3.6.2 of Part 3 says: {http location}, a wsdls:anyURI. 
The value of this property specifies a template for the relative 
portion of the request URI for an operation. This URI is combined 
with the base URI specified in the {address} property of the 
endpoint element to form the full URI for the HTTP request to 
invoke the operation. Actually, this is a template only for the 
application/x-www-form-urlencoded serialization, and is defined 
as such in section 3.8.1. It isn't a template for other serializations 
we define.

I suggest dropping the following sentence: The value of this 
property specifies a template for the relative portion of the 
request URI for an operation. 

Transition history

raised on 20 Sep 2004 by Hugo Haas (hugo@w3.org)

agreed on 7 Oct 2004

Accept option 2 described in http://lists.w3.org/Archives/Public/www-ws-desc/2004Sep/0049.html.

Acknowledgment cycle

announced by group on 7 Oct 2004

Action history

LC46: Issue: missing "type" attribute in schema for wsdl:binding [link to this issue]

In the normative WSDL schema at [1], the wsdl:bindingType type fails to
define a required attribute of name "type" and type xs:anyURI, contradicting
the specification [2].

[1] http://www.w3.org/2004/08/wsdl/
[2] http://www.w3.org/TR/2004/WD-wsdl20-20040803/#Binding

Transition history

raised on 13 Sep 2004 by Roberto Chinnici (roberto.chinnici@sun.com)

agreed on 14 Apr 2004

Accept editor's resolution of the issue.

Acknowledgment cycle

announced by group on 29 Apr 2005

Action history

LC47: Issue: describing the HTTP error text for faults [link to this issue]

As discussed at the f2f, when binding a fault to the HTTP protocol,
we need to be able to specify the error text in addition to the HTTP
status code. The rationale is that the client may want to use
the error text to distinguish between faults with the same status code.

Transition history

raised on 15 Sep 2004 by Roberto Chinnici (roberto.chinnici@sun.com)

agreed on 7 Apr 2005

Accept DaveO's proposal.

Acknowledgment cycle

announced by group on 3 May 2005

Action history

LC48a: XMLP Review of WSDL 2.0 Part 2 LC WD (a) [link to this issue]

Editorial - mismatched document scope
WSDL Part 1 introduction describes Part 2 as "The WSDL Version 2.0 Part 2: 
Message Exchange Patterns specification [WSDL 2.0 Predefined Extensions] 
defines the sequence and cardinality of abstract messages sent or received 
by an operation." However the Part 2 abstract section describes itself 
more broadly than MEPS: "describes extensions for the Web Services Description 
Language (WSDL) Version 2.0 . These extensions include Message Exchange 
Patterns (MEPs), features, SOAP modules, and bindings of features". 

Recommendation: revise Part 1 Introduction text, moving the abstract text from 
Part 2 into the Intro of Part 1 for consistency and accuracy.

Transition history

raised on 27 Sep 2004 by Michael Mahan on behalf of XMLP WG

agreed on 14 Apr 2004

Accept editor's resolution of the issue.

Acknowledgment cycle

announced by group on 29 Apr 2005

agreement by reviewer on 13 May 2005

Action history

LC48b: XMLP Review of WSDL 2.0 Part 2 LC WD (b) [link to this issue]

Clarification request in section 2 - 'Predefined Message Exchange Patterns'
The relationship between WSDL defined MEPs and SOAP defined MEPs is unclear: 
"WSDL message exchange patterns describe the interaction at the abstract 
(interface) level, which may be distinct from the pattern used by the underlying 
protocol binding (e.g. SOAP Message Exchange Patterns)." 

Recommendation: Could you clarify the relationship between abstract WSDL MEPs 
and SOAP bindings MEPs? An important aspect of the clarification is the disposition 
of WSDL-defined faults (Fault Propagation Rules) in light of the SOAP processing model.

Transition history

raised on 27 Sep 2004 by Michael Mahan on behalf of XMLP WG

agreed on 11 Nov 2004

Add text to part 2 and 3 about WSDLMEP and SOAP mep mapping that ponts to section 2.3 of part 3.

Acknowledgment cycle

announced by group on 29 Apr 2005

agreement by reviewer on 13 May 2005

Action history

LC48c: XMLP Review of WSDL 2.0 Part 2 LC WD (c) [link to this issue]

Editorial - sections 2.1.[12]
The cardinality of faults is raised, yet the patterns do not define message 
cardinality. Perhaps this is an old artifact when message cardinality was defined. 

Recommendation: remove references to message cardinality.

Transition history

raised on 27 Sep 2004 by Michael Mahan on behalf of XMLP WG

agreed on 14 Apr 2004

Accept editor's resolution of the issue.

Acknowledgment cycle

announced by group on 29 Apr 2005

agreement by reviewer on 13 May 2005

Action history

LC48d: XMLP Review of WSDL 2.0 Part 2 LC WD (d) [link to this issue]

Editorial - section 3.1 Application Data Feature
General editorial comment. The rationale for AD is 'to enable the description of 
application-defined additional data declarations outside of the normal data channel 
(e.g. the SOAP body).' This is in line with the notion of 3. Predefined Features: 
"(WSDL) features (hereafter 'features') define pieces of extended functionality which 
typically affect message exchanges. Examples may include "reliability", "security", 
or "correlation", among others." Yet the AD example is used to convey seemingly very 
SOAP body relevant data - 'isGoldClubMember' and 'promotionalCode' in a 'reserveCar' 
operation. 

Recommendation: use a more compelling example - or perhaps I am missing the point 
with AD?

Transition history

raised on 27 Sep 2004 by Michael Mahan on behalf of XMLP WG

agreed on 9 Nov 2004

Add text along the lines of "There is a pre-existing "reserveCarRequest" XML data type, which is to be sent as the body of a WSDL operation. Unfortunately, the designers of this type did not leave any extensibility hooks in the schema. The WSDL designer desires to send two pieces of additional data..... " to clarify AD example, explain in intro to AD feature what the intended use is, and add that it SHOULD be used at interface level while discouraging use at binding level.

Acknowledgment cycle

announced by group on 29 Apr 2005

agreement by reviewer on 13 May 2005

Action history

LC49: Clarify whether Parts 2 & 3 MUST be supported [link to this issue]

Part 1 Section 8.3[1] should clarify whether the Part 2 Predefined
Extensions and Part 3 Bindings must be supported by a conformant WSDL
processor.	Section 8.3 says that "a conformant WSDL processor MUST
accept any legal WSDL document as defined by this specification", but it
isn't clear whether "this specification" refers to all of Parts 1, 2 & 3
taken together, or only Part 1.

References
1. http://www.w3.org/TR/2004/WD-wsdl20-20040803/#processor

Transition history

raised on 28 Sep 2004 by David Booth (dbooth@w3.org)

agreed on 9 Nov 2004

Issue closed by:

1. Rewording 8.1 as follows: "An element information item whose namespaces name is "...wsdl" and whose local part id definitions conforms to this specification if it is a valid according to the XML schema for that element as defined by this specification (uri to schema) and additionally adheres to all the constraints contained in this specification family and conforms to the specifications of any extensions contained in it."
2. add conformance sections to each of the bindings.
3. + 8.3, clarify that "this specification" means Part 1.
4. + adding a note advising extension specification authors to have a clear statement of conformance.

Acknowledgment cycle

announced by group on 3 May 2005

agreement by reviewer on 17 May 2005

Action history

LC50: Message Exchange Patterns -- p2c and/or p2e [link to this issue]

As currently defined, the WSDL 2.0 in-out MEP[1] requires the service to
send the response message back to the original requester agent, as
illustrated by pattern p2e[2] in "MEPs versus IOPs".	(This is in
contrast with pattern p2c[3], which permits the response to go to a
third party.)	

I think the WG should either:
	a. Add a pattern like p2c[3] to the MEPs in part 2,
		 in addition to the existing in-out MEP; 
	b. Replace the existing in-out MEP with a pattern like p2c[3].

RATIONALE
Suppose a service wishes to permit the response to be sent to a third
party.	For example: requester agent A sends a request to service S,
which sends the response to agent B (by use of an addressing extension,
for example).	What should service S do, given that the semantics of the
in-out MEP require the response to be sent back to A?	How should
service S be described in WSDL?	It could:
	a. modify the semantics of WSDL 2.0 by use of a required
		 extension (wsdl:required = "true");
	b. use an MEP that is not pre-defined in WSDL 2.0, such as
		 p2c[3]; or
	c. violate the WSDL 2.0 specification.

Pattern p2c[3] was considered earlier by the WG, when the WG discussed
MEPs, and I think the main reasons for adopting p2e[2] instead were:
	- It captures the intent of many common interactions.
	- It permits a requester toolkit to generate code that 
	supports a very simple, function-like usage style, 
	independent of what binding is used:
			Reply message = service.send(requestMessage);
	while not precluding an event-driven
	implementation style that would be needed by p2c[3].

However, I believe two things have changed since the WG made that
decision:

1. The WG became more permissive about the set of MEPs that it defines
in Part 2, adding MEPS for additional fault treatments (Robust-In-Only,
Robust-Out-Only) and optional responses (In-Optional-Out,
Out-Optional-In).

2. The use of Web service addressing extensions is now receiving more
attention.	For example, the W3C is now considering creating a Web
services addressing WG.

3. A requester toolkit could have an option (for each operation) to
generate code in the function-like usage style shown above, even if the
service specifies pattern p2c[3], and it could even be the default
option.	(In this case, the requester toolkit would hide the fact that A
and B need not be the same in p2c[3].)	Others may correct my memory,
but I don't think this possibility was considered at the time when the
MEP TF was discussing the pros and cons of p2c versus p2e.	

Incidentally, one potential argument for adopting BOTH p2e[2] and p2c[3]
is that p2e[2] also allows the *service* toolkit to optimize
interactions because it knows that the reply always goes back to the
same agent that sent the request.	For example, it permits a single HTTP
interaction to transmit both the request and the response.	This is a
further consideration that I don't remember discussing during the MEP
TF.


References
1. WSDL 2.0 in-out MEP:
http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#in-out
or: http://tinyurl.com/4rsvz 
2. p2e:
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/meps-vs-iops_clean.htm#p2e
or: http://tinyurl.com/53hqp 
3. p2c:
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/meps-vs-iops_clean.htm#p2c
or: http://tinyurl.com/4pjo4 

Transition history

raised on 28 Sep 2004 by David Booth (dbooth@w3.org)

agreed on 20 Jan 2005

Adopt proposal for definition of "node" at http://lists.w3.org/Archives/Public/www-ws-desc/2004Nov/0070.html, adding "Note:" before second sentence.

Acknowledgment cycle

announced by group on 12 May 2005

agreement by reviewer on 20 May 2005

Action history

LC51: Editorial last call review comments [link to this issue]

Hi all, finally reading (most of) the Last Call drafts of WSDL 2 I have
the following editorial comments (at least I think they are editorial).

Every comment starts with the number of the relevant section.

PART 1:

2. "independent of any particular serialization" - should mention XML
1.0/1.1 as rationale

2.1.1 after "i.e. they define the [local name], [namespace name],
[children] and [attributes] properties of an element information item"
add that this is equivalent to XML Schema global element declarations.
Also might want to add the type definitions, i.e. they define the
[children] and [attributes] properties, because type definitions are
also relevant.

table 2.1 doesn't mention {type definitions}

2.8.1 {value constraint} doesn't refer to {type definitions} - it is the
only user thereof, so it probably should

2.1.1 "The target namespace URI SHOULD point to a human or..." should
probably be combined with next sentence/paragraph because they are
closely related.

2.3 faults should be moved after 2.4 operations, because it makes more
sense - operations are more important, right? Same in other listings
containing the two.

2.4.1 {safety}: 2 references to web architecture redundant

2.4.2 before bullet list the "MUST be" should be rephrased as "are"

2.4.2.1 expand the acronym AII

2.4.2.1 {rpc-signature} ... of type wsdls:QName (as defined in 2.15.4
anyURI type) - mismatch QName and 2.15.4 anyURI reference

2.4.2.1 bullet 3 uses d0, d1, bullet 2 uses u0, u1 etc.

2.7.1.1 missing fault reference components in second bullet list, fault
reference components can also have f&p, right?

2.7.1.1.1 "iso9001" *space* *comma* - drop the space

2.13.2 note about service references at the end of the section deserves
more visibility, like its own subsection on "reusing <service> type for
service references"

appendix D must be finished

appendix D: services limited to single interface - split WSDL 1.1
services into multiple WSDL 2 services

appendix D: transformed RPC style and removed encoded use - don't use
latter, transform schema for former



PART 3:

2.1: multiple cases of "??" lacking preceding closing double quote:
"xs:string??

2.2 "identifying a soap binding" (should be "THE soap binding"?)

2.6.2 should say {soap modules} is a set of SOAP Module components as
defined in 2.6.3.

Transition history

raised on 29 Sep 2004 by Jacek Kopecky (jacek.kopecky@deri.org)

agreed on 14 Apr 2004

Accept editor's resolution of the issue.

Acknowledgment cycle

announced by group on 29 Apr 2005

objection from reviewer on 12 May 2005

Some not done. More details forthcoming.

objection declined by group on 28 Jun 2005

Insufficient information provided to act on the objection.

Action history

LC52a: Last call review comments (a) [link to this issue]

PART 1:

2.1.1 "The components directly defined within a single Definitions
component are said to belong to the same target namespace."	-- what
about included components in the same namespace?

Transition history

raised on 29 Sep 2004 by Jacek Kopecky (jacek.kopecky@deri.org)

agreed on 27 Jan 2005

Adopt proposal in http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/0063.html.

Acknowledgment cycle

announced by group on 11 May 2005

Action history

LC52b: Last call review comments (b) [link to this issue]

PART 1:

2.5.1 how does {message content model} (in particular, #element) relate
to the use of other data models (3.2)? (text should probably be added
after properties bullet list that {message content model} is not present
in that case)

Transition history

raised on 29 Sep 2004 by Jacek Kopecky (jacek.kopecky@deri.org)

agreed on 3 Mar 2005

{message content model} is optional, missing when a different type system is in use. See also LC70.

Acknowledgment cycle

announced by group on 11 May 2005

Action history

LC52c: Last call review comments (c) [link to this issue]

PART 3:

2: rationale for not defaulting fault binding (at latest in 4th para)?
Is it just faultCodes not being defaultable? Should be mentioned in the
text.

Transition history

raised on 29 Sep 2004 by Jacek Kopecky (jacek.kopecky@deri.org)

agreed on 22 Apr 2005

Clarify that fault codes not being defaultable is indeed the reason.

Acknowledgment cycle

announced by group on 11 May 2005

Action history

LC53: Optional predefined features in Part 2 [link to this issue]

We took the decision on 8 July 2004[1] to adopt the AD proposal as an
optional feature.

However, the example in part 2[2] does not declare the use of the
http://www.w3.org/2004/08/wsdl/feature/AD feature, and it is basically
unclear reading the introduction to predefined features[4] or the
definition of the AD feature[5] whether:
- our predefined features (which is just the AD one at this point) are
	required or not; the only text which is related to this is: "The Web
	Services Description Working Group provides the following predefined
	features and SOAP modules for two reasons - we encourage
	implementors to support these features as we believe they offer
	important functionality"; we should probably add some text making it
	clear that they are optional.
- the use of an optional, predefined feature needs to be declared in a
	WSDL document before setting some of its properties.


	1. http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0109.html
	2. http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#adf-dp-desc
	4. http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#features
	5. http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#app-data

Transition history

raised on 29 Sep 2004 by Hugo Haas (hugo@w3.org)

Subsumed by issue(s) on 3 Mar 2005

See LC76d.

LC54: WSDL Last Call issue [link to this issue]

WSDL 2.0 does not have a mechanism for a WSDL receiver to determine if a
new interface that extends another interface is compatible or
incompatible with the original interface.

Proposed solution 

WSDL interface extends attribute is split to 2 attributes, extends and
imports.	A new interface that is compatible with another interface may
use the "extends" attribute. Compatibility means that a requesting agent
using the original interface can successfully use the derived interface
as if it were the original interface. The definition of "extends" is
along the lines of "lists the interfaces that this interface compatibly
derives from".	A new interface that is incompatible with another
interface must use the "imports" attribute. The definition of "imports"
is along the lines of "lists the interfaces that this interface uses but
are not compatible with". A new component property called "imported
interfaces" is introduced.

Transition history

raised on 29 Sep 2004 by David Orchard (dorchard@bea.com) and Roberto Chinnici (roberto.chinnici@sun.com)

declined on 22 Apr 2005

Closed with no action.

Acknowledgment cycle

announced by group on 12 May 2005

LC55: binding/operation/infault|outfault? [link to this issue]

In the LC version of Part 1 [1], <infault> and <outfault> element
information items are no longer listed among the children of the XML
representation of the Binding Operation component.

Is there a reason why they fell out? I can't find any reference to
changes to that area since the removal of
binding/operation/infault|outfault@messageReference in the 2004/12/04
teleconference minutes. [2]

What I would like to be able to do is specify a soap:module [3] in a
binding for an output fault message for specific operations.

[1] http://www.w3.org/TR/2004/WD-wsdl20-20040803/#Binding_Operation_XMLRep
[2] http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0017.html
[3] http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803/

Transition history

raised on 7 Sep 2004 by Bob Cunnings(cunnings@lectrosonics.com)

agreed on 18 Nov 2004

Roberto's proposal at {http://lists.w3.org/Archives/Public/www-ws-desc/2004Nov/0042.html} accepted, along with three amendments: a) Bring Message Reference Component into line with Roberto's proposal {http://lists.w3.org/Archives/Public/www-ws-desc/2004Nov/0045.html} b) Fix feature and property composition models to accomodate the new component. c) Clarify that QNames refer to interface fault.

Acknowledgment cycle

announced by group on 12 May 2005

agreement by reviewer on 12 May 2005

Action history

LC56: Clarification for binding fault [link to this issue]

Unlike interface faults, no binding operation level <infault> 
and <outfault> constructs are provided in the LC draft. I 
don't recall and can not trace discussion on the rationale for 
such in-symmetric desgin from the mail archival. Since Faults 
have been changed so many times, I would like to make sure we 
still have a common understanding about how it should work and 
that no problem are introduced here. 
		 
Without corresponding <infault>/<outfault> in the 
binding level, here is how I see it works:
		
1. How can one figure out which fault an binding operation uses?
 
This seems do-able without binding level <infault>/<outfault>. 
Since a binding operation refers to an interface operation, one 
should be able to get the fault message reference from the 
interface operation, and then look up the binding <fault> 
corresponding to the interface <fault> to figure out. 
It's do-able, but convoluted. 
		 
2. How can one specify a different fault code, soap module, and 
maybe custom binding extensions for infault and outfault of an 
binding operation?
		 
This is also do-able, but again cumbersome -	one has to define 
different interface <fault>s for infault and outfault even 
if they share a same fault message. 
		 
If this correctly reflects the group's thinking, I will add 
some text in the primer accordingly.

Transition history

raised on 30 Sep 2004 by Liu, Kevin (kevin.liu@sap.com)

agreed on 18 Nov 2004

Dupe of LC55. Roberto's proposal at {http://lists.w3.org/Archives/Public/www-ws-desc/2004Nov/0042.html} accepted, along with three amendments: a) Bring Message Reference Component into line with Roberto's proposal {http://lists.w3.org/Archives/Public/www-ws-desc/2004Nov/0045.html} b) Fix feature and property composition models to accomodate the new component. c) Clarify that QNames refer to interface fault.

Acknowledgment cycle

announced by group on 12 May 2005

LC57: typo in part 3 section 2.1 [link to this issue]

In the "note" following the example, it says:
		
The double question marks ("??") after the attributes in the whttp 
namespace indicates that those optional attributes only make sense 
if the when the SOAP binding uses HTTP as the underlying protocol, 
...
		
"if the" should be removed.
		
(Please ignore if already reported - I didn't find it in the LC 
issue list at a quick browser.)

Transition history

raised on 30 Sep 2004 by Liu, Kevin (kevin.liu@sap.com)

agreed on 27 Oct 2004

Fixed by editor.

Acknowledgment cycle

announced by group on 29 Oct 2004

Action history

LC58: typo in part 3, section 2.7.2 [link to this issue]

first bullet - s/operation/operations 
 
faults are reusable by multiple operations

(Please ignore if already reported - I didn't find it in the LC 
issue list at a quick browser.)

Transition history

raised on 30 Sep 2004 by Liu, Kevin (kevin.liu@sap.com)

agreed on 27 Oct 2004

Fixed by editor.

Acknowledgment cycle

announced by group on 29 Oct 2004

agreement by reviewer on 2 Nov 2004

Action history

LC59a: Bindings for 4 remaining MEPs [link to this issue]

We would like to see the Web Services Description Working Group define bindings for the 4 remaining MEPs for which no bindings have been defined or we would like them removed from the specification.

Transition history

raised on 5 Oct 2004 by Steve Ross-Talbot (steve@enigmatec.net) on behalf of WS Chor WG

declined on 11 Nov 2004

In-Optional-Out and Out-Optional-In will be marked at risk when entering CR and will be removed unless we see 2 interoperable implementations.

Acknowledgment cycle

announced by group on 11 May 2005

LC59b: Support attachments [link to this issue]

WSDL2.0 is unclear about it's support for attachment technologies and this is a concern to us. We would like to see some clarity with respect to what and how attachment technologies will be supported. We have spent some time looking at the WS-I AP1.0 profile as an exemplar and would greatly appreciate clarity on what you intend to support and how it might differ from AP1.0.

Transition history

raised on 5 Oct 2004 by Steve Ross-Talbot (steve@enigmatec.net) on behalf of WS Chor WG

declined on 11 Nov 2004

close with no change to spec. we will suport MTOM. SOAP1.1 binding is not part of our recommendation and support for SwA is not part of our plan.

Acknowledgment cycle

announced by group on 11 May 2005

LC59c: Differences between WSDL 1.1 and WSDL 2.0 [link to this issue]

We recommend that a section is added describing the differences between WSDL1.0 and WSDL2.0. This should include differences in MEP's between the two specifications.

Transition history

raised on 5 Oct 2004 by Steve Ross-Talbot (steve@enigmatec.net) on behalf of WS Chor WG

declined on 11 Nov 2004

we don't think it's necessary for the working group to work on it. Expect third party to chime in.

Acknowledgment cycle

announced by group on 11 May 2005

LC59d: Clarify wsdlLocation [link to this issue]

We seek clarification in the text of WSDL2.0 as to the use of wsdlLocation.

Transition history

raised on 5 Oct 2004 by Steve Ross-Talbot (steve@enigmatec.net) on behalf of WS Chor WG

agreed on 5 May 2005

Accepted proposal to add additional usage motivation.

Acknowledgment cycle

announced by group on 11 May 2005

Action history

LC59e: Clarify serialization [link to this issue]

We seek clarification in the text of WSDL 2.0 for component-to-XML InfoSet mapping, to address issues such as how serialization is performed in a manner compatible with XML Schema.

Transition history

raised on 5 Oct 2004 by Steve Ross-Talbot (steve@enigmatec.net) on behalf of WS Chor WG

declined on 22 Apr 2005

Close with no action, we have added constraints to the component model to ensure it can be serialized, we provide a mapping to XML which works both ways, and we don't see value in providing a canonical serialization.

Acknowledgment cycle

announced by group on 11 May 2005

LC59f: Support compositors [link to this issue]

We noted that the previous composistors work within WSD WG has not made it into the last call document, and similar to point 6, this is a capability that we need and would use if it were present.

Transition history

raised on 5 Oct 2004 by Steve Ross-Talbot (steve@enigmatec.net) on behalf of WS Chor WG

declined on 22 Apr 2005

We note your support, and will handle it procedurally.

Acknowledgment cycle

announced by group on 11 May 2005

LC60: Can multiple inline schemas have same targetNamespace? [link to this issue]

I would appreciate it if you could address the following issue that I have seen in WSDLs of 2 customers in the past month.

One vendor's SOAP stack is creating WSDLs with multiple inline schemas that have the same namespace.

Here's an example:
<wsdl:definition>
<wsdl:types>
<xs:schema targetNamespace="a">
types and elements
</xs:schema>
<xs:schema targetNamespace="a">
different types and elements
</xs:schema>
<xs:schema targetNamespace="b">
whatever
</xs:schema>
</wsdl:types>
...
<wsdl:definition> 

It's not clear to me whether the above is legal or not (two schemas with the same targetNamespace="a").  Should XML parsers for WSDL be smart enough to handle the above?  Or should parsers report errors?

Transition history

raised on 30 Sep 2004 by Jeehong Min (jeehongm@parasoft.com)

agreed on 27 Jan 2005

Add clarification that two inlined schemas from the same targetNS are OK. Note that we rely on schema processors to sort out a coherent set of schema components.

Acknowledgment cycle

announced by group on 13 May 2005

agreement by reviewer on 13 May 2005

Action history

LC61a: comments on the wsdl 2.0 working drafts (a) [link to this issue]

Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language

2.4.1.1 Operation Style

I think having the interface writer specify the applicable style on an 
interface or operation is a bad approach.  Is the interface writer aware 
of the possible styles that exist?  In addition the style is optional, so 
tools will still need to function in the absence of the style attribute. 
Furthermore, specifying the style of the interface blurs the line between 
interface and binding.  I think a better approach would involve supporting 
extensible interface/message structure constraints via the binding.  Using 
this approach, when the wsdl processor encountered a binding that 
referenced an interface it would utilize the constraints associated with 
the specific binding to validate interface.

Transition history

raised on 5 Oct 2004 by Craig Salter (csalter@ca.ibm.com)

agreed on 11 Nov 2004

Move all the styles and RPC signatures section to part 2. This address the perception concern, no change to the use of the styles.

Acknowledgment cycle

announced by group on 13 May 2005

Action history

LC61b: comments on the wsdl 2.0 working drafts (b) [link to this issue]

Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language

2.3 Interface Fault

Why are fault messages considered 'reusable' but input / output messages 
are not?  This seems inconsistent. A major improvement over WSDL 1.1 is 
the removal of the top level 'message' components.  From my experience 
there's little benefit to specifying 'named' messages.  If these do exist 
why are they specified within an interface?  IMHO the complexities 
introduced by named messages outweigh any convenience of reuse.

Transition history

raised on 5 Oct 2004 by Craig Salter (csalter@ca.ibm.com)

declined on 20 Jan 2005

Duplicate of 75a (which was rejected.)

Acknowledgment cycle

announced by group on 13 May 2005

LC61c: comments on the wsdl 2.0 working drafts (c) [link to this issue]

Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language

2.5.2 XML Representation of Message Reference Component

I don't see any use in the inclusion of a 'messageLabel' attribute.  Are 
there any examples where this is not redundant (deducible from the 
context)? I think the inclusion of optional attributes/elements in the 
spec that have no clear usefulness is terribly detrimental and one of the 
regrettable weaknesses of wsdl 1.1

Transition history

raised on 5 Oct 2004 by Craig Salter (csalter@ca.ibm.com)

declined on 22 Apr 2005

Close with no action - this attribute is for MEP extensibility purposes, which we will demonstrate in the primer.

Acknowledgment cycle

announced by group on 13 May 2005

LC61d: comments on the wsdl 2.0 working drafts (d) [link to this issue]

Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language

2.9.2 XML Representation of Binding Component

Seems odd that the binding lacks infault and outfault.  I'd assume that 
the structures should be symmetric?  These sort of mysterious differences 
make the spec feel clumsy.

Transition history

raised on 5 Oct 2004 by Craig Salter (csalter@ca.ibm.com)

agreed on 18 Nov 2004

Dupe of LC55. Roberto's proposal at {http://lists.w3.org/Archives/Public/www-ws-desc/2004Nov/0042.html} accepted, along with three amendments: a) Bring Message Reference Component into line with Roberto's proposal {http://lists.w3.org/Archives/Public/www-ws-desc/2004Nov/0045.html} b) Fix feature and property composition models to accomodate the new component. c) Clarify that QNames refer to interface fault.

Acknowledgment cycle

announced by group on 13 May 2005

LC61e: comments on the wsdl 2.0 working drafts (e) [link to this issue]

Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language

2.9 Binding

I'm struck the variety of places where we expect the wsdl author to 
specify binding related information.  An interface has a 'style' (though 
optional).  The binding has a 'type' then there are 'extensibility 
attributes' used to specify a soap protocol.  Then there are 
'extensibility elements' and of course this does not include possible use 
of 'features' and 'properties'.  IMHO there are too many mechanisms at 
play here.  I'd suggest returning to the simplicity of the wsdl 1.1 and 
its use of the extensibility element.  Here's a summary of the constructs 
I feel should be removed and how ...
 
The binding's type attribute.  This could be deduced by the namespace of 
the child extensibility element (e.g. wsdl 1.1).
The binding's style attribute.  Unneeded .... see comments above on 
2.4.1.1.
The binding's extensibility attributes.  Don't encourage their use.  Why 
not just utilize the attributes of the extensibility elements (e.g. wsdl 
1.1).

Transition history

raised on 5 Oct 2004 by Craig Salter (csalter@ca.ibm.com)

declined on 11 Nov 2004

Close with no action.

Acknowledgment cycle

announced by group on 13 May 2005

LC61f: comments on the wsdl 2.0 working drafts (f) [link to this issue]

Web Services Description Language (WSDL) Version 2.0 Part 3: Bindings

I don't see any description or examples of how to specify the content of a 
SOAP header?  Is the editor's copy incomplete ... I must confess I 
couldn't make much sense of it.  I think having examples included in the 
Primer would go a long way to making the design clearer.

Transition history

raised on 5 Oct 2004 by Craig Salter (csalter@ca.ibm.com)

Subsumed by issue(s) on 3 Mar 2005

Duplicate of LC76d.

LC62a: issues with wsdl:endpoint@address (a) [link to this issue]

Issue 1: the spec and the schema is inconsistent. 
 
In the spec, address is an "optional" attribute of endpoint
 
 <endpoint
          name="xs:NCName" 
          binding="xs:QName"
          address="xs:anyURI"? >
      <documentation />?
      [ <feature /> | <property /> ]*
    </endpoint>

The address attribute is not defined in the schema @ http://www.w3.org/2004/08/wsdl/ <http://www.w3.org/2004/08/wsdl/> 
 
<xs:complexType name="EndpointType" mixed="false"> 
 <http://www.w3.org/2004/08/wsdl/#> - <xs:complexContent>
 <http://www.w3.org/2004/08/wsdl/#> - <xs:extension base="wsdl:ExtensibleDocumentedType">
 <http://www.w3.org/2004/08/wsdl/#> - <xs:choice minOccurs="0" maxOccurs="unbounded">
  <xs:element name="feature" type="wsdl:FeatureType" /> 
  <xs:element name="property" type="wsdl:PropertyType" /> 
  <xs:any namespace="##other" processContents="lax" minOccurs="1" maxOccurs="1" /> 
  </xs:choice>
  <xs:attribute name="name" type="xs:NCName" use="required" /> 
  <xs:attribute name="binding" type="xs:QName" use="required" /> 
  </xs:extension>
  </xs:complexContent>
</xs:complexType>

Transition history

raised on 8 Oct 2004 by Liu, Kevin (kevin.liu@sap.com)

agreed on 22 Apr 2005

Optional on purpose. Close the issue 62a by fixing the schema. Editorial fix to clarify the specification why it is optional intentionally.

Acknowledgment cycle

announced by group on 13 May 2005

Action history

LC62b: issues with wsdl:endpoint@address (b) [link to this issue]

Issue2: why the address attribute is optional? The spec doesn't say anything about under what situation the address attribute may be left out. What's an endpoint without a network address?

Transition history

raised on 8 Oct 2004 by Liu, Kevin (kevin.liu@sap.com)

agreed on 28 Apr 2005

No further action, clarified in LC62a.

Acknowledgment cycle

announced by group on 13 May 2005

LC63: Mixing Schema Languages [link to this issue]

WSDL allows (unintentionally) users to mix components from different schema
languages for XML - say, DTD, XML Schema, Relax NG, etc. How? Via WSDL
import statements -
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#import-xsd,
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#import-xsd, and
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#relax

Example,

<definitions
 xmlns="http://www.w3.org/2004/08/wsdl"
 xmlns:xs="http://www.w3.org/2001/XMLSchema">
 xmlns:dtd="http://www.example.org/dtd">
 xmlns:rng="http://www.relaxng.org/ns/structure/1.0">

 <types>
  <xs:import namespace="uriA" schemaLocation="a.xsd"/> (XSD)
  <dtd:import namespace="uriB" location="b.dtd"/> (DTD)
  <rng:include namespace="uriC" href="c.rng"/> (RNG)
  <xs:schema targetNamespace="uriA">
   <!-- defs and declarations -->
  </xs:schema>
 </types>

<definitions>

At the component model level, these components map to Definitions.{element
declarations} and {type definitions} properties. We request you to say how
it works, or refer to a definition of how it works, or else to rule out
mixing schema languages.

Transition history

raised on 15 Oct 2004 by Asir Vedamuthu (asirv@webmethods.com) on behalf of the XML Schema WG.

Subsumed by issue(s) on 3 Mar 2005

See LC70.

LC64: URI References for Schema Components [link to this issue]

Appendix C, "This appendix provides a syntax for URI references for named
components found in a WSDL document. This includes the top level components:
interface, binding and service and the subordinate components: operation,
fault, and endpoint." -
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#wsdl-uri-references

Element declarations and type definitions are top level components in WSDL
definitions component, that is, Definitions.{element declarations} and {type
definitions}. What are the URI references for these schema components?

Transition history

raised on 15 Oct 2004 by Asir Vedamuthu (asirv@webmethods.com) on behalf of the XML Schema WG.

agreed on 19 May 2005

Accepted proposal, including "wsdl.description()", plus uri will be absent (not merely optional) for XML Schema, and the uri parameter will come second.

Acknowledgment cycle

announced by group on 28 May 2005

Action history

LC65: Editorial: imported schema vs. namespace [link to this issue]

Part 1 says: "The schema components defined in the imported schema are
available for reference by QName (see 2.18 QName resolution)." -
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#import-xsd

If you are really trying to clone xsd semantics, then this should say:

"The schema components defined in the imported >namespace< are available for
reference by QName (see 2.18 QName resolution). "

xs:import fundamentally brings into scope a namespace, not a schema. The
schemaLocation, if present, suggests a possible sort of definitions and
declarations that might be useful in building a schema, and only in that
sense is a schema imported.

Transition history

raised on 15 Oct 2004 by Asir Vedamuthu (asirv@webmethods.com) on behalf of the XML Schema WG

agreed on 14 Apr 2004

Accept editor's resolution of the issue.

Acknowledgment cycle

announced by group on 29 Apr 2005

Action history

LC66: Editorial: schema vs. schema document [link to this issue]

Part 1 says: "Embedding an XML schema uses the existing top-level xs:schema
element information item defined by XML Schema [XML Schema: Structures]. It
may be viewed as simply cutting and pasting an existing, stand-alone schema,
to a location inside the types element information item." -
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#embed-xsd

Should say:

"Embedding an XML schema uses the existing top-level xs:schema element
information item defined by XML Schema [XML Schema: Structures]. It may be
viewed as simply cutting and pasting an existing, >schema document<, to a
location inside the types element information item."

or if you prefer:

"Embedding an XML schema uses the existing top-level xs:schema element
information item defined by XML Schema [XML Schema: Structures]. It may be
viewed as simply cutting and pasting >an existing XML representation of
schema information<, to a location inside the types element information
item."

Note that the terms schema [.1] and schema document [.2] are rigorously
defined in the schema recommendation, and the term "XML Representation" is
widely and uniformly used; we request that these terms be used correctly.

[.1] http://www.w3.org/TR/2004/PER-xmlschema-1-20040318/#key-schema
[.2] http://www.w3.org/TR/2004/PER-xmlschema-1-20040318/#key-schemaDoc

Transition history

raised on 15 Oct 2004 by Asir Vedamuthu (asirv@webmethods.com) on behalf of the XML Schema WG

agreed on 14 Apr 2004

Accept editor's resolution of the issue.

Acknowledgment cycle

announced by group on 29 Apr 2005

Action history

LC67: Editorial: more .. schema vs. schema document [link to this issue]

Part 1 says: "The schema components defined in the embedded schema are
available to WSDL for reference by QName (see 2.18 QName resolution). Note
that only components defined in the schema itself and components included by
it via xs:include are available to WSDL. Specifically components that the
schema imports via xs:import are NOT available to WSDL." - -
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#embed-xsd

we think it should say:

"The schema components defined >and declared< in the embedded schema
>document< are available to WSDL for reference by QName (see 2.18 QName
resolution). Note that only components defined >and declared< in the schema
itself and components included by it via xs:include are available to WSDL.
Specifically components that the schema imports via xs:import are NOT
available to WSDL."

Transition history

raised on 15 Oct 2004 by Asir Vedamuthu (asirv@webmethods.com) on behalf of the XML Schema WG

agreed on 14 Apr 2004

Accept editor's resolution of the issue.

Acknowledgment cycle

announced by group on 29 Apr 2005

Action history

LC68: Editorial: missing antecedent [link to this issue]

"XML Schema MAY be used as the schema language via import or embedding. Each
method defines a different element information item for use within a types
element information item." -
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#xsd-types

The antecedent for the phrase 'each method' is missing. Also, what does it
mean?

Transition history

raised on 15 Oct 2004 by Asir Vedamuthu (asirv@webmethods.com) on behalf of the XML Schema WG

agreed on 14 Apr 2004

Accept editor's resolution of the issue.

Acknowledgment cycle

announced by group on 29 Apr 2005

Action history

LC69a: XForms comments on (WSDL) Version 2.0 Part 3: Bindings (a) [link to this issue]

In 3.8.1 Serialization as "application/x-www-form-urlencoded" it 
states that escaping MUST be defined as in XForms, so not much difference 
here. However, WSDL uses the ampersand (&) character as a separator 
between pairs of parameters. XForms allows the specification of either 
ampersand (&) or semi-colon (;) as the  separator with semi-colon being 
the default [2]. This choice was introduced following comments on the Last 
Call Draft published in January 2002. 

[2] http://www.w3.org/TR/xforms/slice3.html#structure-model-submission

Transition history

raised on 19 Oct 2004 by Roland Merrick (roland_merrick@uk.ibm.com) on behalf of the XForms WG.

agreed on 7 Apr 2005

Accept Hugo's proposal.

Acknowledgment cycle

announced by group on 11 May 2005

agreement by reviewer on 15 Jun 2005

Action history

LC69b: XForms comments on (WSDL) Version 2.0 Part 3: Bindings (b) [link to this issue]

WSDL 2.0 makes no mention of "multipart/related", we do not know if 
this is a problem but it is supported by XForms [3]

[3] http://www.w3.org/TR/xforms/slice11.html#serialize-multipart

Transition history

raised on 19 Oct 2004 by Roland Merrick (roland_merrick@uk.ibm.com) on behalf of the XForms WG.

declined on 14 Apr 2005

Accept rationale for taking no action.

Acknowledgment cycle

announced by group on 11 May 2005

agreement by reviewer on 15 Jun 2005

LC70: Pluggability of Schema Languages in WSDL [link to this issue]

It feels like there is an unclear break between WSDL and XML Schema.  It
seems obvious that the idea was to allow multiple schema languages for 
XML to be used within the context of WSDL, however we find several 
concerns over this.

1) The spec requires anything which understands WSDL to understand XML 
Schema.  This means that anything which could gain by being decoupled 
from XML Schema (IE platforms which do not have a schema processor) 
immediately takes that hit, because it has to support XML Schema. XML 
Schema has been reified into the Object Model for the Type System that 
WSDL uses, with loose words about how to deal with DTDs and Relax NG. 

Reference - "Note: Support for the W3C XML Schema Description Language
 is required of all processors." 
- http://www.w3.org/TR/2004/WD-wsdl20-20040803/#eii-types

2) This feels a bit like inventing how these two xml schema languages 
are used in WSDL rather than standardizing what has been done (see
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#dtd).  Having actual
implementations of a WSDL Generator and a WSDL Processor which actually 
use these and interoperate with each other should be a requirement 
before we include them in the final version of the spec.

3) We are still unclear on what should happen if more than one schema 
language is used. What if they say different things?

4) Overloading the use of the element AII for Message Reference 
Components, to refer components from different schema languages, seems
like a "bad thing"(tm).  If a WSDL processor only understands XML 
Schema, and it goes to retreive the element AII from a Message Reference, 
and it is not a QName that refers to a Schema component, it will cause 
confusion and delay. (Yes, Wes's son is a Thomas fan.)

To counter all of this we have two alternate proposals and one
requirement.

Proposal a) Break out XML Schema from the spec.  Introduce a schema
language "binding" (terribly overloaded term at the moment).  Describe 
in the Types section (part 1 section 3) the part of this binding that 
belongs here.  Describe in the Message Reference Component section 
(part 1 section 2.5) the part of this binding that belongs here.  
Say nothing about XML Schema in the spec.  Introduce an AII on the types
section which defines which schema language binding is in use, and state 
that a processor which does not understand the value of this AII must 
fault.  Have the wsdl processor fail if it does not understand the 
referenced schema language binding.  Introduce an adjunct to the spec 
defining the XML Schema schema language binding, making it optional.

Proposal b)  Drop RelaxNG and DTD from the spec and stay coupled to XML
Schema.

Requirement) WSDL WG should demonstrate that such schema languages within 
WSDL are implementable and there are at least two different interoperable
implementations of DTD and Relax NG type systems within WSDL.
Having actual implementations of a WSDL Generator and a
WSDL Processor which actually use these and interoperate with each 
other should be a requirement before we include them in the final 
version of the spec. If proposal A is adopted or status quo prevails, 
please record this as one of the CR exit criteria.

2005-02-24: WG agreed to move DTD and RelaxNG from the spec and publish as a note

Transition history

raised on 20 Oct 2004 by Wes Moulder(wes@webmethods.com)

agreed on 3 Mar 2005

2005-02-24 Agreed to move this material into a separate note.

Clarify in sec 2.1.3 and elsewhere that there is only a single element declaration in the set for each QName. Add text along the lines suggested by David - "include a note in the spec saying that if someone combines multiple schema languages may be a problem, and we have not solved this problem."

Acknowledgment cycle

announced by group on 28 May 2005

Action history

LC71: default interface/operation/@pattern [link to this issue]

We would like to see the "pattern" attribute of "operation" elements
defaulted based on the contained <input> and <output> elements for
those patterns where that is unambiguously possible. The component 
model will continue to have the current behavior - this is only
a syntactic convenience.

Requiring all users to remember the values of the pattern URIs 
when the value is patently obvious from the <input> and/or
<output> elements makes the language overly cumbersome with 
no value. We would like this extra complexity removed.

Note that this is only a default - if someone else were to define
a pattern with only one <input> and no <output>s then they can
still live happily with the user explicitly setting the value.

Transition history

raised on 27 Oct 2004 by Sanjiva Weerawarana (sanjiva@watson.ibm.com)

agreed on 31 May 2005

Make pattern default to in-out.

Acknowledgment cycle

announced by group on 9 Jun 2005

Action history

LC72: Faults that are not described in WSDL? [link to this issue]

Part 1 section 2.3.1 says "Note that faults other than the ones
described in the Interface component can also be generated at run-time,
i.e. faults are an open set.".

I think this needs clarification.  How can a client application or Web
service know what additional faults to expect, and what message schemas
would describe such faults?

Transition history

raised on 28 Oct 2004 by David Booth (dbooth@w3.org)

declined on 22 Apr 2005

By Design. Close with no action.

Acknowledgment cycle

announced by group on 20 May 2005

proposal from reviewer on 2 Jun 2005

proposal declined by group on 25 Jul 2005

WG did not feel it needed to add text characterizing (possibly wrongly) undeclared faults.

LC73: Raising an ugly issue again [link to this issue]

I apologize in advance for raising this ugly issue again. Perhaps I just
don't understand the model well enough, and maybe you can explain it to me,
but I'm really concerned about the "one interface per service" constraint.

The SOA architecture requires that a web service expose multiple interfaces:
- its functional interface
- a management interface (WSDM, WS-Management, etc)
- a metadata discovery interface (WS-MetadataExchange, etc)
- an interactive interface (WSRP, etc)
- potentially others

I have clients that also require that a web service support versioning, in
which case the service will expose multiple versions of its functional
interface. 

How does WSDL 2.0 support these basic SOA requirements if a service
definition is constrained such that it implements at most one interface?

Transition history

raised on 28 Oct 2004 by Anne Thomas Manes (anne@manes.net)

declined on 19 Jan 2005

Insufficient interest in reopening the issue. Closed with no action.

Acknowledgment cycle

announced by group on 20 May 2005

objection from reviewer on 21 May 2005

objection maintained by group on 6 Jul 2005

Agree to disagree.

Action history

LC74: Idle question [link to this issue]

So, can a WSDL 2.0 document import or include a WSDL 1.1 document?
						
Presumably, 1.1 cannot import 2.0.

Transition history

raised on 26 Oct 2004 by Amelia A Lewis (alewis@tibco.com)

agreed on 21 Apr 2005

Add "2.0" appropriately in the document.

Acknowledgment cycle

announced by group on 20 May 2005

Action history

LC74a: I18N Comments, WSDL 2.0 Part I (partial) (a) [link to this issue]

Section 2.1. In the following quote, the reference to URI 
should explicitly include IRIs (as the type xs:anyURI allows for these). 
In fact, there should be some care taken to clarify that URIs in this document 
mean IRIs, if possible:

<quote>
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.
</quote>

Partial resolution: Change URI to IRI throughout except URI attr and prop on featiures and properties and SOAP module, which becomes "ref"; exempt appendix E where we talk about namespace URIs, and section 4.11.2 in adjunct spec.

Transition history

raised on 5 Nov 2004 by Addison Phillips[wM] (aphillips@webmethods.com)

agreed on 26 May 2005

In addition to the above partial resolutions, we also accept Hugo'sproposal.

Acknowledgment cycle

announced by group on 9 Jun 2005

Action history

LC74b: I18N Comments, WSDL 2.0 Part I (partial) (b) [link to this issue]

Section 2.1. Name uniqueness. While QName's definition 
provides for uniqueness in an internationalized way, it may be useful to 
reference what makes a name unique in this document. In particular, there 
is a gap that surrounds QName in that, although it is based on NCName and 
thus is "include normalized" according to the rules in CharMod:Normaliation, 
there is no requirement that the name itself be in a normalized form (i.e.
Unicode Normalization Form C, which is recommended by but not required by 
XML 1.0/1.1) Some consideration for matching QNames should be made. This 
is a low-priority comment, since other groups are struggling with this 
issue (unsuccessfully).

<quote>
Each WSDL or type system component MUST be uniquely identified by its qualified name.
</quote>

Transition history

raised on 5 Nov 2004 by Addison Phillips[wM] (aphillips@webmethods.com)

declined on 28 Apr 2005

Closed with no action. Insufficient interest in WG to solve this problem. Largely orthogonal to WSDL core concepts.

Acknowledgment cycle

announced by group on 9 Jun 2005

LC74c: I18N Comments, WSDL 2.0 Part I (partial) (c) [link to this issue]

Section 2.1.2, Section 5.0. The <documentation> element presents
a number of internationalization concerns to us. Here is some of the 
text of Section 5:

<quote>
WSDL uses the optional documentation element information item as a 
container for human readable and/or machine processable documentation.
The content of the element information item is arbitrary character 
information items and element information items ("mixed" content in
XML Schema[XML Schema: Structures]). The documentation element 
information item is allowed inside any WSDL element information item.
</quote>

The problem here is that the documentation is supposed to describe, 
either in plain-text or in markup, aspects of the WSDL for documentation 
purposes. Human readable text has two problems here. First, it need
to be tagged with the natural language (by referencing xml:lang, 
xsi:language, or by directly referencing RFC 3066 or its successors)
and second, it may need to be repeated in different languages 
(which may be but are not necessarily translations). 

We suggest that:

a) The <documentation> element require an xml:lang attribute. 
   The attribute may be empty (xml:lang="")
b) The <documentation> element be allowed to be repeated, 
   provided the xml:lang attributes in each of the elements be unique.

You may wish to reference the <documentation> element (under 
annotations) in XMLSchema, although it is not as clear about the above 
as we would probably like :-).

Transition history

raised on 5 Nov 2004 by Addison Phillips[wM] (aphillips@webmethods.com)

agreed on 1 Jun 2005

Change the recurrence of wsdl:documented in DocumentedType to *, add attribute extensibility DocumentationType, let usage of multiple documentation elements be determined in practice, add text to suggest using xml:lang.

Acknowledgment cycle

announced by group on 9 Jun 2005

Action history

LC74d: I18N Comments, WSDL 2.0 Part I (partial) (d) [link to this issue]

Section 2.4.2. RPC Style. There is a requirement on the 
local part of the output element name that says:

<quote>
The LocalPart of the output element's QName is obtained by concatenating 
the name of the operation and the string value "Response".
</quote>

We understand that this is historically the way that it has been done and 
that some implementations, at least, rely on this. However, while it seems
reasonable at first glance that, say, for operation "foobar", the response
is called "foobarResponse", it may be less helpful in cases where the 
original operation name is non-ASCII in nature. It isn't clear why the 
name needs to be quite so determinate (and thus a concatenated construct)
in the first place. Is there some reason why the return message needs
a name based on the request message's plus some English ("Programmer-ese")
token? Since in the RPC style the "out" message is presumably the
response, can this requirement be relaxed?

Transition history

raised on 5 Nov 2004 by Addison Phillips[wM] (aphillips@webmethods.com)

agreed on 11 Nov 2004

Drop "The LocalPart of the output element's QName is obtained by concatenating the name of the operation and the string value "Response"" from RPC style"

Acknowledgment cycle

announced by group on 9 Jun 2005

Action history

LC74e: I18N Comments, WSDL 2.0 Part I (partial) (e) [link to this issue]

Section 2.15. Simple Types. This section gave us a great deal of concern. In this section WSDL defines seven simple types used in the component model of WSDL 2.0. These types are: string, Token, NCName, anyURI, QName, boolean and int. The argument presented in this section is that these needed to be redefined because "the types defined here go beyond the capabilities of XML Schema to describe."

We are not sure why you consider this to be the case (our suspicion is that it is to ensure XML 1.1 compatibility). However, the definitions presented here are much less mature than those in XML Schema for internationalization purposes. We would strongly urge you to reconsider and use the XML Schema definitions directly. If there is a good reason not to use XML Schema directly, then we urge you to import, fully, the definitions in XML Schema for each of these types. A cursory review of our issues with the types you define are:

5a. string. The definition includes all code points between U+0000 and U+10FFFF. It doesn't deal with illegal characters in XML, such as surrogates, unassigned, or non-characters (like U+FFFF or U+10FFFF). XML 1.0 and XML 1.1 define various productions that can be used to avoid this problem, but we don't see why you don't just use the definition found in http://www.w3.org/TR/xmlschema-2/#string

5b. Token. This definition is similar to the one in XML Schema, but leaves out the prohibition on character #0xD. It is not usefully different than the one in XML Schema.

QName, NCName. The NCName and QName definitions say more-or-less what they are, but the productions cited in XML Schema (Namespaces in XML, http://www.w3.org/TR/1999/REC-xml-names-19990114/) should be explicitly cited.

5c. anyURI. This implicitly disallows IRIs. You should include the text from the second and subsequent paragraphs in XML Schema's defintion. In particular, anyURI in XML Schema represents the *unescaped* sequence (it is, effectively, an IRI).

5d. int. This is problematic on two fronts. First, it is different from the "int" type in XML Schema (it is very similar to the "integer" type: "int" in XML Schema is derived from "long", which is derived from "integer" and has a maximum and minimum value corresponding to an integer type of a specific size). Second, you don't define the lexical representation, which may present problems for internationalization. One presumes that the lexical description is the same...

Transition history

raised on 5 Nov 2004 by Addison Phillips[wM] (aphillips@webmethods.com)

Subsumed by issue(s) on 20 Jan 2005

We are removing these definitions, reverting to describing our component model in terms of the XML Schema 1.0 datatypes. This means new XML 1.1 features will not be directly usable within WSDL until the XML Schema WG sorts out how to deal with them.

LC74f: I18N Comments, WSDL 2.0 Part I (partial) (f) [link to this issue]

Section 1.1. (non-i18n) The various terms defined in this section should be made into glossary references, since these are the Ur-definitions used in WSDL.

Transition history

raised on 5 Nov 2004 by Addison Phillips[wM] (aphillips@webmethods.com)

declined on 11 Nov 2004

close with no change to spec. We don't have a glossary. If unhappy with a particular definition, let us know.

Acknowledgment cycle

announced by group on 9 Jun 2005

LC74g: I18N Comments, WSDL 2.0 Part I (partial) (g) [link to this issue]

Section 2.0 (editorial) Capitalization of 'schema' in last paragraph of this section.

Transition history

raised on 5 Nov 2004 by Addison Phillips[wM] (aphillips@webmethods.com)

agreed on 5 May 2005

Accept editor's resolution.

Acknowledgment cycle

announced by group on 9 Jun 2005

Action history

LC75a: Faults and Messages should be similar (same level, etc.) [link to this issue]

Section 2.3: Fault declarations should be moved down into
interface/operation, and not be defined as first-class components of
interface.  Fault references ought to work as message references do:

* The following argument from Section 2.3.1 applies equally well to
messages.  Why aren't they treated consistently?  "The Interface Fault
component provides a clear mechanism to name and describe the set of
faults an interface may generate.  This allows operations to easily
identify the individual faults they may generate by name.  This
mechanism allows the ready identification of the same fault occurring
across multiple operations and referenced in multiple bindings as well
as reducing duplication of description for an individual fault."

* Interface Fault Components are not globally reusable.  The solution is
half-baked.

* Interface Fault Components do not provide any practical re-use.  The
99% case just renames @element.

* Interface Fault Components are awkward because they cannot be bound
within the context of an operation, preventing, for example, the
assignment of a different reason string to the 'same' fault within
different operations.  Making these 'error messages' clear for debugging
scenarios will require creating Interface Fault Components that are
otherwise identical.

* It would be much cleaner if the Interface Operation and Binding
Operation components had parallel properties.  As it is, only one has
{fault references}.

Transition history

raised on 9 Nov 2004 by Jeffrey Schlimmer (jeffsch@windows.microsoft.com)

declined on 10 Nov 2004

Unable to reach consensus to adopt the proposal. Closed without action. See rationale.

Acknowledgment cycle

announced by group on 20 May 2005

agreement by reviewer on 27 May 2005

LC75b: Referencing faults by QName (editorial) [link to this issue]

Section 2.3.1 states: "Interface Fault components are local to Interface
components; they cannot be referred to by QName..."  However, Section
2.6.3 states that "{fault reference}" is "the actual value of the ref
attribute information item", an xs:QName.  Please make this consistent
here and for the other components throughout the document which have
this inconsistency.

Transition history

raised on 9 Nov 2004 by Jeffrey Schlimmer (jeffsch@windows.microsoft.com)

agreed on 5 May 2005

Accept editor's resolution.

Acknowledgment cycle

announced by group on 20 May 2005

agreement by reviewer on 27 May 2005

Action history

LC75c: Remove {safety} property [link to this issue]

Section 2.4.1 defines a {safety} property and a corresponding safe
attribute.  These constructs should be removed.  Tooling can't analyze
developer code for the purpose of automatically setting the safe
attribute, so by default "safety" will be set to false.  We expect
developers to have little incentive to set the safety property manually,
and even when they do we are not convinced they will be able to do so
correctly.  In addition it's not clear why safety is singled out as the
only semantic declaration worthy of inclusion in the WSDL core.

Transition history

raised on 9 Nov 2004 by Jeffrey Schlimmer (jeffsch@windows.microsoft.com)

agreed on 1 Jun 2005

put safety in its own namespace, modify the HTTP binding defaulting rules to say that if no method is specified and the @ext:safety attribute is used in the operation, then the method is GET.

Acknowledgment cycle

announced by group on 9 Jun 2005

Action history

LC75d: Require explicit type for each input/output? [link to this issue]

Section 2.4.2 states: "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 type."  Does this imply that an explicit type
must be declared for all child elements?  If so it should be stated
explicitly.

Transition history

raised on 9 Nov 2004 by Jeffrey Schlimmer (jeffsch@windows.microsoft.com)

agreed on 22 Apr 2005

Change "same type" to "same named type".

Acknowledgment cycle

announced by group on 20 May 2005

agreement by reviewer on 27 May 2005

Action history

LC75e: Move RPC style to Part 2 [link to this issue]

Section 2.4.2 RPC Style defines an extension for use in the {style}
property (see section 2.4.1.1).  As an extension this should be moved to
Part 2.

Transition history

raised on 9 Nov 2004 by Jeffrey Schlimmer (jeffsch@windows.microsoft.com)

agreed on 4 Mar 2005

Duplicate of LC21.

Acknowledgment cycle

announced by group on 20 May 2005

agreement by reviewer on 27 May 2005

LC75f: Allow extension attributes on RPC local element children [link to this issue]

Section 2.4.2 RPC Style is unclear as to whether local element children
may contain extension attributes.  Such attributes should be explicitly
allowed; for instance as identifiers to enable the element to be signed
(xml:id, wsu:Id).

Transition history

raised on 9 Nov 2004 by Jeffrey Schlimmer (jeffsch@windows.microsoft.com)

declined on 22 Apr 2005

The spec does not preclude extension attributes. We don't list things that are unconstrained by the RPC style. Close with no change.

Acknowledgment cycle

announced by group on 20 May 2005

objection from reviewer on 27 May 2005

objection accepted by group on 25 Jul 2005

Agreed to change spec as commenter desired.

LC75g: RPC should allow element wildcards [link to this issue]

Section 2.4.2 RPC Style does not appear to allow element wildcards.
Such wildcards are necessary to enable versioning.

Transition history

raised on 9 Nov 2004 by Jeffrey Schlimmer (jeffsch@windows.microsoft.com)

agreed on 22 Apr 2005

Proposal accepted.

Acknowledgment cycle

announced by group on 20 May 2005

agreement by reviewer on 27 May 2005

Action history

LC75h: Disallow multiple returns in RPC [link to this issue]

Section 2.4.2.1 allows multiple returns.  Why?  Is the expectation that
one would generate an (anonymous?) struct to hold the result?  We'd
prefer that the signature was restricted to a single return.

Transition history

raised on 9 Nov 2004 by Jeffrey Schlimmer (jeffsch@windows.microsoft.com)

declined on 4 Mar 2005

WG felt that many popular languages support multiple return values, and the burden on languages that don't is small.

Acknowledgment cycle

announced by group on 20 May 2005

agreement by reviewer on 27 May 2005

Action history

LC75i: Disallow only <infault>, <outfault> [link to this issue]

Section 2.4.3 states: "At least one of the [children] MUST be an input,
output, infault, or outfault element information item."  Allowing an
operation to only have an infault or outfault child doesn't make sense.
Suggest removing infault and outfault from this list.

Transition history

raised on 9 Nov 2004 by Jeffrey Schlimmer (jeffsch@windows.microsoft.com)

agreed on 20 Jan 2005

Agree to remove "infault" and "outfault" from this list.

Acknowledgment cycle

announced by group on 20 May 2005

agreement by reviewer on 27 May 2005

Action history

LC75j: {safety} has a default, @safety doesn't [link to this issue]

Section 2.4.3.3 says that the safe attribute has no default value, yet
Table 2-5 says the {safety} property does.  While this is not in direct
conflict, it could be clearer that the first case is talking about an
attribute default, and the second is not really a default at all, but a
guaranteed result of the transformation from Infoset to the Component
Model.  There may be similar occurrences of the word "default" in
relation to the component model elsewhere in the spec.

Transition history

raised on 9 Nov 2004 by Jeffrey Schlimmer (jeffsch@windows.microsoft.com)

agreed on 26 May 2005

This has been addressed under LC97.

Acknowledgment cycle

announced by group on 28 May 2005

LC75k: Allow multiple children in soap:body [link to this issue]

Section 2.5.1 Message Reference Component allows message content models
to consist of any single element, any named element, or none.  The
restriction of messages to a single element child is not derived from
SOAP 1.1 or SOAP 1.2.  Multiple element children is a type of message
exchange currently in use.  (Microsoft supports this in ASMX.)  We
request the facility to specify a sequence of named or unnamed elements
to enable WSDL to be used to describe such message exchanges.

Transition history

raised on 9 Nov 2004 by Jeffrey Schlimmer (jeffsch@windows.microsoft.com)

declined on 20 Jan 2005

We note that this can be done by extending the binding, industry trend away from a single child makes us reluctant to support it at this time in our development.

Acknowledgment cycle

announced by group on 20 May 2005

agreement by reviewer on 27 May 2005

LC75l: Make messageLabel mismatch an error [link to this issue]

Table 2-6 and Table 2-7 specify that an error results if the
messageLabel attribute doesn't match the MEP.  However Table 2-13
suggests it's not an error if the messageLabel attribute doesn't match
the MEP.  It's not clear whether there is a reason for these to be
inconsistent.  Please make it an error throughout the spec if the
messageLabel does not match the MEP.

Transition history

raised on 9 Nov 2004 by Jeffrey Schlimmer (jeffsch@windows.microsoft.com)

agreed on 20 Jan 2005

Make the message label property of the binding message reference component required AND substitute an error for empty in the text in the message label mapping in table 2-13.

Acknowledgment cycle

announced by group on 20 May 2005

agreement by reviewer on 27 May 2005

Action history

LC75m: Inconsistent value for {operation reference} [link to this issue]

Table 2-12 says the {operation reference} is the actual value of the ref
attribute.  However, the {operation reference} property is earlier
defined (2.11.1) to be an Interface Operation Component.  Furthermore
Section 2.4.1 states that Interface Operation Components cannot be
referred to unambiguously by QName, which is not reflected in the
mapping in Table 2-12.  Please make these sections consistent.

Transition history

raised on 9 Nov 2004 by Jeffrey Schlimmer (jeffsch@windows.microsoft.com)

agreed on 22 Apr 2005

Editors to fix.

Acknowledgment cycle

announced by group on 20 May 2005

agreement by reviewer on 27 May 2005

Action history

LC75n: Allow multiple interfaces per service [link to this issue]

Section 2.13: Service Components implement a single interface.  This
change from WSDL 1.1 impacts tooling negatively.  Tooling exists for
WSDL 1.1 that serializes a single service element with ports bound to
more than one portType.  There may also be tooling that serializes
multiple service elements to separate ports on some basis other than
whether they implement the same portType.  A service serializing its
description as multiple service elements (as this change requires)
forces it and its client implementations to add an additional layer of
identification to equate the service element QNames.

Transition history

raised on 9 Nov 2004 by Jeffrey Schlimmer (jeffsch@windows.microsoft.com)

declined on 19 Jan 2005

Insufficient interest in reopening the issue. Closed with no action.

Acknowledgment cycle

announced by group on 20 May 2005

agreement by reviewer on 27 May 2005

LC75o: Remove "if any" from Table 2-13 [link to this issue]

Table 2-13 implies there may not be any endpoints in a service (it says
"if any").  However Section 2.13.2 states that there are always "one or
more endpoint[s]".  The "if any" thus appears to be in error and should
be removed.

Transition history

raised on 9 Nov 2004 by Jeffrey Schlimmer (jeffsch@windows.microsoft.com)

agreed on 5 May 2005

Remove "if any".

Acknowledgment cycle

announced by group on 20 May 2005

agreement by reviewer on 27 May 2005

Action history

LC75p: Make address a binding-specific extension [link to this issue]

Section 2.14 builds the address into the WSDL core rather than
expressing it through a binding-specific extension (as in WSDL 1.1).
This also constrains address to a URI.  We expect bindings that require
alternate forms of address (e.g., WS-Addressing Endpoint Reference).

Transition history

raised on 9 Nov 2004 by Jeffrey Schlimmer (jeffsch@windows.microsoft.com)

declined on 22 Apr 2005

In LC62b we clarified that address is optional and can be extended. It is still useful to provide a common location to notate addresses for bindings that take a single URI.

Acknowledgment cycle

announced by group on 20 May 2005

agreement by reviewer on 27 May 2005

LC75q: Disallow XML 1.1 [link to this issue]

Section 2.15: Support for versions of XML other than XML 1.0 complicates
the spec substantially without providing corresponding benefits in
interoperability.  Until a version of XML Schema that provides
facilities for handling XML 1.1 is developed and deployed there is
little real utility in building support for XML 1.1 into WSDL.  The
introduction of new simple types for schema in section 2.15 should be
removed completely, and references to these types should revert to the
corresponding XML Schema 1.0 types.  Section 2 can likewise be greatly
simplified.

Transition history

raised on 9 Nov 2004 by Jeffrey Schlimmer (jeffsch@windows.microsoft.com)

agreed on 20 Jan 2005

We will removing these definitions, reverting to describing our component model in terms of the XML Schema 1.0 datatypes. This means new XML 1.1 features will not be directly usable within WSDL until the XML Schema WG sorts out how to deal with them.

Acknowledgment cycle

announced by group on 20 May 2005

agreement by reviewer on 27 May 2005

Action history

LC75r: Remove conformance requirement on XML Schema [link to this issue]

Section 3 states: "Note: Support for the W3C XML Schema Description
Language [XML Schema: Structures],[XML Schema: Datatypes] is required of
all processors."  We consider it sufficient to just say what it means
when XML Schema is used, and whether it was used correctly.

Transition history

raised on 9 Nov 2004 by Jeffrey Schlimmer (jeffsch@windows.microsoft.com)

agreed on 3 Mar 2005

See resolution of LC5f.

Acknowledgment cycle

announced by group on 20 May 2005

agreement by reviewer on 27 May 2005

LC75s: Add table showing which schema components are visible to WSDL [link to this issue]

Section 3.1 and 3.2 describe rather intricate rules for which schema
components are visible to the WSDL.  A table or diagram would help
greatly in communicating this information.

Transition history

raised on 9 Nov 2004 by Jeffrey Schlimmer (jeffsch@windows.microsoft.com)

agreed on 27 Jan 2005

Agreed to add a table with rows "import", "include" and columns "directly in WSDL", "in schema".

Acknowledgment cycle

announced by group on 20 May 2005

agreement by reviewer on 27 May 2005

Action history

LC75t: Make wsdl:include transitive [link to this issue]

Section 4.1 describes wsdl:include as non-transitive, that is, you can't
refer to components in an included document that have themselves been
included.  This is inconsistent with xs:include, as well as restricting
the options available for modularization of WSDL files.  Please remove
the restriction making wsdl:include non-transitive.  (Note that
wsdl:import should remain explicitly non-transitive, just as xs:import
is.)

Transition history

raised on 9 Nov 2004 by Jeffrey Schlimmer (jeffsch@windows.microsoft.com)

agreed on 3 Feb 2005

Agree the difference in transitivity is a mistake. Accept proposed resolution in http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/0059.html. Also see LC92.

Acknowledgment cycle

announced by group on 20 May 2005

agreement by reviewer on 27 May 2005

Action history

LC75u: Add wsdl:documentation to the component model [link to this issue]

Section 5: The wsdl:documentation element is not mapped into the WSDL
Component model.  This relegates information embedded there to the same
status as an XML comment.  If the wsdl:documentation element provides no
semantic difference than an XML comment, we request that it be removed.
But we prefer that the contents of the wsdl:documentation element be
reflected in the Component model by adding a new property to each
component (e.g., {documentation}) whose value is the XML Element
Information Item of the wsdl:documentation element.  This provides
access to the contents of the documentation element, but also to
annotations (specifically xml:lang) specified on that element.

Transition history

raised on 9 Nov 2004 by Jeffrey Schlimmer (jeffsch@windows.microsoft.com)

declined on 31 Mar 2005

Closed with no action. Documentation at the component model complicates calculation of component equivalence. Component model is not sufficient for complete round-tripping (e.g. XML comments are not implemented).

Acknowledgment cycle

announced by group on 20 May 2005

agreement by reviewer on 27 May 2005

LC75v: Remove "Processor Conformance" [link to this issue]

Section 8.3 on Processor Conformance is untestable (unlike Section 8.1).
Document conformance is adequate for a specification that defines
metadata rather than runtime processing.  Remove section 8.3.

Transition history

raised on 9 Nov 2004 by Jeffrey Schlimmer (jeffsch@windows.microsoft.com)

agreed on 3 Mar 2005

See resolution of LC5f.

Acknowledgment cycle

announced by group on 20 May 2005

objection from reviewer on 27 May 2005

objection accepted by group on 9 Jul 2005

Fixed remaining problems.

LC75w: Allow non-dereferencable includes [link to this issue]

Section 8.3 states: "A conformant WSDL processor MUST fail if it
processes an element containing a wsdl:include statement having a URI
that is not dereferenceable to a legal WSDL document."  What if it
already happens to have a copy of the to-be-included (or to be imported)
WSDL?  The value of requiring a failure in this case is unclear, and
we'd like this restriction to be relaxed.

Transition history

raised on 9 Nov 2004 by Jeffrey Schlimmer (jeffsch@windows.microsoft.com)

agreed on 21 Apr 2005

Remove "is not dereferenceable or" from 4.1.1

Acknowledgment cycle

announced by group on 20 May 2005

agreement by reviewer on 27 May 2005

Action history

LC75x: Complete or remove App D [link to this issue]

Appendix D is incomplete and therefore misleading about the amount of
change required to migrate from WSDL 2.0 to 1.1.  Please complete this
section.

Transition history

raised on 9 Nov 2004 by Jeffrey Schlimmer (jeffsch@windows.microsoft.com)

agreed on 1 Jun 2005

Remove Appendix D

Acknowledgment cycle

announced by group on 9 Jun 2005

Action history

LC76a: MEPs should support addressing mechanism [link to this issue]

Section 2.1.1 Fault Replaces Message and 2.1.2 Message Triggers Fault
don't allow a fault to go to an alternate location in the case where a
wsa:FaultTo [WS-Addressing] header is specified.  Generalize these rules
so that addressing mechanisms can be accommodated without defining new
MEPs.

Transition history

raised on 9 Nov 2004 by Jeffrey Schlimmer (jeffsch@windows.microsoft.com)

agreed on 22 Apr 2005

Close LC76a by adding a clause to the fault rule set that says the destination of the fault may be modified by a binding or extension and to cite WSA as an informative example.

Acknowledgment cycle

announced by group on 20 May 2005

objection from reviewer on 27 May 2005

objection accepted by group on 9 Jul 2005

Adopted consistent descriptions.

Action history

LC76b: Define "propagate" [link to this issue]

Section 2.1.2: What does the term "propagate" mean in the context of
sending a fault? Please clarify.

Transition history

raised on 9 Nov 2004 by Jeffrey Schlimmer (jeffsch@windows.microsoft.com)

agreed on 12 May 2005

Define propagage as: "a best-effort attempt to transmit the fault message to its designated recipient."

Acknowledgment cycle

announced by group on 20 May 2005

agreement by reviewer on 27 May 2005

LC76c: WSDL 2.0 LC Comments (Part 2) (c) [link to this issue]

Section 2.1.1 and 2.1.2 say that the fault message must be delivered.
This implies that the endpoint does not have the option to generate but
not send the fault.  While always useful for debugging, faults are
sometimes logged but not sent to prevent information disclosure and
denial of service attacks.  SOAP 1.2 allows this.

Transition history

raised on 9 Nov 2004 by Jeffrey Schlimmer (jeffsch@windows.microsoft.com)

agreed on 9 Dec 2004

Proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2004Nov/0054.html accepted.

Acknowledgment cycle

announced by group on 20 May 2005

objection from reviewer on 27 May 2005

objection accepted by group on 25 Jul 2005

Added to text to satisfy commenter.

Action history

LC76d: Replace ADD with header construct [link to this issue]

Section 3.1: The Application Data Feature should be replaced by a
construct similar to the SOAP header binding extension in WSDL 1.1:

* The intended semantic of the AD property URI suggests an architectural
commitment beyond any required by SOAP -- application versus some other
processing layer?  Such distinctions are premature at this point in Web
service development and have unclear implications on interoperability.

* Wrapping the name of the XML Schema element for a header block with
two elements and two attributes provides little additional information,
sacrifices readability, and introduces opportunities for errors in WSDL
generation and parsing.

* The dataHeaders header block introduces descriptive markup in SOAP
messages.  Description languages should not introduce significant markup
in the instances they describe.

* The dataHeaders header block implies that endpoints will not be able
to successfully exchange messages unless they agree on a WSDL 2.0
description.  XML Schema does not impose this restriction on the use of
XML.  WSDL 1.1 does not impose this restriction on SOAP messages.  WSDL
2.0 should not impose this restriction either.

* The rules for when to include the dataHeaders block and what to
include in it are underspecified.

* While both the SOAP Module and the missing SOAP header construct
declare a name for a header block (the former a URI and the latter a
URI:local name pair), SOAP Module does not provide a structural
description of the header block (e.g., an XML Schema element).  This
precludes tooling and intermediaries from serializing, deserializing,
and/or validating the header without external header-specific knowledge.
Such processing has proved useful for the SOAP Body and should be
enabled for SOAP headers too.

* The declaration of SOAP 1.1 and 1.2 headers in WSDL is currently in
use.  (Microsoft supports this in ASMX.)  We expect this useful practice
to continue going forward.

Transition history

raised on 9 Nov 2004 by Jeffrey Schlimmer (jeffsch@windows.microsoft.com)

agreed on 3 Mar 2005

Accept proposal with the following amendments:

• syntax will be <wsoap:header element="..." mustUnderstand="xs:Boolean" wsdl:required="xs:boolean"/>*
• goes into part 3 and AD feature will be removed from Part 2
• similar HTTP functionality will be added: <whttp:header element="..." wsdl:required="xs:boolean"/>*
• clarify that the whttp:header elements are avaiable to use within the SOAP HTTP binding

Acknowledgment cycle

announced by group on 20 May 2005

objection from reviewer on 27 May 2005

objection declined by group on 25 Jul 2005

Unable to reach consensus to remove wsoap:mustUnderstand.

Commenter unsatisfied.

Action history

LC77a: Namespaced elements and urlformencoded [link to this issue]

Section 3.8.1: Serialization as "application/x-www-form-urlencoded" does
not appear to constrain XML elements to be unqualified, but neither does
it explain how namespaced elements are to be serialized.

Transition history

raised on 9 Nov 2004 by Jeffrey Schlimmer (jeffsch@windows.microsoft.com)

agreed on 22 Apr 2005

Clarify that since local names must be unique, there is no need to serialize the namespace URI.

Acknowledgment cycle

announced by group on 20 May 2005

agreement by reviewer on 27 May 2005

Action history

LC77b: Drop HTTP binding [link to this issue]

Microsoft does not currently plan to implement Section 3: WSDL HTTP
binding.  If there is only weak support from other implementers perhaps
it would be wisest to drop this binding or factor it out into a Working
Group Note.

Transition history

raised on 9 Nov 2004 by Jeffrey Schlimmer (jeffsch@windows.microsoft.com)

declined on 24 Mar 2005

HTTP binding has support from at least a few vendors, and it's in the charter. Close with no action.

Acknowledgment cycle

announced by group on 20 May 2005

agreement by reviewer on 27 May 2005

LC78: Editorial comments on WSDL 2.0 Part 1 [link to this issue]

Enclosed is a copy of the Part 1 WSDL 2.0 spec in Microsoft Word ormat,
using the change tracking feature to highlight minor editorial issues
within the document.  These issues represent the compilation of editorial
glitches identified by Jeffrey Schlimmer and other reviewers within Microsoft.

I hope the editors find this to be a convenient format for walking through
the suggestions; compiling a stand-alone list would be a considerable effort.

Transition history

raised on 9 Nov 2004 by Jonathan Marsh (jmarsh@microsoft.com)

agreed on 5 May 2005

Accept editor's resolution.

Acknowledgment cycle

announced by group on 20 May 2005

Action history

LC79: Make sure in-only mep is supported in wsdl soap12 binding [link to this issue]

From Nov FTF, need to check that in-only mep is supported by the
						WSDL soap 1.2 binding.

Transition history

raised on 10 Nov 2004 by WSD WG

declined on 1 Jun 2005

There isn't a one-way SOAP MEP, we'll ask for one from the CG, and add an ednote about defaulting to such a MEP if one comes online in the spec.

Acknowledgment cycle

announced by group on 1 Jun 2005

Action history

LC80: Extension Components are not Described [link to this issue]

Part 1 mentions Extension components, but does not descibe them in any 
detail. For example, they are mentioned in the Operation Name Mapping 
Requirement [1] and in the Component URI References [2]. If Extension 
components are important, they should be defined. For example, I'd expect 
that they at least have a QName.

[1] http://www.w3.org/TR/2004/WD-wsdl20-20040803/#Interface_OperationName
[2] http://www.w3.org/TR/2004/WD-wsdl20-20040803/#extension-elements

And from http://lists.w3.org/Archives/Public/www-ws-desc/2004Nov/0058.html:
   Un-recognized required features result in components, un-recognized 
   required element-based extensions don't. Why the difference?

Transition history

raised on 11 Nov 2004 by Arthur Ryman (ryman@ca.ibm.com)

declined on 21 Apr 2005

Closed with no change to the spec.

Acknowledgment cycle

announced by group on 20 May 2005

LC81: The Component Model is Underconstrained wrt the WSDL 2.0 Schema [link to this issue]

As written, the Component Model is missing constraints that enable typical 
instances of the Component Model to be represented as WSDL 2.0 documents. 
This problem is over and above the differences in the character sets and 
name values allowed by the Component Model versus XML.

For example, consider and Interface that extends no other Interfaces and 
that contains a single Operation. Both the Interface and the Operation 
have a QName. However, the Component Model does not constrain their 
namespace names to be equal, as would be the case if the Component Model 
instance came from a WSDL 2.0 document.

I think there is no value in making the Component Model much more general 
than what can be expressed in WSDL 2.0 documents (except for the character 
issues).

I recommend that the Component Model be tightened up to allow its 
instances to be represented by WSDL 2.0 documents, except when prevented 
by differences in character sets and name value spaces. (BTW, I am 
unconvinced that allowing any exceptions is very valuable.)

Transition history

raised on 11 Nov 2004 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 4 Mar 2005

Editors may add constraints whereever needed to ensure component model allows no more than can be serialized as an XML document.

Acknowledgment cycle

announced by group on 20 May 2005

Action history

LC82: Operation Name Mapping Requirement Bug [link to this issue]

The Operation Name Mapping Requirement [1] has a bug.

Consider an interface that has two operations that both return the same 
GED output message, e.g. a Car search service that has findByColour and 
findByHorsepower operations which both return ListOfCars. Assume this 
operation uses a request-response MEP so the response is always corelated 
with the request. 

According to the ONMR, these operations are ambiguous because they have 
the same GED for their output message. The Interface component must have 
either a Feature or an Extension element component that describes how the 
sender is enabling the recipient to distinguish the messages.

This is a spec bug since in this case there is no ambiguity on the input 
messages. The requirement text needs to be corrected to restrict the case 
where the ONMR applies. Also, even those the output messages are the same, 
there is no amibuity since the output is corelated with the input.

[1] http://www.w3.org/TR/2004/WD-wsdl20-20040803/#Interface_OperationName

Transition history

raised on 11 Nov 2004 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 31 May 2005

Accept Tom's proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2005May/0085.html

Acknowledgment cycle

announced by group on 9 Jun 2005

Action history

LC83: The Component Model Does Not Enforce Component Nesting [link to this issue]

The Component Model does not enforce nesting. For example, consider two 
interfaces, that each have a single operation, e.g.

interface TV {
        operation PowerOn;
}

interface Radio {
        operation PowerOn;
}

The TV and Radio interfaces each contain a PowerOn operation. Suppose that 
the properties of the PowerOn operations are identical in both cases. The 
Component Model allows there to be a single Operation component that 
appears in the {operations} property of each Interface component. This 
violates our intuition that operations are local to interfaces, and which 
is apparent in the XML syntax for WSDL 2.0.

More seriously, this situation breaks the URI Reference specification 
since that assumes we can identify any component by build up a path of 
names of its ancestors. In this example, there is not unique path to the 
Operation component.

I recommend that the Component Model should faithfully reflect the nesting 
structure of components that is apparent from the XML syntax of WSDL 2.0 
documents. This translates to the constraint that every component, except 
the root Description component, have a unique parent. The parent of the 
component is the component that contains the definition of the component 
as in the XML syntax.

Transition history

raised on 11 Nov 2004 by Arthur Ryman (ryman@ca.ibm.com)

Subsumed by issue(s) on 31 Mar 2005

Parent property added to component model in LC105 solves this.

LC84a: Operation Name Mapping Requirement is ambiguous [link to this issue]

See referenced presentation.

Transition history

raised on 10 Nov 2004 by David Booth

Subsumed by issue(s) on 19 Jan 2005

Issue goes away with the rewrite of the Operation Name Mapping Requirement to a Best Practice note.

LC84b: Operation Name Mapping Requirement has the wrong granularity [link to this issue]

See referenced presentation.

Transition history

raised on 10 Nov 2004 by David Booth

declined on 31 May 2005

Close with no action.

Acknowledgment cycle

announced by group on 9 Jun 2005

objection from reviewer on 25 Jun 2005

objection declined by group on 25 Jul 2005

WG declined to pursue moving @action from WS-A to WSDL.

LC84c: Operation Name Mapping Requirement doesn't go far enough [link to this issue]

See referenced presentation.

Transition history

raised on 10 Nov 2004 by David Booth

declined on 31 May 2005

Close with no action. See LC82.

Acknowledgment cycle

announced by group on 9 Jun 2005

agreement by reviewer on 11 Jul 2005

LC85: HTTP binding's MEP use description [link to this issue]

Based on our previous discussion[1], the HTTP binding supports 6 MEPs
(In-Only, Robust In-Only, In-Out, Out-Only, Robust Out-Only, Out-In).
It is not specifically specified how those map to HTTP request and
responses. I would propose adding the following clarification:

    Each of the supported MEPs involve one to two messages or faults
    being exchanged. The first is transmitted using an HTTP request,
    and the second is transmitted using the corresponding HTTP
    response. In cases where only one message is being sent, the
    message body of the HTTP response MUST be empty.

While reviewing this text, I noticed that section 3.7 "Specifying HTTP
Error Codes for Faults" talks about HTTP error code sent by the
service. Because of the out-first MEPs, we should remove "by the
service", as it could be done by the client.

  1. http://lists.w3.org/Archives/Public/www-ws-desc/2004Oct/0066.html

Transition history

raised on 12 Nov 2004 by Hugo Haas (hugo@w3.org)

agreed on 10 Dec 2004

Fixed by editors.

Acknowledgment cycle

announced by group on 29 Apr 2005

Action history

LC86: Pseudo-schema inconsistencies [link to this issue]

WG noticed (esp. Asir) that the Part 3 pseudo schema is not 
consistent with Part 1 as it does not show where F&P can appear.

Transition history

raised on 18 Nov 2004 by Working Group

agreed on 10 Dec 2004

Fixed by editors.

Acknowledgment cycle

announced by group on 10 Dec 2004

Action history

LC87: Component Designators - what's the unique identifier? [link to this issue]

Section C.2 of the latest editors draft says:

"Columns two through five specify the identifiers that uniquely identify
the component. Identifiers are typically formed from the {name}
property, although in several cases references to other components are
used."

It is not immediately clear which property uniquely identifies the
component, namely, is the {message label} a unique identifier for a
message reference component?  It's not called out as such in the
description of that property, so it would be much clearer if we just
said "it's the {name} property of component v,w,x, the {message label}
property of component y, and the {blah} property of component z."  Also
might be best to say "uniquely identify the component within it's
context."

Transition history

raised on 17 Nov 2004 by Jonathan Marsh (jmarsh@microsoft.com)

agreed on 5 May 2005

Accept editor's resolution.

Acknowledgment cycle

announced by group on 20 May 2005

Action history

LC88: Editorial: Typo in Section 3.7.3 Part 2 - HTTP Fault [link to this issue]

ref:
http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803/#http-fault-decl-xml

"The XML representation for binding a SOAP Fault are two attribute
information items with .."

 should say,

" .. HTTP Fault .. "

Transition history

raised on 19 Nov 2004 by Asir Vedamuthu (asirv@webmethods.com)

agreed on 14 Apr 2004

Accept editor's resolution of the issue.

Acknowledgment cycle

announced by group on 29 Apr 2005

agreement by reviewer on 6 May 2005

Action history

LC89a: Clarify schema validity conformance requirement [link to this issue]

1.  Is schema-validity a conformance point, or not?  The table
    entry for the "wsdl" namespace prefix mentions a normative
    schema, yet the conformance section talks about information
    model. These two items seem in conflict, and burying the
    schema mention as an aside in a listing of namespace prefixes
    makes it all too easy to dismiss.  I could not find the schema
    in the documents, either.

Transition history

raised on 22 Nov 2004 by Rich Salz (rsalz@datapower.com)

agreed on 22 Apr 2005

Already have done so; to complete this work add a conformance section to the RPC extension.

Acknowledgment cycle

announced by group on 24 May 2005

agreement by reviewer on 24 May 2005

Action history

LC89b: Don't introduce new abstract datatypes [link to this issue]

2.  Abstracting away from XSD datatypes is a mistake. It is eminently
    reasonable to bind yourself to the official W3C schema and data-
    type language.  IT seems foolish to introduce a new type suite
    (and terms such as "actual value") that will almost always map
    directly onto XSD.  Does anyone in the WG know of any plans to
    do otherwise?  This leads into my next point.

Transition history

raised on 22 Nov 2004 by Rich Salz (rsalz@datapower.com)

agreed on 20 Jan 2005

We will removing these definitions, reverting to describing our component model in terms of the XML Schema 1.0 datatypes. This means new XML 1.1 features will not be directly usable within WSDL until the XML Schema WG sorts out how to deal with them.

Acknowledgment cycle

announced by group on 24 May 2005

agreement by reviewer on 24 May 2005

LC89c: Drop XML 1.1 support [link to this issue]

3.  Abstracting away XML 1.x and 2.x is a mistake.  There is too much
    tortured language and complexity by trying to support two incompatible
    formats called XML.  I suggest that support for XML 2.0 is premature:
    it has no Infoset, no Schema, and (yes, because of no schema), no
    SOAP support -- let alone other web services related specifications
    such as XML Digital Signature.  The hardest part of standardization
    is making the right trade-off.  Defer XML 2.0 and you can lose
    the resultant complexity and type redundancy, and you'll be
    making the right exchange.

Transition history

raised on 22 Nov 2004 by Rich Salz (rsalz@datapower.com)

agreed on 20 Jan 2005

We will removing these definitions, reverting to describing our component model in terms of the XML Schema 1.0 datatypes. This means new XML 1.1 features will not be directly usable within WSDL until the XML Schema WG sorts out how to deal with them.

Acknowledgment cycle

announced by group on 24 May 2005

agreement by reviewer on 24 May 2005

LC89d: Disabling a feature on a specific operation [link to this issue]

4.  It doesn't seem possible to define a Feature (sec 2.8) at the Interface
    level, yet disable it for a specific operation.  Unlike my other
    points, this is arguably more of a feature request. :)

Transition history

raised on 22 Nov 2004 by Rich Salz (rsalz@datapower.com)

declined on 22 Apr 2005

WG has thoroughly explored several possibilities, including this one. Closed with no action.

Acknowledgment cycle

announced by group on 24 May 2005

agreement by reviewer on 24 May 2005

LC89e: Properties are runtime and shouldn't be in WSDL [link to this issue]

5.  Properties, which are relevant to a specific runtime instance, do not
    belong here, but rather in a separate file.  WSDL is a network service
    contract; putting per-implementation information here, which may be
    completely inappropriate or wrong for two installations of the same
    runtime, only encourages non-portable service definitions.

Transition history

raised on 22 Nov 2004 by Rich Salz (rsalz@datapower.com)

declined on 22 Apr 2005

Closed with no action.

Acknowledgment cycle

announced by group on 5 May 2005

agreement by reviewer on 5 May 2005

LC89f: Strengthen conformance re: syntax [link to this issue]

6.  Following on the previous item, syntax should dominate.  The most
    important thing about WSDL should be that it is a *portable* description
    of a service interface.  It is crucial that end-users be able to take
    a WSDL file from one platform and use it on another.  Infosets are
    not portable; they are useful to runtime and compiler implementors
    here, not developers using WSDL. The conformance points must be
    strengthened, and end-users must have a clear understanding of what
    it means to write a conforming WSDL file.

Transition history

raised on 22 Nov 2004 by Rich Salz (rsalz@datapower.com)

agreed on 22 Apr 2005

Add "An XML 1.0 document that is valid with respect to the WSDL 2.0 XML Schema and that maps to a valid WSDL 2.0 Component Model is conformant to the WSDL 2.0 specification."

Acknowledgment cycle

announced by group on 24 May 2005

agreement by reviewer on 24 May 2005

Action history

LC89g: Bleed between XML representation, infoset, pseudo-schema, component model [link to this issue]

7.  The phrase "XML representation" as used throughout (e.g., sec 2.5.2)
    is wrong.  The XML representation is the syntax; the Infoset is not
    a representation, it is a data set. Another confusion is the use of
    "[owner]" which looks like an Infoset item, but isn't. My point here
    is that there is much bleed-through, and a confusing mix between
    XML syntax (not enough), non-normative psuedo-schema, XML Infoset,
    and WSDL Component Model.

2005-03-04: Reclassified as editorial.

Transition history

raised on 22 Nov 2004 by Rich Salz (rsalz@datapower.com)

agreed on 5 May 2005

Accept editor's resolution.

Acknowledgment cycle

announced by group on 24 May 2005

agreement by reviewer on 24 May 2005

Action history

LC89h: Use XML Schema, not pseudo-schema [link to this issue]

8.  Much redundancy and lack of clarity could be avoided by using XML
    Schema.  Every (or almost every) section that describes a WSDL
    component follows the same outline:
        A short bit of prose
        Non-normative psuedo-schema
        Infoset description
        Component properties
    Almost all of the middle two sections could be removed by
    including normative XSD fragments.  This would have the benefit
    of being both more precise and less verbose.  I have heard the
    argument that the psuedo-schema is useful to most readers. My
    counter-argument is that this recommendation is targeted to
    WSDL developers, not casual web services developers (although
    I wish it otherwise), and familiarity with XSD can be assumed.

Transition history

raised on 22 Nov 2004 by Rich Salz (rsalz@datapower.com)

declined on 22 Apr 2005

Close with no action.

Acknowledgment cycle

announced by group on 24 May 2005

agreement by reviewer on 24 May 2005

LC89i: Need primer [link to this issue]

9.  A primer is needed. This follows from #6. Just as SOAP and Schema
    have primers targeted toward end-users, so should WSDL. I'd argue,
    in fact, that while you can "hide" the details of SOAP from most
    end-users, you *cannot* do the same for WSDL.

Transition history

raised on 22 Nov 2004 by Rich Salz (rsalz@datapower.com)

agreed on 10 Mar 2005

Primer is one of our chartered deliverables.

Acknowledgment cycle

announced by group on 24 May 2005

agreement by reviewer on 24 May 2005

LC89j: Use namespaces to avoid local-name conflicts [link to this issue]

10. The numerous "Note"'s about name uniqueness are a big warning sign
    that something is wrong.  XML has the technology to avoid
    local-name conflicts, and the current scheme gives only the
    illusion of independent distributed service development.  Proper
    use of namespaces can completely obliterate this problem area.

Transition history

raised on 22 Nov 2004 by Rich Salz (rsalz@datapower.com)

declined on 1 Jun 2005

Our use of namespaces is similar to XML Schemas, and is natural in the syntax despite the component model notes. WG unable to envision a solution without severe consequences to the syntax. Closed with no action.

Acknowledgment cycle

announced by group on 9 Jun 2005

agreement by reviewer on 10 Jun 2005

LC89k: Inheritance unnecessary [link to this issue]

11. The inheritance model isn't necessary. Rather than cram everything
    into one target namespace, allow a service to implement multiple
    endpoints. The conformance point could be "at least one"; ability to
    support multiple namespaces is then a quality of implementation (i.e.,
    marketplace) issue. This would also address #10.

Transition history

raised on 22 Nov 2004 by Rich Salz (rsalz@datapower.com)

declined on 19 Jan 2005

Insufficient interest in reopening the issue. Closed with no action.

Acknowledgment cycle

announced by group on 24 May 2005

agreement by reviewer on 24 May 2005

LC89l: Drop component model [link to this issue]

12. The component model, necessary for equivalence, which in turn is
    necessary for the inheritance model, is a bad idea. Fixing #11
    will partly remove the primary need for the component model.
    Adding some additional "ref" (or href/id) attributes to make all
    linkages explicit (those that don't follow the in-scope model),
    and the component model can be completely removed from the
    recommendation.

Transition history

raised on 22 Nov 2004 by Rich Salz (rsalz@datapower.com)

declined on 4 Mar 2005

Closed with no action.

Acknowledgment cycle

announced by group on 24 May 2005

agreement by reviewer on 24 May 2005

LC89m: Clarify "directly include" [link to this issue]

13. If I understand it correctly, then I am not sure the "directly
    include" concept is useful.  If "a.wsdl" imports "b.wsdl", then
    the types section of the first must reproduce any imports
    in the types section of the second.  If true, this isn't the way
    conventional programming languages work, and since XSD already
    has mechanisms to address multiple inclusion, it seems to needlessly
    require "a.wsdl" to have internal knowledge of "b.wsdl".
    necessary.

Transition history

raised on 22 Nov 2004 by Rich Salz (rsalz@datapower.com)

declined on 21 Apr 2005

Fix rows 4,5 of table 2-1 to match the other rows.

Acknowledgment cycle

announced by group on 24 May 2005

agreement by reviewer on 24 May 2005

Action history

LC90: XML Schema comment on WSDL 2.0 [link to this issue]

The following is a comment on the WSDL 2.0 last call [1]
from the XML Schema WG.  We very much appologize about the 
lateness of this comment.

Paul Biron, for the XML Schema WG
[1] http://www.w3.org/TR/2004/WD-wsdl20-20040803

Problem statement 

It is not uncommon for schema designers to architect systems with 
multiple schemas for a single namespace, with different defintions 
of identically (Q)named schema components (elements, types, etc.).
A WSDL description currently allows only a single schema (in 
<wsdl:types>) and thus a single set of type components available 
for reference (e.g., in <wsdl:input>, <wsdl:output> and 
<wsdl:fault>).  Therefore, WSDL is not currently able to describe 
a service where input and output share the same namespace but use 
conflicting schemas.

Use cases 

1. The prototypical case of multiple schemas for a single namespace 
is XHTML.  All flavors of XHTML share the same namespace but there 
are three separate (and conflicting) schemas: strict, transitional 
and frameset.  It is not currently possible to use WSDL to describe 
a service that takes XHTML transitional documents as input and 
output's an equivalent XHTML strict document.

2. Another case of multiple schemas for a single namespace arises 
from the common strategy of versioning a vocabulary by keeping the 
namespace constant and indicating the vocabular version as part of 
the document content (e.g., with a @version attribute, etc.).  XSLT 
is the prototypical case of this versioning strategy.  It is not 
currently possible to use WSDL to describe a service that takes an 
XSLT 1.0 stylesheet as input and outputing an similar XSLT 2.0 
stylesheet (and vice versa).

3. Other cases of multiple schemas for a single namespace arise for 
any number of reasons, and the particular reasons why people have 
architected their vocabularies so as to have multiple schemas all 
sharing the same namespace are what really matters here.  What does 
matter is that people are doing this and that all of these cases 
have one thing in common: that WSDL as it stands cannot be used to 
describe interactions where there is ANY conflict between the 
different input and output schemas for the same namespace.

Proposed solution 

A possible solution to the above problem would be to provide a means 
of partitioning <wsdl:types> into a) input; b) output; c) fault 
and d) (possibly) "all" sections.  Declarations within <wsdl:input> 
could reference only those components in the "input" partition (or 
the "all" partition if that were allowed); declarations within 
<wsdl:output> could reference only those components in the "output" 
partition, etc.  Another more general solution might be to
allow an arbitrary number of "labled" partitions (or, more correctly, 
schemas) which could then be referenced by any component in the WSDL 
description. 

The XML Schema WG considers this issue important but realizes that 
it is late in your rec-cycle.  We hope you will consider the issue 
carefully and perhaps together we can arrive at a solution that 
works for everyone.

Transition history

raised on 24 Nov 2004 by Biron,Paul V (Paul.V.Biron@kp.org)

declined on 19 May 2005

WG believes it has an existence proof that an extension could be done that satisfies the need. Implementers in the WG expressed no interest in providing support for such an extension (or similar functionality in the core) and thus thsi capability would be unlikely to meet our CR goals.

Acknowledgment cycle

announced by group on 28 May 2005

LC91: XML Schema comment "T2" on WSDL 2.0 [link to this issue]

The following is a comment on the WSDL 2.0 last call [1] from the XML 
Schema WG.  We very much appologize about the lateness of this comment.

Xan Gregg, for the XML Schema WG
[1] http://www.w3.org/TR/2004/WD-wsdl20-20040803

This is an editorial comment on the impact of xs:import in 3.1.1 and 
3.1.2.

3.1.1 contains:

     Note that only components defined in the schema itself
     and components included by it via xs:include are available
     to WSDL. Specifically, components that the schema imports
     via xs:import are NOT available to WSDL.

We think this is correct, but not all of us were sure of the intent at 
first reading, so we suggest wording along the following lines, which 
reinforces the idea that it is a namespace that is imported, not a 
schema.

For 3.1.1 instead of the above two sentences:

     Note that only components in the imported namespace are
     available for reference in the WSDL document.

For 3.1.2 instead of the similar two sentences, we suggest:
		
		Note that only components in the namespace corresponding
		to the targetNamespace attribute of the embedded schema
	element are available for reference in the WSDL document.

(The latter also emphasizes that the targetNamespace is a property of 
the schema element and not of the schema itself.)

Transition history

raised on 4 Dec 2004 by Xan Gregg (xan.gregg@jmp.com)

agreed on 27 Jan 2005

Proposed rewording accepted.

Acknowledgment cycle

announced by group on 13 May 2005

proposal from reviewer on 2 Jun 2005

proposal declined by group on 25 Jul 2005

Agreed to make only minor changes to the affected text.

Action history

LC92: wsdl:include semantics is different from xs:include [link to this issue]

[On behalf of the XML Schema WG]

WSDL Part 1 says: "The WSDL include element information item is modeled
after the XML Schema include element information item (see [XML Schema:
Structures], section 4.2.3 "References to schema components in the same
namespace"). "

...and...

"Specifically, it can be used to include components from WSDL descriptions
that share a target namespace with the including description. Components in
directly included descriptions become part of the component model of the
including description. Directly included means that component inclusion is
not transitive; components included by one of the included documents are not
available to the original including document unless the are included
directly by that document. " -
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#includes

We have some comments based on our general experience with composition
matters.

These two WSDL statements are to some extent contradictory. In fact, XML
schema inclusions are effectively transitive. The XML schema model is that a
single schema (I.e. set of components) is composed from the transitive
closure of the included documents (as well as, in our case, redefined
documents, documents obtained through schemaLocation hints on an import or
in the instance, supplied on a command line, etc.) QName references are
uniformly resolved within this combined schema, regardless of the source of
the definition or the identity of the file containing a QName reference.

It would be nice if WSDL composition worked like XML Schema composition. If
you decide to keep it as it is, we would like to make clear that WSDL
mechanism is indeed different than XML Schema, and suggest that any
comparisons you draw between the two be a bit clearer and more accurate.

Transition history

raised on 7 Dec 2004 by Asir Vedamuthu (asirv@webmethods.com)

agreed on 3 Feb 2005

Agree the difference in transitivity is a mistake. Accept proposed resolution in http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/0059.html. Also see LC75t.

Acknowledgment cycle

announced by group on 13 May 2005

LC93: Editorial: In section 2.15.3, "and" should be "or" [link to this issue]

Editorial:
In
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?
content-type=text/html;%20charset=utf-8#ncname_type
[[
. . . tokens that do not contain the space (#x20) and ':' characters.
]]
The word "and" should be "or".

Transition history

raised on 11 Dec 2004 by David Booth (dbooth@w3.org)

agreed on 5 May 2005

Accept editor's resolution.

Acknowledgment cycle

announced by group on 20 May 2005

agreement by reviewer on 21 May 2005

Action history

LC94: Clarification needed: Part 3 sec 2.8.1 and 2.8.2: soap fault codes [link to this issue]

Regarding part 3 sec 2.8.1 and 2.8.2: soap fault codes, the meaning of
the {soap fault code} seems unclear. 

Does the fault message type determine the soap fault code, or vice
versa?  For example, given the following:

<binding . . . >
  <fault ref="tns:myFaultMessage"
	wsoap:code="foo" />
</binding

which of the following interpretations applies?

a. If the actual error condition causing the fault corresponds to SOAP
code foo, then transmit a fault of type tns:myFaultMessage.

b. If the actual error condition causing the fault corresponds to
tns:myFaultMessage, then transmit SOAP code foo.

If (a) is the correct interpretation, then what happens if an error
corresponding to a different SOAP code occurs?  Does this imply that a
tns:myFaultMessage will NOT be sent if the SOAP code is NOT foo?

Transition history

raised on 12 Dec 2004 by David Booth (dbooth@w3.org)

declined on 3 Feb 2005

When a fault occurs, code and schema are both as specified. The distinction this issue presumes does not exist.

Acknowledgment cycle

announced by group on 28 May 2005

agreement by reviewer on 31 May 2005

LC95: Editorial: Typos [link to this issue]

Typos:

Part 3 sec 2.10.3 Default Binding Rules:
s/Inteface Operation/Interface Operation/

Part 3 sec 2.9.2 Relationship to WSDL Component Model:
s/as defined by for this specific operation/as defined for this specific
operation/

Part 1 sec 2.9.1:
s/to accessing the service/to access the service/

Transition history

raised on 13 Dec 2004 by David Booth (dbooth@w3.org)

agreed on 5 May 2005

Accept editor's resolution.

Acknowledgment cycle

announced by group on 20 May 2005

agreement by reviewer on 21 May 2005

Action history

LC96: wsdl:import semantics is different from xs:import [link to this issue]

[On behalf of the XML Schema WG]

WSDL Part 1 says: 

"The WSDL import element information item, like the include element
information item (see 4.1 Including Descriptions) also allows for the
separation of the different components of a WSDL description into
independent descriptions, but in this case with different target namespaces,
which can be imported as needed. This technique helps writing clearer WSDL
descriptions by separating the definitions according to their level of
abstraction, and maximizes reusability.

The WSDL import element information item is modeled after the XML Schema
import element information item (see [XML Schema: Structures], section 4.2.3
"References to schema components across namespaces"). Specifically, it can
be used to import components from WSDL descriptions that do not share a
target namespace with the importing document. Components in directly
imported descriptions are part of the component model of the importing
description. Directly imported means that component importation is not
transitive; components imported by one of the imported documents are not
available to the original importing document unless the are imported
directly by that document. The imported components can be referenced by
QName." 

http://www.w3.org/TR/2004/WD-wsdl20-20040803/#imports

Some background on XML Schema Import
------------------------------------

As with include, the comparison here seems to be based on some
misconceptions about how XML Schema works. Let us briefly clarify the
behavior of XML Schema xsd:import.

First of all, xsd:include and xsd:import are different in XML schema, and
not just because include works within a single namespace. The primary
purpose of xsd:include is to bring in new components from another schema
document; the primary purpose of xsd:import is to allow references to a
foreign namespace from within a schema document. This function perhaps
become clearer when one notices that the only mandatory information on an
import is in the following form:

<import namespace="nsUri" />

Note that there is no mandatory schemaLocation hint; whether the occurrence
of this import causes "importation" of new components for namespace nsUri is
at the discretion of the processor. What is mandatory is that an import
appear for any referenced namespace. So, we have:

Legal:

<schema xmlns:ns="nsUri">
 <import namespace="nsUri" />
 <element name="e" type="ns:t"/>
</schema>

Not Legal:

<schema xmlns:ns="nsUri">
 <!--missing import -->
 <element name="e" type="ns:t"/>
</schema>

Where might the definition for type ns:t come from in the above example? A
schema document containing the definition could have been named as an
argument to the processor, could have been identified in an
xsi:schemaLocation hint in an instance, or might have been imported as a
side effect of processing some other schema document. The definition might
also have been built into the processor (e.g. an HTML editor with built in
knowledge of HTML validation.)

In general, with the exception of <xsd:include> and <xsd:redefine>, XML
processors can use most any policy for locating schema documents and
components. Of course, there is a very commonly used strategy, which is to
honor schemaLocation hints on an import:

<schema xmlns:ns="nsUri">
 <import namespace="nsUri" 
     schemaLocation="http://example.org/nsURischema.xsd/>
 <element name="e" type="ns:t"/>
</schema>

Because many processors honor such hints, it's a common misconception that
components are imported by import statements. That appears to be true of
WSDL, but not of Schema.

Also, as already noted in our comment on include, the visibility of global
components in XML schema is pervasive. The ability to reference a global
component does not depend on the schema location document in which the
reference occurs. Insofar as components are brought in as a result of nested
schemaLocation hints, the visibility is indeed (to use your term)
transitive. This appears to be another difference between the WSDL and
Schema designs.

Suggested change
----------------

As with include, we think there would be some "least astonishment" value for
users if WSDL were to follow Schema's lead, but we certainly don't insist
that you do. As with include, we would like to understand the reasons for
any differences that you decide to retain. We do feel it's appropriate to
formally request that any comparisons drawn to the schema design be
accurate, so we request that you either remove or correct the text that
suggests that WSDL and Schema import behave similarly. As currently
specified, it appears that they are different with respect both to the role
of import in bringing components into a WSDL or Schema definition, and also
in the degree to which such components are globally visible.

Transition history

raised on 15 Dec 2004 by Asir Vedamuthu (asirv@webmethods.com)

Subsumed by issue(s) on 21 Apr 2005

Subsumed by LC120 resolution.

LC97: Editorial: Setting Default Values [link to this issue]

WSDL last call drafts use 4 different styles to set default values,

[Style 1] In Part 1, default value is set via mapping
"Mapping .. {safety}	The actual value of the safe attribute information
item if present, otherwise the value false."

"Mapping .. {required}	The actual value of the required attribute
information item if present, otherwise "false"."

[Style 2] In Part 3, SOAP Binding, default value is assumed
"Mapping .. {required}	The actual value of the required attribute
information item."

[Style 3] In Part 3, HTTP Binding, default value is set via component
description
"A [local name] of version
 A [namespace name] of "http://www.w3.org/2004/08/wsdl/http"
 A type of wsdls:string
 A default value of "1.1""

[Style 4] In Part 3, HTTP Binding, default value is spelled out in a
separate table
"{http output serialization}	The actual value of the
whttp:outputSerialization attribute information item, if present. Otherwise,
the default value as defined in 3.3 Default Binding Rules."

Of them, I like [Style 1] and [Style 3]. To be consistent, my suggestion is
to use ONE style for setting default values.

See also further direction from WG.

Transition history

raised on 15 Dec 2004 by Asir Vedamuthu (asirv@webmethods.com)

agreed on 26 May 2005

Accept editor's resolution

Acknowledgment cycle

announced by group on 28 May 2005

Action history

LC98: {soap mep} property and SOAP 1.1 Binding [link to this issue]

Background Info

"{soap mep}, a wsdls:anyURI, which is an absolute URI as defined by [IETF
RFC 2396], to the Binding Operation component. The value of this property
identifies the SOAP Message Exchange Pattern (MEP) for this specific
operation. If no specific value is assigned, then the value assigned by the
default rules apply (for SOAP 1.2, see 2.10.3 Default Binding Rules). It is
an error for this property to not have a value (which MAY happen if the
default rules are not applicable)." - Part 3

Last sentence, it is an error if {soap mep} property does not have a value.
As I recall, this is the reason why I made up those spooky URIs for SOAP 1.1
Binding. At the last face to face, we decided to drop those URIs, ignore
{soap mep} property, and rely on Interface Operation component's {message
exchange pattern} property.

Issue

For SOAP 1.1 binding, {soap mep} property has no value. Per Part 3, it is an
error if {soap mep} property does not have a value.

Proposed Solution

In Part 3, move this constraint from Binding Operations to SOAP 1.2 Binding
section.

Transition history

raised on 15 Dec 2004 by Asir Vedamuthu (asirv@webmethods.com)

agreed on 1 Jun 2005

Accept proposal.

Acknowledgment cycle

announced by group on 9 Jun 2005

Action history

LC99: Message Reference Component is Underspecified [link to this issue]

The Message Reference Component description [1] doesn't define the 
semantics of the message when the optional {message content model} 
property is absent.

If the property is absent is that the same as #any?

[1] http://www.w3.org/TR/2004/WD-wsdl20-20040803/#MessageReference

Transition history

raised on 9 Jan 2005 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 21 Apr 2005

Add the "other" value added to component model, all values to have octothorpe stripped in component model.

Modified 2005-04-28, keep the octothorpe and add the #other value to the schema.

Acknowledgment cycle

announced by group on 23 May 2005

Action history

LC100: The WSDL 2.0 XSD for Root Element is Too Loose [link to this issue]

The wsdl20.xsd definition [1] for the root element doesn't constrain the 
order of the top level elements as described in the spec.[2]

The current xsd is like:

  <xs:complexType name="DefinitionsType" mixed="false">
    <xs:annotation>
      <xs:documentation>
        Please refer to the WSDL 2.0 specification for
        additional constraints on the contents of this type.
      </xs:documentation>
    </xs:annotation>
    <xs:complexContent>
      <xs:extension base="wsdl:ExtensibleDocumentedType">
        <xs:choice minOccurs="0" maxOccurs="unbounded">
          <xs:element ref="wsdl:import"/>
          <xs:element ref="wsdl:include"/>
          <xs:element ref="wsdl:types"/>
          <xs:element ref="wsdl:interface"/>
          <xs:element ref="wsdl:binding"/>
            <xs:element ref="wsdl:service"/>
          <xs:any namespace="##other" processContents="lax" minOccurs="1" 
maxOccurs="1"/>
        </xs:choice>
        <xs:attribute name="targetNamespace" type="xs:anyURI" use=
"required"/>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

It should be like:

  <xs:complexType name="DefinitionsType" mixed="false">
    <xs:annotation>
      <xs:documentation>
        blah, blah, blah ...
      </xs:documentation>
    </xs:annotation>
    <xs:complexContent>
      <xs:extension base="wsdl:ExtensibleDocumentedType">
                <xs:sequence>
                        <xs:choice minOccurs="0" maxOccurs="unbounded">
                                <xs:element ref="wsdl:import"/>
                                <xs:element ref="wsdl:include"/>
                                <xs:any namespace="##other" 
processContents="lax" minOccurs="1" maxOccurs="1"/>
                        </xs:choice>
                        <xs:element ref="wsdl:types" minOccurs="0" 
maxOccurs="1"/>
                        <xs:choice minOccurs="0" maxOccurs="unbounded">
                                <xs:element ref="wsdl:interface"/>
                                <xs:element ref="wsdl:binding"/>
                                <xs:element ref="wsdl:service"/>
                                <xs:any namespace="##other" 
processContents="lax" minOccurs="1" maxOccurs="1"/>
                        </xs:choice>
                </xs:sequence>
                <xs:attribute name="targetNamespace" type="xs:anyURI" use=
"required"/>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>


[1] http://www.w3.org/2004/08/wsdl
[2] http://www.w3.org/TR/2004/WD-wsdl20-20040803/#Definitions_XMLRep

Transition history

raised on 9 Jan 2005 by Arthur Ryman (ryman@ca.ibm.com)

declined on 22 Apr 2005

Close with no action.

Acknowledgment cycle

announced by group on 20 May 2005

LC101: message level binding? [link to this issue]

I took an action item in our last concall to open a new issue to catch
the group's discussion around using different transport protocols for
different messages of a binding operation. The issue was raised in
discussion on LC50.   

Status Quo

In the current WSDL2.0 draft, binding type and protocol are specified in
the binding component level, 
	- the binding component has a "type" property which indicates
what kind of binding (e.g soap, http, etc) is used. 
	- The soap binding extension adds a "protocol" property binding
component to indicate what transport is used. 

Once their values are set, those properties are applied to all the
operations and messages under that binding, and there is no build-in
constructs to overwrite them in message level. In other words, by
design, not only the input and output messages of an operation,  but all
the operations of a binding MUST use same binding type and protocol.  


Issue

Practically, a typical web service will use the same binding (type,
transport, etc) for all its input and output messages, but there are
situations that a service may need to specify different bindings for
different messages. Here are a few examples,
 
- A service may prefer to use different transports for its "in" message
and "out" message, e.g. to receive a request message over SOAP/HTTP and
send the response via SOAP/SMTP. 
- A service may want to specify explicitly some aspect of a transport
for individual messages.  E.g. while most of the services that use an
in-out MEP over HTTP may use the same HTTP connection, some services may
prefer use different HTTP connections for the "in" message and the "out"
message.
- a service that supports ws-addressing replyTo and faultTo may want to
use a different binding for such "re-direct"s. In such cases, they may
count on WSDL to provide the legal binding candidates such "redirect"
can use. 

The current spec is not clear/consistent about whether such cases are
supported by WSDL2.0. Just by looking at the WSDL component model, they
are NOT supported, but mandatory extensions may support them by
overwriting the binding settings at message level. This inconsistency
has already caused confusion in the web services community, including
other W3C working groups.

Transition history

raised on 16 Dec 2004 by Liu, Kevin (kevin.liu@sap.com)

declined on 1 Jun 2005

Close with no action.

Acknowledgment cycle

announced by group on 9 Jun 2005

LC102: What is the SOAP MEP for In-only [link to this issue]

Folks, 

It seems that we have a hole in our specification. 

We were trying to specify a WSDL interface that utilizes a single input
message, i.e. with In-only MEP. 

Currently, per section 2.9.2 of Part3 [1] states the following:  

{
{soap mep}, a wsdls:anyURI, which is an absolute URI as defined by [IETF
RFC 2396], to the Binding Operation component. The value of this
property identifies the SOAP Message Exchange Pattern (MEP) for this
specific operation. If no specific value is assigned, then the value
assigned by the default rules apply (for SOAP 1.2, see 2.10.3 Default
Binding Rules). It is an error for this property to not have a value
(which MAY happen if the default rules are not applicable).
} 

We then looked at (Section 2.10.3 Default Binding Rules) which says: 

{
SOAP MEP Selection. If the Interface Operation component's {message
exchange pattern} property has the value
"http://www.w3.org/@@@@/@@/wsdl/in-out" then the default value of the
{soap mep} property for the corresponding Binding Operation component is
"http://www.w3.org/2003/05/soap/mep/request-response/" identifying the
SOAP Request-Response Message Exchange Pattern as defined in [SOAP 1.2
Part 2: Adjuncts]. If the Inteface Operation component has any other
value for the {message exchange pattern} property, then no default value
is defined for the {soap mep} property of the corresponding Binding
Operation component.
}

This means that for an In-only MEP, we have no default SOAP MEP.
However, it is an error for the property not to have a value. 

This means the user has two choices: 

-- Define a new SOAP MEP for an In-only MEP. Since there is no
recommended SOAP input MEP that is defined in the SOAP Adjuncts, that is
the only choice for the user. Right? 

-- Use a predefined SOAP MEP, such as request-response. But, this does
not really match the abstract definition of the operation, as there will
be a response. This means then I will have to change my interface to use
a different MEP, that allows a response. Robust-In? 

What are we really suggesting the community to do in this case? 

This is rather disturbing to us. It is well known that some of our MEPs
may not have corresponding SOAP MEPs or appropriate bindings that may be
addressed by extension mechanisms, but In-only is a common WSD MEP that
the community uses already. 

Did we miss a decision pertaining to this case? We don't think that
expecting the users to define a new SOAP MEP is acceptable for interop
purposes as currently the only MEP that is defined with the bindings is
In-Out...

Transition history

raised on 14 Jan 2005 by Yalcinalp, Umit (umit.yalcinalp@sap.com)

Subsumed by issue(s) on 1 Jun 2005

See LC79.

LC103: {message label} property of Binding Message Reference Component Should be REQUIRED [link to this issue]

The {message label} property of the Binding Message Reference component 
[1] should be REQUIRED. This property always exists, however, it is 
allowed to be OPTIONAL in the XML infoset because it can be inferred in 
the case that there is exactly one message with the specified {direction} 
property in the MEP. It is OK to have it OPTIONAL in the XML infoset as an 
authoring convenience. But this property always has a definite value so it 
should be REQUIRED in the Component Model.

[1]http://www.w3.org/TR/2004/WD-wsdl20-20040803/#Binding_Message_Reference

Transition history

raised on 19 Jan 2005 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 20 Jan 2005

Make the message label property of the binding message reference component required AND substitute an error for empty in the text in the message label mapping in table 2-13. (also see LC75l.)

Acknowledgment cycle

announced by group on 28 May 2005

LC104: Proposed Changes to the Interface Component, Features and Properties [link to this issue]

This proposal is a follow-on to my note [1].

The {operations}, {faults}, {properties}, and {features} properties of the 
Interface component are defined as derived properties rather than as being 
directly mapped onto the XML infoset.

The {operations} and {faults} include the Operation and Fault components 
directly defined in the Interface component and those inherited from any 
Interface components that this component extends.

The {features} and {properties} similarly include all directly defined and 
inherited Feature and Property components.

I recommend that we change the definition of the above properties to 
include only those components that are directly defined in the Interface, 
and introduce another set of derived properties that are computed from the 
directly defined properties as follows:

{all operations} and {all faults} include those directly defined and those 
inherited from extended Interface components.

{in-scope features} and {in-scope properties} include those directly 
defined, those inherited from extended Interface components, and those 
included from parent components. This is analogous to the [in-scope 
namespaces] property of the XML Infoset [2].

Furthermore, we should add {in-scope features} and {in-scope properties} 
to all components that have {features} and {properties}.


The benefit of these changes is that we have a clear and consistent naming 
convention for directly defined properties versus derived properties.

Editorially, we do not have to update the description of each affected 
component. We could just add a section that defined the meaning of 
{in-scope features} and {in-scope properties}.

[1] 
http://lists.w3.org/Archives/Public/public-ws-desc-comments/2005Jan/0007.html
[2] http://www.w3.org/TR/xml-infoset/

Transition history

raised on 27 Jan 2005 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 24 Feb 2005

WG agreed to make Interface {features} and {properties} consistent, per http://lists.w3.org/Archives/Public/www-ws-desc/2005Feb/0068.html. WG declined to acc {in-scope properties} or {in-scope features}. WG agreed to "change the definition of the above properties to include only those components that are directly defined in the Interface", but declined to add {all operations} and {all faults} properties.

Acknowledgment cycle

announced by group on 20 May 2005

Action history

LC105: Proposal for Simplifications to the Component Model [link to this issue]

As I mentioned in an earlier note [1], I've hit problems trying to 
formally specify some aspects of the component model. These are related to 
the interactions between interface inheritance, component equivalence, and 
extension elements. I'd like to propose some simplifications here so I can 
move forward.

1. The spec has the notion of component equivalence. This concept was 
introduced as a consequence of interface inheritance. The problem was that 
we wanted to allow diamond inheritance, eg:

interface A extends B, C;
interface B extends D;
interface C extends D;

The problem occurs because now it looks like interface A contains two, 
potentially conflicting, copies of the operations in D. We resolved this 
by saying that if the copy of D acquired via B is equivalent to the copy 
of D acquired via C, then all is well. Otherwise there is an error. The 
two copies will be equivalent if they come from the same document, which 
is the normal case. However, we can't simply compare the URIs used to 
import or include D because it is possible to have two different URIs 
resolve to the same document. We therefore need to compare the contents of 
the documents.

The definition of component equivalence is recursive and can be computed 
bottom-up, i.e. two components are equivalent if all their properties are 
equivalent. Their properities could be either values or component 
references. If component references, then apply this definition 
recursively until you hit just values.

This would be fine if all component properties could be computed 
bottom-up. But there are some properties that are computed top-down, e.g. 
in-scope Property and Features, or inherited Operation or Fault 
components. Also, some Extension component properties might be like this. 
So the definition is a little circular and hard to specify simply.

I'd like to propose a simplification. We should eliminate the concept of 
component equivalence and use infoset equivalence instead. In a sense, the 
infoset is really where this concept belongs since it arises from 
considering how we combine documents. The component model has no concept 
of document. It is built up from the infosets of documents.

The impact of this change is that as we are building up the component 
model, we check to see that duplicate definitions of components have 
equivalent infosets. If the infosets differ then we have an error and we 
can't create the component model. The infoset definition is strictly 
bottom-up and can be computed without reference to derived component model 
properties.

Furthermore, I suggest we apply this notion only to the top level 
elements: interface, binding, and service, since they are the components 
that are likely to appear more than once either via import or include or 
by cut and paste.

2. An implication of the above proposal is that we would disallow 
"accidental" duplication of operations or faults. For example, the 
following situation is disallowed:

interface A { operation X };
interface B extends A { operation X};

The above is disallowed since operation X is defined in two different 
interfaces. This is disallowed even if the contents of operation (A/X) is 
identical to operation (B/X). The appearance of X in B is considered to be 
an accident and an error.

Similarly, the following is also illegal:

interface A { operation X};
interface B { operation X};
interface C extends A, B;

A and B may contain operations of the same name, but an error occurs when 
C extends both of them, even if X is defined identically in both. 
Designers must factor common operations into a base interface, e.g.

interface D {operation X};
interface A {...};
interface B {...};
interface C extends A, B;

The same considerations apply to Fault components.

An additional motivation for this rule is that now all components have 
unique URI's. Everyone component is defined in a unique parent component 
and we can assign it a URI by building up a path composed of the names of 
its ancestors. In contrast, if we allowed accidental equivalence, then in 
the first example, we only have one operation component X, but is has 2 
parents (A and B) and therefore 2 URIs : nsuri#wsdl.operation(A/X) and 
nsuri#wsdl.operation(B/X). And we would really have to compute its derived 
properties to determine equivalence.

3. Finally, for this to work, we should only permit extension elements and 
attributes in the top level elements: interface, binding, and service. 
This means they are disallowed as children of the root description 
element.

The motivation for this is that extensions in the root element are scoped 
to the document, but there is no way to capture this scope within the 
component model. The only property pushed down from the document to the 
top level elements is the targetnamespace attribute which becomes the 
namespace name of the QNames of interface, binding, and service.

Allowing root level extensions complicates the definition of infoset 
equivalence of the top level elements since the semantics of the 
extensions might alter the meanings of the top level element, i.e. attach 
some inherited properties to them.

The consequence is that if an extension is intended to have document wide 
scope, then it must be explicitly copied into all the top level elements. 
However, I am not aware of any such extensions in use today.

One other pleasant consequence of this rule is that we can have a 
deterministic schema that enforces the order of the top level elements, 
i.e.:

description =
        (import | include) *
        types ?
        (interface | binding | service) *

This avoids the need to introduce additional elements to enforce order as 
I proposed in [2].

[1] 
http://lists.w3.org/Archives/Public/public-ws-desc-comments/2005Jan/0007.html
[2] 
http://lists.w3.org/Archives/Public/public-ws-desc-comments/2005Jan/0006.html

2005-03-04: Added constraint that top-level components must be unique. Added parent property to nested components.

Transition history

raised on 27 Jan 2005 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 17 Mar 2005

Closed: Added constraint that top-level components must be unique. Added parent property to nested components. Remaining proposal not accepted.

Acknowledgment cycle

announced by group on 20 May 2005

Action history

LC106: Revisit LC21 resolution [link to this issue]

Folks, 

I took the action item to explore the impact of a decision made by the
wg with respect to the style attribute at the last f2f [1]. 

We were discussing LC61a [2] and we made the decision to move style
attribute to Part2 where it naturally belongs. The nature of my action
does not concern our decision with respect to LC61a which I agree with.
The action item  concerns investigating an earlier decision of the wg
that was brought up by Asir during the discussion of LC61a with respect
to LC21 [4] that was resolved in [3]. 

It became apparent in the f2f [1] that people were unaware of the impact
of the decision made in [3] with respect to rpc style in particular. 

In LC21[3], there were two decisions taken by the wg as quoted:
(Labeled as A and B for reference)

A:  ED TODO: Add a statement like: 

The Style property may constrain both input and output, however a
particular style may constrain in only one direction. In Section 2.4.1.1
of Part 1.

B: ED TODO: Integrate the style property changes to move the style
properties from operation to message component and add the defaulting
language for the operation component model. Part 1 and 3. changes.

I am raising an issue with respect to the second decision made by the
wg. It appears that the consequences of the decision with respect to rpc
style was not considered during the October meeting [3]. 

1) A and B are contradictory. When the style is moved to message level,
the style property can no longer contrain both input and output. It
becomes impossible to do so. So, the first ed to do A is in conflict
with the second one, B. 

2) The decision makes the rpc style completely unusable, actually
undefinable as the style is now defined for message, not for operation.
The rpc style governs the interaction and relationship between input and
output messages. Therefore, it belongs at the operation level. As a
matter of fact, moving the style attribute to message component
completely breaks the rpc style as there is no other means to relate the
constraints at the correct level of abtraction, namely the operation
that represents the interaction between input and output messages, and
the signature which is also related to it. 

This is a BIG issue and must be resolved by revisiting the decision for
LC21. I am not sure why this has been missed [3], but the attendence
list indicates that the folks who put together rpc style were not
attending. So, it is my duty to bring it to the wg's attention. :-)

The reason for moving the style to message component is to provide the
correct level of granularity for other styles to define constraints only
on the message level. However, the solution of LC21, providing correct
level of granularity should not break one of the styles we painfully
designed for a long time in this wg, namely the rpc style. 

There are several ways that this can be achieved. I looked at the
proposals that were presented during the f2f with that regard. 

-- Option 1 will not break rpc style. This will provide granularity at
both operation level and message level. 

-- Another proposal was brought up by Jonathan. To keep @style at
operation level and not introduce a message level @style. But introduce
a multi part IN and OUT style with a list of styles that produce a union
of constraints. Not clear from the minutes why this is not considered. 

Both approaches are acceptable IMO, but the second part (B) of the LC21
resolution, which is luckily not implemented yet, as stated is NOT.  We
prefer the first option, as it will allow style to appear where it
logically fits. Since composition rules for style requires all listed
styles to be observed [5], the same reasoning can apply to styles that
apply to message as well as operation to be treated as a single set. 

I propose the following 

-- we reopen the issue LC21. 
-- we keep the resolution A for LC21. 
-- we reconsider these two options instead of B which will not break rpc
style as an amendement for the resolution. 

Transition history

raised on 22 Dec 2004 by Umit Yalcinalp

agreed on 4 Mar 2005

Have style only at the operation level, specify that the uri/multipart styles may be used for any mep with an initial message.

Acknowledgment cycle

announced by group on 20 May 2005

Action history

LC107: Consistency of WSDL Component property names [link to this issue]

I'd like to suggest some improvements in the consistency of property names
in the Component Model (WSDL 2.0 Part 1 spec, Section 2 Component Model)

ElementDeclaration is referred to by properties in various components:

Description has property {element declarations}  - a set of
ElementDeclaration
InterfaceFault has property {element}                  - an
ElementDeclaration
MessageReference has property {element}         - an ElementDeclaration

For clarity, could same name be used for properties that refer to the same
type of component (with adjustments for plural or singular):
Description {elements}
InterfaceFault {element}
MessageReference {element}

==================

There is a similar inconsistency with the names of fault properties:

Interface {faults} - a set of InterfaceFault
InterfaceOperation {fault references} - a set of FaultReference
FaultReference {fault reference} - an InterfaceFault
BindingFault {fault reference} - an InterfaceFault

The use of {fault references} for InterfaceOperation makes sense, but its
use in FaultReference and BindingFault is confusing. For example, a
FaultReference {fault reference} refers to an InterfaceFault that must be a
member of the parent Interface {faults} so why not use the same property
name for both?

In this example, the {fault reference} property in FaultReference and
BindingFault could be simply {fault}, thus:
FaultReference {fault} - an InterfaceFault
BindingFault {fault} - an InterfaceFault

==========================

Perhaps property names could be made not only consistent but more
descriptive by basing them on the name of the Component they refer to. This
would facilitate the creation of APIs based closely on the WSDL Component
Model that are more descriptive (eg: the getter/setter methods for
properties).

Thus...

Description {element declarations} - a set of ElementDeclaration
InterfaceFault {element declaration} - an ElementDeclaration
MessageReference {element declaration} - an ElementDeclaration

and...

Interface {interface faults} - a set of InterfaceFault
InterfaceOperation {fault references} - a set of FaultReference
FaultReference {interface fault} - an InterfaceFault
BindingFault {interface fault} - an InterfaceFault

This would also clarify the use of operations and faults across Interfaces
and Bindings:

Interface {fault} - an InterfaceFault
Binding {fault} - a BindingFault

could become...

Interface {interface fault} - an InterfaceFault
Binding {binding fault} - a BindingFault

And....

Interface {operations} - a set of InterfaceOperation
Binding {operations} - a set of BindingOperation

could become...

Interface {interface operations} - a set of InterfaceOperation
Binding {binding operations} - a set of BindingOperation.

[Also see friendly amendment, approved 2/17/05.]

Transition history

raised on 9 Feb 2005 by John Kaputin (KAPUTIN@uk.ibm.com)

agreed on 5 May 2005

Accept editor's resolution.

Acknowledgment cycle

announced by group on 20 May 2005

Action history

LC108: Part 3, SOAP Binding - Editorial Issues [link to this issue]

(a) Missing: mapping from XML Representation for {soap modules} [1]

(b) Malformed: XML Representation of SOAP Binding Fault [2]

<definitions >
  <binding >
    <fault ref="xs:QName"
           wsoap:code="xs:QName"
           wsoap:subcodes="list of xs:QName"? />
---------------------------------------------->
    </fault>*
  </binding>
</definitions>

[1] http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803/#soap-module-decl
[2]
http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803/#soap-fault-decl-xml

Transition history

raised on 3 Feb 2005 by Asir Vedamuthu (asirv@webmethods.com)

agreed on 14 Apr 2004

Accept editor's resolution of the issue.

Acknowledgment cycle

announced by group on 20 May 2005

Action history

LC109: Multiple input and output elements for an operation [link to this issue]

The WSDL schema allowa multiple input, output, infault and outfault
within an operation.
The primer says that multiple infault and outfault define alternative
fault message. 
It does not define the role of of multiple input/output. Are they also
regarded as alternative?

JMarsh: It might be a problem that only the primer says infault and
outfault define alternative fault messages.  That should probably be
fixed (or clarified if I just missed it) in Part 1 or Part 2.

Transition history

raised on 26 Jan 2005 by Zvi Bruckner (zvi.b@sapiens.com)

agreed on 14 Apr 2004

Accept editor's resolution of the issue.

Acknowledgment cycle

announced by group on 20 May 2005

Action history

LC110: WSDL 2.0 Part3, Sec. 3.4 [link to this issue]

The XML Representation of the HTTP version used is a string representing 
only the "major" "." "minor", why not choosing the HTTP-Version definition 
of RFC2616?
<<
   HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT^M
>>
Or use integers for major and minor?

Transition history

raised on 14 Feb 2005 by Yves Lafon (ylafon@w3.org)

agreed on 22 Apr 2005

Restrict the pattern to digits.digits, and add an explicit ref to 2616.

Acknowledgment cycle

announced by group on 20 May 2005

Action history

LC111: HTTP Error code for faults (part3, sec 3.7) [link to this issue]

3.7.1 says:
<<<
For every Interface Fault component contained in an Interface component, 
an HTTP error code MAY be defined. It represents the error code that will 
be used by the service in case the fault needs to be returned.
>>>

Would it be possible to add that fault definition SHOULD NOT go against 
the definition of the HTTP error codes?
Ie: you may specify returning an error code using 4xx if the error is in 
the HTTP request, a 5xx error for a "server-side" error during the 
processing of the request, and preclude the use of 3xx for faults?
Or reference RFC 3205 Section 8 [1].
Thanks,

[1] http://ietf.org/rfc/rfc3205.txt

Transition history

raised on 14 Feb 2005 by Yves Lafon (ylafon@w3.org)

agreed on 24 Mar 2005

Add "The fault definition SHOULD NOT go against the definition of theHTTP error codes, see RFC 3205."

Acknowledgment cycle

announced by group on 20 May 2005

Action history

LC112: New LC issue: XML Schema required (appears twice) [link to this issue]

New issue: in Part 1, we indicate twice that all (WSDL) processors must 
support XML Schema. Although not harmful, I propose that we remove the 
second indication. I propose to treat this issue as editorial.

Transition history

raised on 16 Feb 2005 by Jean-Jacques Moreau (jean-jacques.moreau@crf.canon.fr)

agreed on 5 May 2005

Accept editor's resolution.

Acknowledgment cycle

announced by group on 20 May 2005

Action history

LC113: Feature and Property Composition for Binding Operation Omits Interface Operation [link to this issue]

I think there is an ommission. In the Feature [1] and Property [2] 
Composition sections, the in-scope components for Binding Operation should 
include those of the corresponding Interface Operation.

[1] 
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#Feature_composition_model
[2] 
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#Property_composition_model

Also see Asir's addendum.

Transition history

raised on 21 Feb 2005 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 14 Apr 2005

Proposal (including Asir's amendment) accepted.

Acknowledgment cycle

announced by group on 20 May 2005

Action history

LC114: In-Multi-Out MEP [was "WSDL 2.0 specification"] [link to this issue]

> 1) Why has the In-Multi-Out pattern been deleted from the spec?

[Dbooth] As far as I recall there were two reasons: 1. nobody in the Working
Group had a particular need for it; 2. we don't have a binding that uses
it.

> 
> 2) We need to describe an asynchronous Request-Multiple Response
> interaction. How are we supposed to describe it without the In-Multi-Out
> pattern?

[DBooth] There are several options, though I don't know if you would consider any
of them good enough for your purposes.

1. Use the in-out pattern (regular request/response), but specify an
additional application-level constraint (outside of WSDL) that there may
be multiple instances of the response.  Thus, the WSDL document itself
would be insufficient for a client to make use of the service.  The
client would *also* need to know of this additional application-level
constraint.

2. Define the request and response as two separate one-way operations,
and specify application-level constraints (outside of WSDL) to indicate
that one request may be followed by multiple responses.  From a WSDL
perspective, each request would be a separate WSDL operation and each
response would be a separate operation, but the application could view
the combination of a request and multiple responses as representing a
single application-level operation.

3. Define a new MEP and corresponding binding extension for
request-multi-response.

> 
> 3) The specification states that on top of the 8 pre-defined patterns,
> additional ones may be defined, but it doesn't provide a formal
> language/notation/syntax for the pattern extensibility. How is the user of
> the spec supposed to define new ones?

[DBooth] Good point.  I think it would make sense to add some guidance on this to
either the spec or the primer.  The basic answer:

1. Look around on the Web to see if somebody else has already defined
one that is close enough to what you want.

2. Write an HTML document that clearly defines the MEP, and post it at a
stable URL that will represent the formal (URL) name of the MEP, such as
http://example.com/2005/ws/in-multi-out.  

3. Write a corresponding binding extension for your MEP.

4. Publicize your new MEP and binding extension, so that others can
implement and use it.

Note that the above procedure does *not* cause your MEP to become
automatically recognized and usable by WSDL toolkits.  It simply
provides a well-defined mechanism for naming and reusing them.

Transition history

raised on 9 Mar 2005 by David Booth (dbooth@w3.org)

agreed on 1 Jun 2005

Close without action.

Acknowledgment cycle

announced by group on 9 Jun 2005

LC115: Re: a WSDL whatsit? (conformance terminology) [link to this issue]

Section 8.1 is the one that defines (or will define, once the editorial
changes are complete) a "conforming WSDL 2.0 document".  (We currently
use the term "WSDL document" in a number of places in the spec, so these
also need to be changed to "conforming WSDL 2.0 document".  Or perhaps
we should just make the term be "WSDL 2.0 document", to be slightly
briefer.)

It occurs to me that it would also make sense to move Part 1 section 8.1
to the beginning of the spec, so that the reader can begin with the
overall understanding of what constitutes a conformant WSDL 2.0 document
(which is what section 8.1 defines), and then drill down as the spec is
read.  

I suggest moving section 8.1 immediately after section 1.1, so that
section 1 would proceed as follows:
	1.1 says what WSDL is all about (no change);
	1.2 (formerly 8.1) says what consitutes a conformant WSDL 2.0 document;
	1.3 (formerly 1.2) says what it means (no change);
	1.4 (formerly 1.3) defines notational conventions (no change).

See also followup suggestion.

Transition history

raised on 25 Mar 2005 by David Booth (dbooth@w3.org)

agreed on 5 May 2005

Accept editor's resolution.

Acknowledgment cycle

announced by group on 20 May 2005

agreement by reviewer on 21 May 2005

Action history

LC116: RE: Is schemaLocation Required When Importing Inline Schemas? [link to this issue]

The spec currently says that when you refer to inline schemas within the 
same document you need to provide a schemaLocation attribute with a 
suitable fragid in the xs:import statement:

Inside an embedded XML schema, the xs:import and xs:include element 
information items MAY be used to refer to other XML schemas embedded in 
the same WSDL description, provided that an appropriate value is specified 
for their schemaLocation attribute information items, such as a fragment 
identifier (see [XML Schema: Structures] 4.3.1). The semantics of such 
element information items are governed solely by the XML Schema 
specification [XML Schema: Structures].

I thought we said the fragid was unnecessary since the WSDL processor 
knows where to find the schemas.

On the other hand, there was a very long thread [1] about how to refer to 
an inline schema from another WSDL document. The thread ended 
inconclusively with an action item [2] that doesn't seem to exist. The 
conclusion seems to have been that you didn't need the schemaLocation, but 
the behavioir was dependent on the processor.

Can we please tighten this up? I just created some Primer text that may 
not be correct.

I propose that we require a WSDL processor to know how to locate any 
inline schemas it encouters while processing a document so that the 
schemaLocations are not required.

"If schemaLocation is not present then a WSDL processor MUST attempt to 
locate the schema among the inline schemas it has encountered while 
processing the WSDL document."

[1] http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0109.html 
[2] http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0156.html

Transition history

raised on 30 Mar 2005 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 21 Apr 2005

Incorporate suggested text (http://lists.w3.org/Archives/Public/www-ws-desc/2005Apr/0145.html), changing: "so long as the inline schema has been encountered during resolution of imports and includes for the current component model." to "so long as the inline schema has been resolved in the current component model."

Acknowledgment cycle

announced by group on 20 May 2005

Action history

LC117: Problem with Service References: elementFormDefault="qualified" prevents restriction [link to this issue]

In the process of writing the Primer section on Service References, I have 
found a problem in the solution we adopted. The context of this topic is 
that some services may reference to other services, and we were defining a 
way that WSDL could be used to describe the interface and binding of the 
service that was being refered to.

Recall that the we decided to go with Roberto's counter-proposal [1] which 
was based on the idea of using XSD to restrict wsdl:ServiceType and 
wsdl:Endpoint to have fixed values for @interface and @binding, and to 
transmit service references using the restricted wsd:ServiceType.

If you just want to say that a message contains a reference to another 
service and you don't want to contrains the interface or binding, then you 
directly re-use the wsdl:ServiceType in the message.

If you want to describe the interface of the service, then you create a 
new type that restricts the value of the @interface attribute to have a 
fixed value which is the QName of the interface. This works, e.g. 

If you also want to describe the binding of the service, then you create a 
new type that restricts the value of the @binding attribute of 
wsdl:EndpointType. You can do that, but there is no way you can actually 
use this type to restrict the <wsdl:endpoint> element. Here is a sample.

<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        elementFormDefault="qualified"
        targetNamespace=
"http://greath.example.com/2004/schemas/reservationDetails"
        xmlns:tns=
"http://greath.example.com/2004/schemas/reservationDetails"
        xmlns:wdetails=
"http://greath.example.com/2004/services/reservationDetails"
        xmlns:wsdl="http://www.w3.org/2004/08/wsdl">

        <import namespace="http://www.w3.org/2004/08/wsdl"
                schemaLocation="wsdl20-1.xsd" />


        <complexType name="ReservationDetailsEndpointType">
                <complexContent>
                        <restriction base="wsdl:EndpointType">
                                <attribute name="binding" type="QName" use
="required"
                                        fixed=
"wdetails:reservationDetailsSOAPBinding" />
                        </restriction>
                </complexContent>
        </complexType>

        <complexType name="ReservationDetailsServiceType">
                <complexContent>
                        <restriction base="wsdl:ServiceType">
                                <sequence>
                                        <element name="endpoint"
                                                type=
"tns:ReservationDetailsEndpointType" />
                                </sequence>
                                <attribute name="interface" type="QName" 
use="required"
                                        fixed=
"wdetails:reservationDetailsInterface" />
                        </restriction>
                </complexContent>
        </complexType>
</schema>

The problem is that within the <restriction> of wsdl:ServiceType, the 
<element name="endpoint" ...> refers the QName tns:endpoint, not 
wsdl:endpoint because we use elementFormDefault="qualified". This is 
actually a valid restriction since the content model of wsdl:ServiceType 
allows elements from other namespaces. However, this does not restrict the 
wsdl:endpoint element to have the fixed binding value. FYI, here is a 
chunk of a valid instance document according to this restricted service 
type.

        <reservation>
                <details:confirmationNumber>HSG635</
details:confirmationNumber>
                <details:checkInDate>2005-06-27</details:checkInDate>
                <details:checkOutDate>2005-06-28</details:checkOutDate>
                <details:reservationDetailsService
                        interface="wdetails:reservationDetailsInterface">
                        <details:endpoint name="SOAP"
                                binding=
"wdetails:reservationDetailsSOAPBinding"
                                address=
"http://greath.example.com/2004/reservation/HSG635"/>
                </details:reservationDetailsService>
        </reservation>

There is a fix however. The reason that we were able to restrict the 
attribute values is that they are unqualified. Therefore, if we changed 
our WSDL schema to use elementFormDefault="unqualified", and we ensured 
that <endpoint> was a local element, then we could restrict it. However, 
for consistency, we should probably also make the other nested elements 
unqualified, i.e. just keep the top-level elements (<interface>, 
<binding>, <service>, etc.) qualified. We can still have named complex 
types for all the elements though.

Transition history

raised on 28 Mar 2005 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 31 May 2005

1) Remove service reference section 2) Define wsdlx:interface/binding in part 1. These attributes are intended to be used as annotations. 3) Illustrate the use of URIs with these attributes in the Primer. 4) Make @name with service and endpoint types required. 5) Pass the hot potato to WS-Addressing 6) Find the potato handler from WSD wg

Acknowledgment cycle

announced by group on 9 Jun 2005

Action history

LC118: New Issue RPC Style (and proposed fix) [link to this issue]

As I am composing the RPC style example, I noticed that the order of the
elements in designating the signature is not preserved for the values of
the wrpc:signature which I believe is unintentionally missing. 
I recommend the following small fix for bullet numbered 2 in section
3.1.1:
Previous:

{2. Filter the elements of this list into two lists, the first one (L1)
comprising pairs whose t component is one of {#in, #out, #inout}, the
second (L2) pairs whose t component is #return.}
New: 
{2. Filter the elements of this list into two lists, the first one (L1)
comprising pairs whose t component is one of {#in, #out, #inout}, the
second (L2) pairs whose t component is #return. During the composition
of L1 and L2, the relative order of members in the original list MUST be
preserved.}
I think this should be non-contraversial.

Transition history

raised on 30 Mar 2005 by Yalcinalp, Umit (umit.yalcinalp@sap.com)

agreed on 22 Apr 2005

Accepted.

Acknowledgment cycle

announced by group on 20 May 2005

Action history

LC119: Misc Part1 editorial issues [link to this issue]

Misc Part1 editorial issues:

1. Typos:
s/modularize a a given component/modularize a given component/
s/unless the are imported/unless they are imported/

2. The mappings from the XML Infoset-->Component Properties are
unidirectional in WSDL 2.0 -- not bidirectional.  (We do not define a
mapping back from Component Properties-->XML Infoset.)  This should be
clearer whenever these mappings are mentioned.  Therefore, phrases like
(in sec 2.1.3):
[[
The mapping between the properties of the Description component (see
2.1.1 The Description Component) and the XML Representation of the
description element information item . . . .
]]
should be reworded to something like:
[[
The mapping from the XML Representation of the description element
information item to the properties of the Description component (see
2.1.1 The Description Component) . . . .
]]

This occurs in a quite a number of places, and should be corrected
throughout.  Here is another example:
[[
Table 2-1. Mapping between Description Component Properties and XML
Representation
]]
should be something like:
[[
Table 2-1. Mapping from XML Representation to Description Component
Properties
]]

3. In all of the Infoset-->Component Property mapping tables (such as
Table 2-1), I suggest changing the column headings from "Property" and
"Mapping" to something like "Property Name" and "Property Value (Mapping
from Infoset)", in order to be more clearly descriptive.

Transition history

raised on 4 Apr 2005 by David Booth (dbooth@w3.org)

agreed on 5 May 2005

Accept editor's resolution.

Acknowledgment cycle

announced by group on 20 May 2005

agreement by reviewer on 21 May 2005

Action history

LC120: Contradictions regarding transitivity of wsdl:import [link to this issue]

Statements in Part 1 about the meaning of wsdl:import appear to be 
contradictory.  On one hand, sec 4.2 says that wsdl:import is not 
transitive.  On the other hand, sec 2.1.1 says there is no difference 
between included/imported components and components derived directly from a 
WSDL 2.0 document, and this logically leads to import being transitive.

Suppose WSDL document A imports WSDL document B, which imports WSDL 
document C, which neither includes nor imports anything.  The components of 
C will be only the components derived directly from the XML Infoset of 
C.  Since B imports C, clearly the set of components for B will include the 
set of components for C.  So far so good.  But A now imports B, so what 
components will A have?  We have already established that the set of 
components of B includes the set of components from C as a subset.  Since 
there is no distinction made between the subset of components that 
originated in C and the other components, the components of A must 
therefore also include the components of C as a subset.  This contradicts 
the statement that "wsdl:import is not transitive".

The basic problem here is that the spec is referring to the *components* of 
the imported document.  Those components only exist if we interpret the 
meaning of the imported document according to the WSDL 2.0 specification, 
at which point there is no way to know whether those imported components 
originated in the imported document or another document (transitively).

Here are the relevant excerpts from the spec:

Part 1 sec 4.2 Importing Descriptions
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-type=text/html;%20charset=utf-8#imports
second paragraph says:
[[
Components in directly imported descriptions are part of the component 
model of the importing description. Directly imported means that component 
importation is not transitive; components imported by one of the imported 
documents are NOT available to the original importing document unless the 
are imported directly by that document.
]]

But section 2.1.1 The Description Component
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-type=text/html;%20charset=utf-8#Description_details
sixth paragraph says:
[[
The set of interfaces/binding/services/etc. available in the Description 
component include those that are defined within the component itself and 
those that are imported and/or included. Note that at the component model 
level, there is no distinction between directly defined components vs. 
imported/included components.
]]
Furthermore, sec 2.1.3 Mapping Description's XML Representation to 
Component Properties
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?
content-type=text/html;%20charset=utf-8#Description_Mapping
also shows no distinction between components that originated in the WSDL 
2.0 document and components that originated in an included/imported document.

Transition history

raised on 13 Apr 2005 by David Booth (dbooth@w3.org)

agreed on 21 Apr 2005

Add references to qname resolution and clarify that section; use Asir's text for 4.2.

Acknowledgment cycle

announced by group on 20 May 2005

agreement by reviewer on 21 May 2005

Action history

LC121: Editorial: Ambiguous use of the terms "include" and "import" [link to this issue]

Part 1 uses the words "include" and "import" in several places without 
being clear about whether they are referring to wsdl:include and 
wsdl:import or xs:include and xs:import.

In fact, these terms appear to be used in two different ways in the same 
table, in some cases referring to the wsdl: versions, and in other cases 
referring to the xs: versions.  For example, in the table in sec 2.1.3 
"Mapping Description's XML Representation to Component Properties"
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?
content-type=text/html;%20charset=utf-8#Description_Mapping
the entry for {type definitions} says:

         ". . . plus any imported type definitions . . .",

which (I think) is referring to xs:import, whereas the entry for 
{interfaces} says:

         ". . . plus any included or imported Interface components . . ."

which is referring to wsdl:include and wsdl:import.

I think it would be good to look throughout the document at how these terms 
are used, and disambiguate each usage, such as writing "included via 
wsdl:include" instead of simply "included".

Transition history

raised on 14 Apr 2005 by David Booth (dbooth@w3.org)

agreed on 19 May 2005

Accept editor's fix.

Acknowledgment cycle

announced by group on 20 May 2005

agreement by reviewer on 21 May 2005

Action history

LC122: Part 2 editorial issue: "binding" versus "binding extension" [link to this issue]

Part 2 sometimes uses the term "binding" when it should say "binding
extension".  A "binding" is a wsdl: construct that employs a particular
"binding extension", such as the WSDL 2.0 SOAP Binding Extension.

Also, typo:
Part 2 Sec 5: s/associated the message/associated with the message/

Transition history

raised on 18 Apr 2005 by David Booth (dbooth@w3.org)

agreed on 16 Jun 2005

Accept editor's resolution

Acknowledgment cycle

announced by group on 16 Jun 2005

agreement by reviewer on 17 Jun 2005

Action history

LC123: Another part 1 typo [link to this issue]

Part 1 Section 4.1: 
s/belonging the same target namespace/belonging to the same target
namespace/

Transition history

raised on 18 Apr 2005 by David Booth (dbooth@w3.org)

agreed on 5 May 2005

Accept editor's resolution.

Acknowledgment cycle

announced by group on 20 May 2005

agreement by reviewer on 21 May 2005

Action history

LC124: Support of evolution of messages described in Schema 1.0 [link to this issue]

Following our decision to retire Jonathan's issue to get a joint task  
force with the XML Schema WG, I took an action item to propose a new  
issue for extensibility/versioning for wsdl using schema 1.0 [1]:

Issue: Support for evolution of messages described in Schema 1.0

Description:
The XML Schema Working Group is currently collecting use cases for  
versioning [2] and are likely to provide support for more 'open content' 
in Schema 1.1. This direction is supported by members of the WSD WG 
who would like WSDLs using Schema 1.0 to be able to describe message 
contents which may compatibly evolve within a given namespace.

Describing messages with more open content in Schema 1.0, whilst  
possible, is an unnatural and difficult enough activity to be the subject 
of numerous articles and conference papers, some written by members 
of this WG, offering techniques for publishers to provide extensibility  
points in schemas. An author has to know in advance where content
will be added in the future; it's not possible to evolve schemas 
published by a third party, unless they have provided such extensibility
points. 

Abstract Proposal:
WSDL could define how a type description relates to a message, either  
specifically for schema 1.0 or through a "schemaProcessingStyle"
property.

That is a WSDL could describe how a schema processor should be employed  
when building or parsing messages. An example of such a processing 
style is a technique demonstrated by Henry Thompson [3] whereby the 
PSVI from a first pass validation of a message is processed to remove 
unexpected content from a message before validating the message again, 
thereby enabling more open message content.

Paul

[1]  
http://lists.w3.org/Archives/Public/www-ws-desc/2005Mar/att-0116/ 
20050331-ws-desc-minutes.html#action01

[2] http://www.w3.org/XML/2005/xsd-versioning-use-cases/

[3] Henry Thompson, XML2004 "Versioning made easy with W3C Schema":
http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0019.html
slides:
http://www.markuptechnology.com/XMLEu2004/

Transition history

raised on 15 Apr 2005 by Paul Downey (BT)

declined on 21 Jul 2005

Closed with no action.

Acknowledgment cycle

announced by group on 25 Jul 2005

LC125: Inconsistent Component Names [link to this issue]

I just complete the editorial work for LC107, which I believe does make 
the component model property names a lot easier to understand.

In the process of doing this, I noticed that our component names are a 
little inconsistent. We have 2 groups of 5 components, with parallel 
structures:

Interface
InterfaceFault
InterfaceOperation
MessageReference
FaultReference

Binding
BindingFault
BindingOperation
BindingMessageReference
BindingFaultReference

The odd men out are InterfaceFault and InterfaceOperation. It seems like 
the interface prefix is unnecessary. There are 2 ways to handle this:

Option 1: Drop Interface from InterfaceFault and InterfaceOperation

Interface
Fault
Operation
MessageReference
FaultReference

Option 2: Add Interface to MessageReference and FaultReference

Interface
InterfaceFault
InterfaceOperation
InterfaceMessageReference
InterfaceFaultReference


Option 1 has the benefit of brevity. I prefer this.

Option 2 has the benefit of complete consistency with the Binding 
components. The 2 sets are now related by s/Interface/Binding/

Transition history

raised on 18 Apr 2005 by Arthur Ryman (IBM)

agreed on 28 Apr 2005

Rename components "Interface, InterfaceFault, InterfaceOperation, *InterfaceMessageReference, *InterfaceFaultReference".

Acknowledgment cycle

announced by group on 20 May 2005

Action history

LC126: Clarification for wsdl:required attribute needed [link to this issue]

In review of the draft, it is not clear to me what we are assuming with
respect to the presence of an extension in WSDL without using
wsdl:required attribute. 

Do we assume that it is optional (i.e. wsdl:required="false"), or is it
undefined? In reading the section about mandatory extensions, it seems
that such extensions are assumed to be optional (since they are
definitely NOT marked with wsdl:required attribute and considered to be
non-mandatory per that section). If this is the semantics, I propose
that we include a clarification that the default value for the
wsdl:required attribute is false and extensions that appears in a WSDL
document are considered to be marked to be optional. If that is not the
intended semantics, I would like to know what it means to put an
extension in WSDL, not mark it required optional/required and what would
that tertiary logic implies? 

If I have missed a discussion and resolution on this, a pointer to the
resolution will be appreciated.

Transition history

raised on 29 Apr 2005 by Yalcinalp, Umit (umit.yalcinalp@sap.com)

agreed on 26 May 2005

Accept editor's resolution

Acknowledgment cycle

announced by group on 28 May 2005

Action history

LC127: Editorial Comment: wsdl:include [link to this issue]

Section 4.1 [1]

"The WSDL 2.0 include element information item allows for the separation of
different components of a service definition, belonging to the same target
namespace, into independent WSDL 2.0 documents which can be merged as
needed."

As you know, include mechanism is not about merging documents. Suggestion:
delete "which can be merged as needed".

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

PS: I believe that Roberto raised the same editorial issue in mid April.
Couldn't find the mail URI tho.

Transition history

raised on 4 May 2005 by Asir Vedamuthu (asirv@webmethods.com)

agreed on 19 May 2005

Accept editor's fix.

Acknowledgment cycle

announced by group on 20 May 2005

Action history

LC128: MEP template [link to this issue]

At some point, there was a comment asking for a template for Message
Exchange Patterns.  I'm working on the sample additional patterns for
the primer, and noticed the lack of guidance myself (although it's easy
enough to capture the pattern).  So, here's proposed text for a
template.  This could be included in: a) Adjuncts, as part of the
description of extensibility, or b) the primer, in section 5.4.4, as
additional guidance.

Pattern Name

This pattern consists of [number] message[s, in order] as follows:

  [enumeration, specifying, for each message] A[n optional] message:

    * indicated by a Message Label component whose {message label} is
'[label]' and direction is '[direction]'

    * [received from|sent to] ['some' if first mention] node [node
identifier]

This pattern uses the rule [fault ruleset reference].

An operation using this message exchange pattern has a {pattern}
property with the value '[pattern URI]'.

Note: the "received from" and "sent to" are always from the point of
view of the service, and participating nodes other than the service are
implicitly identified as the originators of or destinations for
messages in the exchange.

Transition history

raised on 5 May 2005 by Amelia A Lewis (alewis@tibco.com)

agreed on 12 May 2005

Accepted.

Acknowledgment cycle

announced by group on 20 May 2005

Action history