In Part 1, in section A.2.2 The Element Declaration Component, we can
read:
A.2.2 The Element Declaration Component
wsdl.elementDeclaration(element)
wsdl.elementDeclaration(element,system)
1. element is the {name} property of the Element Declaration component.
2. system is the absolute URI of the extension type system used for the
Element Declaration component. This parameter is absent if XML Schema
is the type system.
Note that a similar statement is done in section A.2.3 The Type
Definition Component.
Two comments:
- what's the system URI?
- why is it a URI and not an IRI?
I am confused about this system absolute URI. Where is it coming from?
Can we provide an example of a value when XML Schema is not in use?
Let's take our example of use of Relax NG or DTDs in Discussion of
Alternative Schema Languages and Type System Support in WSDL 2.0[1]. I
don't believe that we've defined such a URI.
I understand this to mean that if you use something else then XML
Schema for element or type definition, you need to provide a URI (BTW,
why not an IRI?) for identification with the fragment identifiers.
This needs to be clarified.
1. http://www.w3.org/TR/2005/NOTE-wsdl20-altschemalangs-20050817/

Action history

Arthur

A number of properties in Part 2 are optional, but their mapping from
XML says "otherwise empty", which means that that they would always be
present, but sometimes empty, which is different from not being
present.
I am proposing to remove this "otherwise empty" from the mapping for
the following properties to make them really optional:
- {soap fault subcodes}
- {soap action}
- {http location}
- {http error reason phrase}
- {http transfer coding}
This would mean replacing certain "if empty" in their definition by
"if not present".
{soap fault code} and {http error status code} suffer from the
same problem but should not as I mentioned in another issue I have
raised.

Action history

Hugo

This is an issue which has already been addressed (LC130[1]) and
editorially implemented incorrectly.
It therefore is editorial. Details follow.
Part 2's section 5.7 Binding Faults defines:
* {soap fault code} OPTIONAL. A xs:QName, to the Binding Fault
component. The value of this property identifies a possible SOAP
fault for the operations in scope. If this property is empty, no
assertion is made about the value of the SOAP fault code.
[...]
* wsoap:code OPTIONAL attribute information item
* A [local name] of code
* A [namespace name] of "http://www.w3.org/2005/08/wsdl/soap"
* A type of union of xs:QName and xs:token where the allowed token
value is "#any"
[...]
┌───────────────────────┬───────────────────────────────────────────────┐
│ Property │ Value │
├───────────────────────┼───────────────────────────────────────────────┤
│ │ The actual value of the code attribute │
│ {soap fault code} │ information item if present and if its value │
│ │ is not "#any"; otherwise empty. │
├───────────────────────┼───────────────────────────────────────────────┤
Why do we need "#any" as a possible value if the wsoap:code attribute
is optional?
It turns out that the resolution to LC130 was not properly
implemented:
* Jonathan Marsh <jmarsh@microsoft.com> [2005-06-04 01:08-0700]
> Issue LC130: Binding fault defaulting?
> RESOLUTION: wsoap:subcode and wsoap:code will be optional,
> wsoap:subcode and wsoap:code will allow #any as a token,
> missing attribute will map to #any in the component model,
> #any => no assertion is made about the value,
> http:code will be similarly modified.
-- http://lists.w3.org/Archives/Public/www-ws-desc/2005Jun/0003
wsoap:subcode, wsoap:code and whttp:code need to be revised to reflect
the correct resolution of LC130.
1. http://www.w3.org/2002/ws/desc/4/lc-issues/#LC130

Acknowledgment cycle

Action history

Hugo

Part 2's section 6.3 Default Binding Rules states:
* Accept headers. Standard HTTP accept headers (see section 14 of [IETF
RFC 2616]) MAY be used in an HTTP request. When constructing an HTTP
Accept header, the HTTP client MAY take into account the
expectedMediaType information (see [MTXML]) appearing on an output
message description to find out about the type of binary element
content which is expected to be sent by the HTTP server.
This hints that expectedMediaType may contain a list of media types
that may be used in an HTTP response.
However, we have defined an {http output serialization} property which
declares the one media type which is being used in the HTTP response.
So how does expectedMediaType come into play here? Do Accept headers
really do anything useful?
This needs to be clarified.
For background information, see the thread starting at [1].
Should we keep the text above, "appearing on an output message
description" needs to be crisply expressed in terms of components and
properties.
1. http://lists.w3.org/Archives/Public/www-ws-desc/2005Aug/0010.html

Kevin

Section 6.12.2 Relationship to WSDL Component Model reads:
{http authentication scheme} REQUIRED. xs:string to the Endpoint
component, corresponding to the HTTP authentication scheme used.
The valid values are "basic" for the "basic" authentication scheme
defined in [IETF RFC 2617], "digest" for the Digest Access
Authentication scheme as defined in [IETF RFC 2617], and "none"
for no access authentication.
It would be better to have:
A xs:token with one of the values basic, digest, or none.
and have this reflected in the schema.

Action history

Hugo

In Part 2's 6.12 Specifying HTTP Access Authentication, we have:
* {http authentication realm} REQUIRED. A xs:string to the Endpoint. It
corresponds to the realm authentication parameter defined in [IETF
RFC 2617]. If the value of the {http authentication scheme} property
is not "none", it MUST not be empty.
[...]
┌──────────────────────┬────────────────────────────────────────────────┐
│ Property │ Value │
├──────────────────────┼────────────────────────────────────────────────┤
[...]
│ │ The actual value of the │
│ {http authentication │ whttp:authenticationRealm attribute │
│ realm} │ information item; otherwise, "" (the empty │
│ │ value). │
└──────────────────────┴────────────────────────────────────────────────┘
Why do we have this property required and defaulting to an empty
string?
It seems to make more sense to have this property optional.
Here's a proposal for the property definition:
{http authentication realm}, OPTIONAL.
A xs:string. It corresponds to the realm authentication parameter
defined in [IETF RFC 2617]. If the value of the {http
authentication scheme} property is not "none", it MUST be present
and not empty.
and for its mapping:
The actual value of the whttp:authenticationRealm attribute
information item, if present.
This is related to another comment about optional properties
defaulting to empty values.

Transition history

Close issue with following resolution:
- make auth scheme and realm both optional
- auth scheme and auth realm properties exist together
- drop the value "none" from auth scheme values
- we use the default value of the attribute to provide the default value for realm (of "")
- editorial: clean up the wording of the "Relationship to WSDL Component Model" to properly use the word component and property correctly and carefully.

Action history

Hugo

Hi all,
a last call comment on the 2005 last call draft of the adjuncts:
I believe operation styles should mandate that the {message content
model} of the operation's messages is "#element". This applies to
sections 4.1, 4.2 and 4.3.
All the styles mandate that the content model be defined using an
element that is a sequence, so message content models #any, #none and
#other should probably be disallowed. I don't think we will lose any
useful functionality.

Action history

Hugo

Hi all,
a last call comment on the 2005 last call draft of the adjuncts:
Sections 5.3 and 6.3 say: "if the value of the {message content model}
property is "#any" then the payload MAY be any one XML element."
I believe this MAY actually hides a hard constraint, it seems that "MUST
be a single XML element" would be more correct.

Action history

Hugo

Section 3.3 contains statements about "schema components that use the
xs:anyURI simple type". Specifically mentioning this, and not
mentioning any other type, raises some doubt as to whether these
attributes may be used to annotate other types, particularly
EndpointReferences of type wsa:EndpointReferenceType. It would be
clearer either to drop the reference to xs:anyURI specifically (leaving
"schema components"), or to soften it to something more like "schema
components, for example those that use the xs:anyURI simple type."

Action history

Arthur

The comments below form part of the the WS-Addressing WG's review of the
WSDL drafts (WS-A WG Meeting 19th Sept 05). These comments refer to WSDL
SOAP binding Extension section in the Adjuncts document.
Regards,
Katy Warr
WSDL Adjuncts Section: 5.10.3 SOAP Header Block component
How does wsoap:header indicate required = true/false?
There does not appear to be a way to indicate that the service
(a) supports the header and the client may send it
VS
(b) supports headers and REQUIRES that the client use the described
header?
The mustUnderstand=true attribute part of <wsoap:header> indicates only
whether the mustUnderstand attribute must be set on the header (and not
whether it is mandatory for the client to send the header itself).

Transition history

Add a 'required' attribute to wsoap:header and whttp:header similar to wsoap:module and a 'required' property. Missing attribute maps to 'false'. When 'true' it means that the service expects the header to be there; when 'false' then the sender decides whether it should be there or not.

Action history

Hugo

WSDL Adjuncts Section 5.10.3 SOAP header block component
The following sentence switches between a SOAP Header Block representing 1
header and representing multiple headers.
"A SOAP Header Block component describes an abstract piece of header data
(message headers) that is associated with the exchange of messages between
the communicating parties. The presence of a SOAP Header Block component
in a WSDL description indicates that the service supports headers and MAY
require a Web service consumer/client that interacts with the service to
use the described header. Zero or more such headers may be used."

Action history

Hugo

I'm puzzled at the use of a special mechanism for importing XML schemas,
as discussed in 2.3.2. AFAIKS, the same effect can be had by just using
a simple xs:schema wrapper element:
<xs:schema>
<xs:import .../>
</xs:schema>
This is a cleaner approach than just in-lining the xs:import and
xs:include, since it minimizes the number of different ways of doing the
same thing. From the comment at the end of 2.3.1, it seems that there's
a misunderstanding of how schema operates here. As I understand it,
imported schema definitions become part of the schema and have the same
visibility as definitions made directly under the including schema. In
support of this interpretation, section 4.2.3 of Schema Part 1
(http://www.w3.org/TR/xmlschema-1/#composition-schemaImport) ends with:
The ·schema components·
<http://www.w3.org/TR/xmlschema-1/#key-component> (that is {type
definitions} <http://www.w3.org/TR/xmlschema-1/#type_definitions>,
{attribute declarations}
<http://www.w3.org/TR/xmlschema-1/#attribute_declarations>, {element
declarations} <http://www.w3.org/TR/xmlschema-1/#element_declarations>,
{attribute group definitions}
<http://www.w3.org/TR/xmlschema-1/#attribute_group_definitions>, {model
group definitions}
<http://www.w3.org/TR/xmlschema-1/#model_group_definitions>, {notation
declarations} <http://www.w3.org/TR/xmlschema-1/#notation_declarations>)
of a schema corresponding to a <schema>
<http://www.w3.org/TR/xmlschema-1/#element-schema> element information
item with one or more <import>
<http://www.w3.org/TR/xmlschema-1/#element-import> element information
items must include not only definitions or declarations corresponding to
the appropriate members of its [children]
<http://www.w3.org/TR/xml-infoset/#infoitem.element>, but also, for each
of those <import> <http://www.w3.org/TR/xmlschema-1/#element-import>
element information items for which clause 2
<http://www.w3.org/TR/xmlschema-1/#c-ims> above is satisfied, a set of
·schema components· <http://www.w3.org/TR/xmlschema-1/#key-component>
identical to all the ·schema components·
<http://www.w3.org/TR/xmlschema-1/#key-component> of *I*.
Given this, I don't see any possible reason why xs:imported components
of a schema would not be available for reference by QName in the WSDL.

Acknowledgment cycle

Action history

Kevin

This is *not* by any means a spec-ready proposal, but I'm sending it so
we can discuss general direction, and perhaps move forward modulo
editorial work.
5.11.3 Binding WSDL MEPs to SOAP MEPs
This section briefly describes the relationships between WSDL components
and SOAP 1.2 MEP properties as described in {SOAP 1.2 Part 2}. We
define these relationships for the WSDL {in-out} pattern bound to a SOAP
{request-response MEP} (as would be the case for a usual SOAP In-Out
operation). Extensions (such as {WS-Addressing}) MAY alter these
mappings.
5.11.3.1 The Client
As the client, the property
"http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role"
takes the value "RequestingSOAPNode".
The WSDL "In" message is mapped to the SOAP
"http://www.w3.org/2003/05/soap/mep/OutboundMessage" property.
The WSDL "Out" message maps to the SOAP
"http://www.w3.org/2003/05/soap/mep/InboundMessage" property.
5.11.3.2 The Service
As the service, the property
"http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role"
takes the value "RespondingSOAPNode".
The WSDL "In" message is mapped to the SOAP
"http://www.w3.org/2003/05/soap/mep/InboundMessage" property.
The WSDL "Out" message maps to the SOAP
"http://www.w3.org/2003/05/soap/mep/OutboundMessage" property.

Acknowledgment cycle

Action history

Hugo

Editorial: Primer | SOAP 1.1 Binding
In the Primer and SOAP 1.1 Binding, the bib ref to the Infoset points to
the original publication. Core and Adjuncts both correctly point to the
2nd edition. Request the entries consistently point to 2nd edition.

Asir

Section 2.20 Comparing URIs and IRIs in Part 1 references:
[TAG URI FINDING]
TAG Finding on URI Comparison, X. Foo, Y. Bar, Authors. W3C
Technical Architecture Group, Month, Year. Draft available at
http://www.textuality.com/tag/uri-comp-4.
This is a draft TAG finding, whose content is mainly identical to the
IRI spec's Simple String Comparison section, which is a much more
stable document.
Therefore, I would like us to use section 5.3.1. Simple String
Comparison of RFC 3987 as the normative way to compare IRIs in WSDL
2.0 documents.

Acknowledgment cycle

Action history

JJM

Comment about:
Web Services Description Language (WSDL) Version 2.0 Part 0: Primer
http://www.w3.org/TR/2005/WD-wsdl20-primer-20050803/
The primer talks exclusively about URIs. It should talk about IRIs
some. The primer is probably a good place to mention that for
internationalization purposes, WSDL 2.0 supports IRIs which are a
superset of URIs.
It might be useful to point to An Introduction to Multilingual Web
Addresses[1] which explains what IRIs are, how they differ from URIs,
why they exist, etc.
1. http://www.w3.org/International/articles/idn-and-iri/

Acknowledgment cycle

Action history

Kevin

Part 2 uses the concept of "IANA media type token"[1], but does not
define by value nor reference what it is exactly: a media type? a
media type with some parameters? As far as I can tell, or more
precisely as far as Google can tell, we are the only ones using this
denomination.
We should clarify this concept.
I believe that what we mean is:
The 'type "/" subtype' production as defined in section 5.1. Syntax
of the Content-Type Header Field of RFC 2045 Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet Message Bodies.
Reading this section, the media type is not necessarily registered
with IANA, so I would suggest changing the name to "media type token".
Note that this proposal deliberately leaves out the possibility of
using parameters, which I think is fine and is what we were after.
Cheers,
Hugo
1. http://www.w3.org/TR/2005/WD-wsdl20-adjuncts-20050803/#http-operation-decl-relate

Acknowledgment cycle

Action history

Hugo

The WS-A WG has added a statement "Pseudo schemas do not include
extensibility points for brevity" to their notational conventions [1].
Except for that new statement, that text is identical to ours [2]. I
believe it would be beneficial to add the statement to our notational
conventions section(s) as well.
I propose this be treated editorial and done prior to LC publication.
But if it doesn't happen we'll track it as an editorial issue during the
next LC.
[1]
http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-core.html
?content-type=text/html;%20charset=utf-8#notation
[2]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html#bnfp
seudoschemas

Hugo

This is an editorial comment which impacts both Part 1 and 2.
Part 1 says:
wsdlx
"http://www.w3.org/2005/08/wsdl-extensions"
Defined by this specification 3.3 Describing Messages that Refer
to Services and Endpoints.
Actually, only part of wsdlx is defined in this section, @wsdlx:safe
being defined in Part 2.
In Part 2, Table 1-1 lists a "wsdl-x" prefix. This should be "wsdlx".

Hugo

This is an editorial comment about Part 1.
Section 2.4.1 The Interface Operation Component states:
Note:
Despite having a {name} property, Interface Operation components cannot
be identified solely by their QName. Indeed, two Interface components
whose {name} property value has the same namespace name, but different
local names, can contain Interface Operation components with the same
{name} property value. Thus, the {name} property of Interface Operation
components is not sufficient to form the unique identity of an Interface
Operation component.
Since we're going through the effort of saying that you can't use
QNames to identify operations, we should add a reference to our
definition of fragment identifiers for WSDL documents, and more
specifically to appendix A.2.6 The Interface Operation Component.

Acknowledgment cycle

Action history

Arthur

Section 2.4.1.1 Operation Style in Part 1 states:
The WSDL Version 2.0 Part 2: Adjuncts specification [WSDL 2.0 Adjuncts]
defines the following operation style:
* RPC Style
Part 2 actually defines 3 styles. Either we should list them all, or
we should make a more general reference to Part 2 containing
predefined styles.

Acknowledgment cycle

Action history

Hugo

This is an editorial comment.
Section 4.1.2 XML Representation of the wrpc:signature Extension in
Part 2 states:
See Example 4-1 for a definition of this type.
We should change the mark-up as this is peculiar for an example to
define something in the spec.

Action history

Roberto

This is an editorial comment.
In Part 2, section 6.3 Default Binding Rules reads:
Note:
The application/x-www-form-urlencoded serialization format places
constraints on the stype of the interface operation bound (see 6.9.1
Serialization as application/x-www-form-urlencoded ).
There's a typo ("stype"), and it would be more precise to say:
The application/x-www-form-urlencoded serialization format places
constraints on the XML Schema definition of the {element
declaration} property of the Interface Message Reference components
of the Interface Operation component bound (see 6.9.1 Serialization
as application/x-www-form-urlencoded ).

Acknowledgment cycle

Action history

Hugo

LC324: HTTP binding: error in definition of queryParameterSeparatorDefault and queryParameterSeparator [link to this issue]

This is an editorial issue.
In Part 2, section 6.5 Specifying the Default HTTP Method defines the
{http query parameter separator} property.
Section 6.6.3 XML Representation reads:
The XML representation for binding an Operation are four attribute
information items with the following Infoset properties:
[...]
* An OPTIONAL queryParameterSeparatorDefault attribute information item
with the following Infoset properties:
* A [local name] of queryParameterSeparatorDefault
* A [namespace name] of "http://www.w3.org/2005/08/wsdl/http"
* A type of xs:string whose length facet value is "1"
Not four, but six AIIs are defined.
Moreover, it's not queryParameterSeparatorDefault which is on
operation, but queryParameterSeparator.
queryParameterSeparatorDefault should still be defined, though. Before
defining it, we need to decide where (see issue about "Editorial
reorganization for defaults").

Acknowledgment cycle

Action history

Hugo

This is a purely editorial comment.
In Part 2, section 6.10.3 XML Representation, defaultTransferCoding
should be transferCodingDefault.
Also:
The XML representation for specifying the transfer coding is an
OPTIONAL attribute information item with the following Infoset
properties:
Should be:
The XML representation for specifying the transfer coding is an
OPTIONAL attribute information item for the input, output, infault
and outfault EIIs with the following Infoset properties:

Acknowledgment cycle

Action history

Hugo

Hi all,
here are some (IMHO) editorial comments on WSDL2 part 1 2005 last call
draft (it's really nifty how both last calls fall on 3 Aug 8-) ):
1) section 6.1.1 on mandatory extensions talks about extensions,
features and properties being optional or mandatory. I believe all
mentions of properties should be dropped from this section as properties
cannot be made mandatory, AFAICS.
2) section 8 (Conformance) should have at least a short introductory
paragraph before 8.1 starts; and this paragraph could describe how
section 8 (Conformance) is different from 1.2 (Document Conformance).
3) MAY is IMHO overly capitalized in many places and should be
lowercased: 2.3.1 first capitalized MAY; 2.4.1 same; 2.4.1.1 same; last
in 2.9.1; first in 3.1; 3.1.2; 4.2.1; 7.1.
My rule of thumb is to capitalize MAY where a reader could reasonably
expect MUST NOT or SHOULD NOT, like "the property MAY be empty", but not
where the may is kinda obvious, like "XML Schema MAY be used [in WSDL]".
My reason for dropping the capitalization is to make it easier for the
reader - they won't need to stop and think about the significance of
this particular MAY (like "should I have expected otherwise for some
reason?")
4) 2.8.1.1 says "IRI MAY ... be associated with AT MOST one ..." - I
don't think we should use "MAY AT MOST" in the conformance sense here;
this should be rephrased to use the standard MAY/SHOULD/MUST and other
verbiage to describe the constraint.

Action history

Arthur

here are some (IMHO) editorial comments on WSDL2 part 2 (Adjuncts) 2005
last call draft:
1) MAY is IMHO overly capitalized in many places and should be
lowercased: 3.1 (thus the operation MAY or MAY NOT be safe 8-) ); 4.1.1;
first in Accept headers in 6.3; 6.8.1; ednote in 6.9.1.1; double curly
brace in 6.9.1.1
My rule of thumb is to capitalize MAY where a reader could reasonably
expect MUST NOT or SHOULD NOT, like "the property MAY be empty", but not
where the may is kinda obvious, like "XML Schema MAY be used [in WSDL]".
My reason for dropping the capitalization is to make it easier for the
reader - they won't need to stop and think about the significance of
this particular MAY (like "should I have expected otherwise for some
reason?")
2) in 5.9.2, in the bullet, the word "added" seems to be missing before
"to the Binding...", or something other is missing in that sentence.
3) section 5 in the beginning (fourth para) points out how no defaults
are provided for faults so if an interface contains faults, it must be
bound explicitly. That's no longer true since we made code and subcodes
optional; that fourth paragraph from section 5 should be removed.

Transition history

Accept addition of comma, {element} will be named {element declaration}, and check that this convention is adhered to elsewhere in the document, and the final sentence will be reworded for more clarity.

Acknowledgment cycle

Action history

Hugo

These are the comments I have on the WSDL 2.0 Primer, per the request
that the WS-Addressing WG review the WSDL 2.0 documents
1. Typos:
a. section 2.3 third para, first line: "either imported nor inlined"
should be "either imported or inlined".
b. section 2.4.4.1 last para under third bullet "provides examples for
the URI style and Multipart style" should be "provides examples for the
IRI style and Multipart style"
c. section 5.1 second para: "The context that a Web service may be
deployed" should probably be: "The context in which a Web service may be
deployed".
2. Section 5.3 contains repeated use of the term "endpoint reference" in
a sense which is not a WS-A EPR. It would be wise, particularly given
the references in 5.2 to WS-A, to make it very clear that the endpoint
reference described in 5.3 is not an End Point Reference. Or maybe a
different term would be better? Something like "endpoint URL" perhaps?
3. WS Addressing is not included in the References, despite being
mentioned in section 5.2.

Arthur

Hi all,
just an editorial comment - I find the current beginning of section 2 of
part 2 (Predefined Message Exchange Patterns) kinda nasty - introducing
the term node before any introductory text that even mentions "message
exchange".
I think it would help if the introduction of the section was
reformulated.

Acknowledgment cycle

Action history

Hugo

Part 1, Introduction [1] says - "The WSDL Version 2.0 Part 2: Adjuncts
specification [WSDL 2.0 Adjuncts] describes extensions for Message
Exchange Patterns, features, SOAP modules and bindings of features, and
a language for describing such concrete details for SOAP 1.2"
Part 2 does not define "features" or "bindings of features". The above
list should read "... extensions for Message Exchange Patterns, SOAP
modules, and a language for describing such concrete details for SOAP
1.2."
[1] http://www.w3.org/TR/2005/WD-wsdl20-20050803/#intro

Acknowledgment cycle

Action history

Hugo

Part 1 claims, "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." [1]
What is a valid WSDL 2.0 Component Model? Part 1 does not describe this.
[1] http://www.w3.org/TR/2005/WD-wsdl20-20050803/#markup

Action history

JJM

In sec. 2.1.2 you write: "The value of the targetNamespace attribute information item SHOULD be a dereferenceable IRI (see [IETF RFC 3987])." In sec. 2.1.2.1 you write: "The type of the targetNamespace attribute information item is xs:anyURI. Its value MUST be an absolute IRI (see [IETF RFC 3987])." Why do you have a SHOULD vs. a MUST? If the SHOULD is because of "dereferencable", I would propose: "The value of the targetNamespace attribute information item MUST be an IRI (see [IETF RFC 3987]) and SHOULD be dereferenceable."

Acknowledgment cycle

Action history

JJM

I am trying to get a clear understanding of what actually should be
declared as a fault in the WSDL. Looking at the various types of things
that could occur, some based on recent proposals, it appears there could
be:
1. Anomalies specific to the operation to be performed such as the
client failing to supply a mandatory value.
2. A generic anomaly such as the XML data supplied to the client being
malformed.
3. A generic anomaly such as the faults described in the WS-Addressing
proposal.
4. A generic anomaly such as an inconsistent SOAP envelope "Client"
soapFault ( Basic Profile R2724 ).
6. An HTTP 4xx error.
7. An HTTP timeout.
Should the WSDL only declare Faults for the cases covered by (1)? The
argument for this would be that the abstract WSDL defines the Operation
and others are generic, existing for all operations, and for 4, 5, and 6
the particular "faults" depend on the protocols of the bindings and if
multiple bindings were used would be different for each case.
The use of an In-Only mode for an operation would also appear to require
that the lower level faults are not explicitly declared for the
operation as that would appear to violate the rules for declaring an
In-Only operation.
For example say there is an op where the service reserves the right to
discard calls in busy periods without telling the client that a discard
has occurred. This is best defined in the WSDL as an In-Only MEP op.
Now Basic Profile R2724 still requires a SOAP fault be sent back if the
SOAP envelope is corrupt, even if you wanted to you can't decide not to
do this because the op is In-Only as the corruption may mean you can't
identify which op was invoked. So in the WSDL the op has no faults
because it is In-Only but in fact the consumer can receive SOAP faults (
and possibly WS-* faults ).
So this seems to me that there are explicit Faults declared for the
operation and implicit faults resulting from the binding to WS-*
protocols, SOAP and so on. There seem to be two issues here:
1. How are the implicit faults defined / listed? Should this be part of
the definition of the binding?
2. What about cases where WSDLs are used as input to toolkits, is there
a separate binding-independent set of explicitly declared Faults and a
concrete binding-dependent set of faults that have to be derived or put
in a derived concrete WSDL that can have Faults even in In-Only ops or
that converts the In-Only to an In-Optional-Fault pattern?
Any help in clarifying whether I am completely off track here would be
much appreciated.

Action history

Arthur

There are two comments about the definition of the {element} property
of a HTTP Header component.
== Error on types not allowed ==
In Part 2, section 6.3 Default Binding Rules reads:
* HTTP Header Construction. If the {http headers} property as defined
in section 5.10 Declaring SOAP Header Blocks exists and is not empty
in a Binding Message Reference or Binding Fault component, element
information item conforming to the element declaration of a HTTP
Header component's {element} property, in the {http headers}
property, MUST be turned into a HTTP header for the corresponding
message.
Only element information items of type xs:string or xs:anyURI may be
serialized. All complex data types are ignored. Attributes on data
elements are ignored.
Each such element information item is serialized as follows:
First, the reference should be 6.7 Declaring HTTP Headers and not 5.10
Declaring SOAP Header Blocks
Second, as we cannot serialize certain types of data, we shouldn't
encourage declaring HTTP header using an element that cannot be
used. We usually try to raised errors when we know there's a problem,
and we are not doing so here.
I therefore propose this new text for section 6.3 Default Binding
Rules:
HTTP Header Construction.
If the {http headers} property as defined in section 6.7 Declaring
HTTP Headers exists and is not empty in a Binding Message
Reference or Binding Fault component, HTTP headers conforming to
the {element} property of each HTTP Header component present MUST
be serialized as follows:
[ Keep the two existing rules here and add a following third one ]
* Attributes on the instance data element are ignored.
and to replace the current text in section 6.7 about the definition of {element}:
* {element}, REQUIRED. A xs:QName, a reference to an XML element
declaration in the {element declarations} property of the Description
component. This element represents a HTTP header.
the following:
{element}, REQUIRED.
A xs:QName, a reference to an XML element declaration in the
{element declarations} property of the Description component. This
element represents a HTTP header. The element information item
declared MUST be of the type xs:string or xs:anyURI.
== Types allowed ==
We restricted the serialization to xs:string or xs:anyURI.
1. What about types derived from xs:string, e.g. xs:token? How about
allowing:
"type xs:string or xs:anyURI, or of a derived type using those as a
base type definition."
2. Any reason for not allowing xs:int?

Transition history

Accepted Proposal 1 with the following amendments:
- make it clear that the types are restricted to simple types
- make it clear there are no angle brackets in the value (e.g. use lexical representation)
- include the description of how to make a HTTP name (Jacek's email at http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/0017.html) and put that in our schema
- for the value of the header reference the HTTP specs and say that this has to be followed (e.g. line length, escaping)

Acknowledgment cycle

Action history

Hugo

LC317: HTTP binding: Misalignment between IRI style and application/x-www-form-urlencoded serialization, and between Multipart style and multipart/form-data serialization [link to this issue]

In our previous last call, we went back and forth about the design of
the operation style (applying to an operation or a message?) and the
generality of the URI and Multipart styles (limited to in-out or
not?).
I am afraid that we ended up in a situation which isn't bulletproof.
However, it should be fairly simple to fix it.
== Issue ==
The IRI style, like all styles, applies to an operation. We made it
constrain the first message of the MEP in use in order not to
constrain it to in-out, in-only and robust-only unnecessarily in case
somebody wants to use it for say an out-in operation.
This constraint expressed in this style is for use for a serialization
as an IRI of the instance data, by the
application/x-www-form-urlencoded serialization. However, this
serialization talks about serializing an input message (section 6.9.1
Serialization as "application/x-www-form-urlencoded"):
This serialization format is designed to allow a Web service to
produce a IRI based on the instance data of input messages. It may
only be used for interface operation using the IRI Style format as
defined in 4.2 IRI Style.
With the current specification, you could use the IRI style an a
out-in operation, which would constrain the first message, the output
message, and use the application/x-www-form-urlencoded serialization
on the second message, the input message, which is not constrained
by our IRI style. This is broken.
The application/x-www-form-urlencoded can be used only for the
messages that are constrained by the IRI style, i.e. only for the
first message of an operation.
As a side note, I don't think that we mean to say limit the
serialization to a Web service; we should say "Web service or client".
== Proposal ==
Here is some new proposed text for section 6.9.1:
This serialization format is designed to allow a client or Web
service to produce an IRI based on the instance data of a message.
It may only be used when binding Interface Operation components
using the IRI Style format as defined in 4.2 IRI Style, i.e. this
serialization format may only be used to serialize the initial
message of an interface operation.
Specifically, for the HTTP binding defined in this section (6. WSDL
HTTP Binding Extension), "application/x-www-form-urlencoded" MAY be
used as a value for the {http input serialization} property of the
Binding Operation component, but MUST NOT be used as a value as a
value for the {http output serialization} or {http fault
serialization} properties.
And add the following to Table 6-3. Mapping from XML
Representation to Binding Operation component Extension Properties to
note that it's an error for {http output serialization} or {http
fault serialization} to use this value:
{http output serialization}
The actual value of the whttp:outputSerialization attribute
information item, if present; otherwise, the default value as
defined in 6.3 Default Binding Rules, computed based on the value
of the {http method} property. It is an ERROR for this property
to have the value "application/x-www-form-urlencoded" (see
section 6.9.1 Serialization as
"application/x-www-form-urlencoded").
{http fault serialization}
The actual value of the whttp:faultSerialization attribute
information item, if present; otherwise "application/xml". It is
an ERROR for this property to have the value
"application/x-www-form-urlencoded" (see section 6.9.1
Serialization as "application/x-www-form-urlencoded").
== Similar issue ==
A similar issue exists in section 6.9.3 Serialization as
"multipart/form-data", and similar text should fix the problem.

Action history

Hugo

Part 2 defines a number of new components: a SOAP Module component, a
SOAP Header Block component, a HTTP Header component.
All of those are nested components. Part 1 states:
The component that contains a nested component is referred to as the
parent of the nested components. Nested components have a {parent}
property that is a reference to their parent component.
-- http://www.w3.org/TR/2005/WD-wsdl20-20050803/#Description_details
It would be good to define a similar {parent} property for our nested
components in Part 2, especially as the concept of parent is used in
the IRI identification of those components.

Action history

Hugo

Hi all,
a last call comment on the 2005 last call draft of the adjuncts:
In both bindings, SOAP and HTTP, there are a number of attributes for
specifying defaults, like transferCodingDefault, mepDefault,
methodDefault etc. These attributes are used when constructing the
component model, but they only provide the defaults for the created
operation and message reference components, for example a binding
operation will get the default HTTP transfer coding if it doesn't
specify its own.
I don't think this will work the expected way for interfaceless
bindings, i.e. bindings that don't say what interface they bind. These
bindings don't contain any operations, so the defaults are not used and
are dropped. I'm not sure what is used for those affected properties
when the binding is used on an endpoint and thus indirectly connected to
the endpoint's service's interface.
I believe we should add component properties to carry these default
values in the component model.

Action history

Hugo

Hi all,
a last call comment on the 2005 last call draft of the adjuncts:
in our HTTP binding, we have a property {http error reason phrase} which
is IMHO unnecessary. The HTTP reason phrase is purely informative and
therefore it doesn't make much sense to specify what a service will use
for a particular fault.
To compare, we don't deal with fault reason in the SOAP binding, and I
raised a similar issue for WS Addressing (they mandated SOAP fault
reasons for their faults) and they decided to make their text the
recommended reason text, not the required one.
I believe we should drop whttp:reasonPhrase attribute and all the
corresponding property, {http error reason phrase}, from WSDL 2 HTTP
binding.

Acknowledgment cycle

Action history

Hugo

Hi all,
while working on the RDF binding, I've noticed an inconsistency in where
fault properties are placed in bindings:
SOAP binding puts wsoap:code and subcodes and wsoap:header on binding
fault, and the same does HTTP mapping with whttp:code and whttp:header.
This basically shows that most specific binding fault properties are put
on the bindings faults.
Inconsistently, HTTP binding puts whttp:transferCoding on the fault
reference within operations - do we have a use case for different
transferCodings for the same faults when used in different operations?
If not, I suggest that transferCoding is moved from operation/infault
and outfault to binding/fault.

Acknowledgment cycle

Action history

Hugo

In Part 1 we refer to the fault propagation
rulesets (FPR) by names like "message-triggers-fault" but these names are
not used in Part 2, i.e. Part 2 just says "Message Triggers Fault". Also,
FPRs are an extension point. Should we introduce IRIs for the FPRs? These
IRIs wouldn't appear in any WSDL 2.0 document. However, it seems
consistent to use IRIs for them since we do this for other extension
points. The MEP templates have a slot [fault ruleset reference] which
would be used to specify the IRI for the FPR. The obvious choices for the
IRIs are:
http://www.w3.org/2005/08/wsdl/fault-replaces-message
http://www.w3.org/2005/08/wsdl/message-triggers-fault
http://www.w3.org/2005/08/wsdl/no-faults
These would tie in better with the names we use in Part 1.

Action history

Hugo

Defaults in the bindings are inconsistently defined.
The bindings have:
- a default binding rules section:
5. WSDL SOAP Binding Extension
5.3 Default Binding Rules
6. WSDL HTTP Binding Extension
6.3 Default Binding Rules
- sections for other defaults:
5.6 Specifying the Default SOAP MEP
6.5 Specifying the Default HTTP Method
- other sections defining their own defaults:
6.6 Binding Operations
(defines queryParameterSeparatorDefault)
6.10 Specifying the Transfer Coding
(defines transferCodingDefault)
I would like to propose to have each @foobarDefault consistently
defined in its own subsection under 5.3 Default Binding Rules and 6.3
Default Binding Rules, or have them consistently defined in the
section where they're used for determining the value of a property
(like sections 6.6 or 6.10).
I prefer those two proposed solutions to having them as subsections of
the the binding definition (like 5.6 and 6.5) as I believe that it
gives as much important to setting a default, which does not directly
impact the component, as to say binding an operation, which is much
more substantial.

Action history

Hugo

I'm writing on behalf of DAWG, which is using WSDL 2.0 to specify the SPARQL
Protocol for RDF [1]. We have a couple of LC comments about WSDL 2.0, and
I'll be sending each one in a separate message. This message contains the
last LC comment we intend to raise at this time.
We have added a POST binding for our sole operation, query, because we
anticipate there being SPARQL queries, perhaps autogenerated ones, that are
too long to transmit reliably over GET, serialized into a URI. Therefore, we
added a POST binding, and we'd like the serialization of the input message
for that POST operation to be application/x-www-form-urlencoded. We do not
have an XML serialization of SPARQL's surface syntax, so that we cannot POST
application/xml.
As with our other two comments, we raise this because we'd like to use WSDL
2.0 to describe our service *accurately* and completely.
Cheers,
Kendall Clark
[1] http://www.w3.org/sw/2001/DataAccess/proto-wd/

Acknowledgment cycle

Action history

Hugo

In Part 1, section 2.1.3 Mapping Description's XML Representation to
Component Properties reads:
{type definitions}
The set of Type Definition components corresponding to all the type
definitions defined as descendants of the types element information
item, if any, plus any (via xs:include) or imported (via xs:import)
Type Definition components. At a minimum this will include all the
global type definitions defined by XML Schema simpleType and
complexType element information items. It MAY also include any
definitions from some other type system which describes the
[attributes] and [children] properties of an element information
item. It is an error if there are multiple type definitions for each
QName.
Why are simpleType and complexType called out here, and not element
for example?
I propose simplifying the second sentence:
At a minimum this will include all the global definitions defined by
XML Schema declarations.

Acknowledgment cycle

I was reading through the WSDL 2.0 primer. I see a new
addition where the fault is defined outside the
operation but inside the interface for reusability.
This logic can be extended for other messages as well
( input and output). Quite frankly it seems redundant
to declare the fault again inside the
interface. Fundamentally faults are no different than
output messages. Only thing the service provider responds
with it when the normal processing doesnt happen. They
should be treated like output messages. Declaring the
message type ( in schemas/types) and using it in the
Operation should be good enough similar to the other messages.

Acknowledgment cycle

attributeFormDefault value should be qualified at
http://www.w3.org/2005/08/wsdl/rpc.xsd because per Part 2 RPC Signature
Extension [1] is,
* A [local name] of signature
* A [namespace name] of "http://www.w3.org/2005/08/wsdl/rpc"
[1]
http://www.w3.org/TR/2005/WD-wsdl20-adjuncts-20050803/#InterfaceOperatio
n_RPC_Signature_XMLRep

Acknowledgment cycle

Comment on:
Web Services Description Language (WSDL) Version 2.0 Part 2:
Adjuncts
http://www.w3.org/TR/2005/WD-wsdl20-adjuncts-20050803/
and:
Web Services Description Language (WSDL) Version 2.0 SOAP 1.1
Binding
http://www.w3.org/TR/2005/WD-wsdl20-soap11-binding-20050803/
{soap action} is defined as a property of Binding Operation
component[4]:
{soap action} OPTIONAL. A xs:anyURI, which is an absolute IRI as
defined by [IETF RFC 3987], to the Binding Operation component.
The value of this property identifies the value of the SOAP
Action Feature (as defined for this specific operation), as
specified in the binding rules of bindings to specific versions
of SOAP (see 5.11.3 Default Binding Rules for the SOAP 1.2
binding when the value of the {soap version} property of the
Binding component is "1.2").
The SOAP 1.2 binding states[5]:
SOAP Action Feature. If a value for the {soap action} property of
a Binding Operation component has NOT been specified then the
SOAP Action Feature (see [SOAP 1.2 Part 2: Adjuncts]) has NO
value assigned by the Binding component. Otherwise, the value of
the {soap action} property of a Binding Operation component is
the value of the SOAP Action Feature for all messages of the
corresponding Interface Operation component.
The SOAP 1.1 binding states[6]:
The value of the {soap action} property identifies the value of
the SOAP 1.1 SOAPAction HTTP request header field, Section 6.1.1,
SOAP 1.1 specification [SOAP11].
I believe that this is the wrong granularity. The SOAPAction HTTP
header in SOAP 1.1[1] and the SOAP Action Feature in SOAP 1.2[2] are
properties of a message. It is unclear, as shown by WS-Addressing and
its wsa:Action[3] which has similar properties and motivations, that a
single action value can be applied to all the messages of an
operation in all cases.
I propose the following change: place {soap action} at the Binding
Message Reference, Binding Fault and Binding Fault Reference levels.
Editorially, I think the cleanest way is:
- remove the definition of {soap action} from section 5.8 Binding
Operations
- add a subsection called "5.9 Assigning SOAP Action values to
Messages" defining the {soap action} property on the Binding Message
Reference, Binding Fault and Binding Fault Reference components
- say in the SOAP 1.2 binding that the value of {soap action} sets the
value of the SOAP Action Feature of the corresponding SOAP message
or fault
- say in the SOAP 1.1 binding that the value of {soap action} sets the
value of the SOAPAction HTTP header for an HTTP Request; say that it
MUST be ignored in other cases (it's not explicitly said right now)
As a related editorial side note, the SOAP 1.1 binding also says[7]:
SOAP Action. If the Binding Operation component's {soap action}
property has NOT been specified, then the Binding component
assigns quoted string value to the SOAP 1.1 SOAPAction HTTP Header
Field (see [SOAP11]).
I assume that "quoted string" means "an quoted empty string ("")". If
not, I don't know what it means. It should be clarified.
1. http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383528
2. http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#ActionFeature
3. http://www.w3.org/TR/2005/WD-ws-addr-wsdl-20050413/#explicitaction
4. http://www.w3.org/TR/2005/WD-wsdl20-adjuncts-20050803/#property-BindingOperation.soapaction
5. http://www.w3.org/TR/2005/WD-wsdl20-adjuncts-20050803/#soap12-defaults
6. http://www.w3.org/TR/2005/WD-wsdl20-soap11-binding-20050803/#SOAP11
7. http://www.w3.org/TR/2005/WD-wsdl20-soap11-binding-20050803/#soap11-defaults

Action history

Hugo

Hi all,
a last call comment on the 2005 last call draft of the adjuncts:
Section 6.6.2 in adjuncts defines {http input serialization}, {http
output serialization} and {http fault serialization} to describe the
content type of the messages. It does so on the binding operation
component level. I believe the binding message reference and binding
fault reference components would be a better place for these properties;
and the current places could be dropped or they could carry defaults.
So instead of
<binding ...>
<operation ... whttp:outputSerialization="image/jpeg" />
</binding>
we'd have
<binding ...>
<operation ... >
<output whttp:serialization="image/jpeg" />
</operation>
</binding>
This would allow us to define different serializations for different
output messages (or different input messages or different faults).
Granted, none of our MEPs have multiple input messages or multiple
output messages, but there can always be multiple faults.
It doesn't seem to me that the current limitation to a single
serialization format for all inputs, other for all outputs and yet
another for all faults, is in any way useful. In fact, to me it seems
fairly strange.

Acknowledgment cycle

In Core: On reference of xs:anyURI: It would be good if you could mention that although xs:anyURI allows for IRIs (see LC74a), the mapping from IRI to URI in xs:anyURI is currently not defined in terms of IRI. This comment relates also for example to the reference of xs:anyURI in sec. 2.1.2.1 and sec. 3.1.2.1, and to the Adjuncts specification.

Transition history

Add "Note: The xs:anyURI type is defined so that xs:anyURI values are essentially IRIs [RFC 3987]. The conversion from xs:anyURI values to an actual URI is via an escaping procedure defined by [XLink 1.0], which is identical in most respects to IRI Section 3.1. For interoperability, WSDL authors are advised to avoid the characters "<", ">", '"', space, "{", "}", "|", "\", "^", and "`", which are allowed by the xs:anyURI type but disallowed in IRIs.

Action history

JJM

A few typos courtesy of Marc:
Section 2, first paragraph after note: "define the sequence and of
abstract messages" should be "define the sequence of abstract messages"
Section 5.10.1: "ond" should be "and"
Section 5.11.2:
"extension of the 5." should be either "extension of 5." or "extension
of section 5."
"patterns defined in 2." should be "patterns defined in section 2"
"patterns defined in 6." should be "patterns defined in section 6.6"
Section 5.9.1: "it is permissible for specification interaction to
engage" is very strange wording. I don't really have an alternative but
wanted to call attention to it.
Section 6.3 first note after table 6-1: "stype" should be "type"

Action history

Hugo

Hi,
I'd just like to point out a few minor errors in the 2005/08 versions of the adjunct schema for both SOAP and HTTP.
SOAP: Typo: mustUnderstnad -> mustUnderstand
HTTP: There is no declaration for the 'wsdl:' NS prefix.
The type for reasonPhrase is xs:int; it should be xs:string.

Action history

Hugo

WS-Desc,
I'm writing on behalf of DAWG, which is using WSDL 2.0 to specify the SPARQL
Protocol for RDF [1]. We have a couple of LC comments about WSDL 2.0, and
I'll be sending each one in a separate message.
We'd like to avoid having to require a particular fault serialization type
in our HTTP bindings. That is, we anticipate SPARQL services being free to
serialize fault messages in several different Media Types: plain text, HTML,
XML, RDF, etc.
If whttp:faultSerialization is a required property and the default value
doesn't describe our service, what alternative do we have?
Hugo Haas responded to my initial comments thus:
Maybe the fault serialization should be a property of the Binding Fault
and Binding Fault Reference components, rather than of the Binding
Operation, which would solve your problem.
There may be other design choices as well.
Cheers,
Kendall Clark
[1] http://www.w3.org/sw/2001/DataAccess/proto-wd/

Transition history

Copy the content of section 2.2 of the Describing Media Types for Binary Content note (a product of this WG) into part two, AND
point the definition of whttp:inputSerialization, whttp:outputSerialization, and whttp:faultSerialization at that definition, AND
check other references to these serialization properties to insure that they do not improperly restrict serialization to a single mime type.

Action history

Hugo

WS-Desc,
I'm writing on behalf of DAWG, which is using WSDL 2.0 to specify the SPARQL
Protocol for RDF [1]. We have a couple of LC comments about WSDL 2.0, and
I'll be sending each one in a separate message.
In short, we'd like to have multiple values for {http output serialization}.
Well, in truth, multiple values, or some kind of MIME wildcard, or allow
that component to be optionally declared. (FWIW, I believe this issue is
related to LC323 but not identical.)
Our situation is that our protocol qua service has one interface,
SparqlQuery, and one operation, query. That operation takes a SPARQL query
and returns the results of that query. Nice, neat, and simple.
However, SPARQL queries may return different MIME types, including
application/sparql-results+xml, application/rdf+xml, as well as different
serializations of RDF (N3, Turtle, N-Triples).
We also have a POST binding for query in order to submit In Messages that
are so long as to not reliably be serializable over a GET.
If we had to declare a different operations, the total number would become
really unwieldy -- I think the total number would be 10 (number of
serialization formats, 5, times the number of HTTP methods, 2 -- eek! And,
FWIW, this will only get worse if future DAWG adds other interfaces or
operations, with the same blowup of operations. Very unwieldy!)
Much simpler, and more descriptively accurate, to be able to say:
<operation ... whttp:outputSerialization="application/sparql-results+xml,
application/rdf+xml...">
or
<operation ... whttp:outputSerialization="*/*">
Cheers,
Kendall Clark
[1] http://www.w3.org/sw/2001/DataAccess/proto-wd/

Acknowledgment cycle

This email collects several minor editorial points regarding the WSDL
Core specification, some more minor than others. I apologize for the
somewhat late submission, which was due to several extraneous
circumstances too tedious to mention.
1) In the paragraph at the beginning of section 1.3 ending "... the
functionality implied by that extension is only optional to the
client. But it needs to be supported by the Web Service." the
last sentence might better read "It must be supported by the Web
Service."
2) In section 2.3.1, the paragraph beginning "Note that faults other
than the ones described in the Interface ..." seems like more than
a mere note.
3) In the same section, the rather long note beginning "Despite
having a {name} property, Interface Fault components cannot be
identified ..." seems to say, basically, that separately included
interfaces must be consistent with each other to the extent they
overlap. If this is so, something to the effect of "In other
words, interfaces must be consistent where they overlap." might
make the situation clearer. Also, my first reaction to this was
"Ah, the diamond inheritance problem." But diamond inheritance is
not a problem, since the shared ancestor is automatically
consistent with itself (see the note on idempotency below). If
I've got this right, it might be worth noting.
4) The above note appears in very similar form in other sections.
I'm sure that factoring this out has been suggested, but for what
it's worth, I'd like to weigh in in favor of having at least the
bulk of it appear only once, possibly with a short reference where
the mostly-repeated text presently appears
5) In section 2.4.1.1, in "... the rules implied by that IRI (such as
rules that govern the schemas) MUST be followed or it is an
error", it was not clear to me what exactly should happen should
this error occur. The text appears to mean that the combination
simply would not work, just as in-scope properties with an empty
intersection won't work. The question here is, what entity, if
any, needs to report this error (and how, etc.). Also, the net
effect of all this seems to be the conjunction of the (possibly
empty) set of constraints specified by the IRIs, but the
separation into cases obscures this somewhat. If there is a
general agreement that this paragraph could be made clearer, I
would be willing to attempt a clearer wording.
6) In section 2.7.1, second paragraph. Consecutive sentences start
with "Thus," and "Hence," This might flow better as "Thus, by
definition, every SOAP 1.2 abstract feature is also a WSDL 2.0
feature, and there is no need to define a separate WSDL 2.0
feature ..."
7) In section 2.8.1, first paragraph, the last sentence asserts
"Properties, and hence property values, can be shared amongst
features/bindings/modules, and are named with IRIs precisely to
allow this type of sharing." This seems to emphasize that the
names are not QNames, but it wasn't apparent to me why QNames
wouldn't have worked equally well. I have the distinct feeling
the answer is blindingly obvious and I'm just missing it.
8) In 2.8.1.1, the paragraph beginning "Many of the component types
in the component model contain a {properties} property ..."
produced parse errors on the first couple of readings. The root
problem is that "property" is badly overloaded, at least in this
context. Unfortunately, it's not clear how to avoid this
painlessly, as both senses of "property" are integral to the
spec. The upshot seems to be to distinguish between properties
(in the F&P sense) that are directly attached (declared
properties) and all applicable properties, whether directly
attached or pulled in by composition (in-scope properties). If
this is the intent, the wording could be clearer (and again, I
could probably have a go at rewording it).
9) In 2.9.1, paragraph 6, the text "Thus, it is an error for a
binding component not to define bindings ..." again leads me to
wonder what reports the error and when. Also, the "Thus," made me
wonder if I'd missed a step (quite likely).
10) In 2.9.2, in the XML representation of Binding components, the
word "whgse" was clearly inserted to test whether reviewers were
awake. I'm happy to report that I might well be.
11) Section 2.11.2.2 seems like boilerplate in the same sense as the
note on inheritance and overlap mentioned above.
12) In the tables in sections 2.12.3 and 2.13.3, the descriptions of
{interface message|fault reference}seem rather lengthy for a table
entry. And again, they seem to be near duplicates. The general
problem with such duplication is of course that it's hard to tell
without careful inspection what's duplicated and what's not.
13) In section 2.15.1, the {address} is given as optional. Is there
any guidance on when one might want to not include it?
14) In section 2.17, the definition of equivalence is oddly
asymmetric. Speaking as a math major, I'd be more comfortable if
"and the second component has no additional properties" were
simply "and vice versa." Similarly, "set-based values are
considered equivalent if they contain corresponding equivalent
values, without regard to order." feels a bit odd since on the one
hand, sets are unordered by definition, and on the other hand they
are also duplicate-free by definition but this is not mentioned.
I might reword this as "Set-based values are considered equivalent
if for each value in the first, there is an equivalent value in
the second, and vice versa," parallel with the proposed rewording
for components as a whole (and the usual set-theoretic definition
that each is a subset of the other).
15) In the same section, in the first bullet point (simple types),
does "contain the same value" mean "contain the same actual value"
in the XSD sense? If not, what does it mean?
16) In section 2.19, first paragraph, a "tuple, consisting of two
parts" is generally called an "ordered pair".
17) In the following paragraph, "QName references are resolved by
looking in the appropriate property," the appropriate property
should be spelled out, even if the result is a bit tedious.
18) In 4.1, the paragraph beginning "A mutual include is direct
inclusion by one WSDL 2.0 document of another WSDL 2.0 document
..." the upshot seems to be that inclusion is idempotent (because
a component is equivalent to itself and so multiple inclusion
doesn't redefine anything). It would be better either to mention
idempotency explicitly, or, perhaps better, to rephrase this
paragraph in terms of the transitive closure (which is mentioned
earlier) to explain that everything in the transitive closure of
the inclusion relation is thrown into the same flat space.
19) In section 4.1, the location attribute doesn't have to be
dereferenceable, but this may lead to unresolvable QNames down the
line. It would be nice to say that implementations SHOULD report
broken location links as a root cause of the QName failures they
cause, assuming that this is not burdensome to determine.
20) A.3 (security considerations) is remarkably short. This is just a
comment -- I don't think it needs to be lengthened.

Close with no action (this paragraph has already been revised somewhat).

Close with no action (too disruptive at this time).

Implement proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2005Oct/0040.html, plus these amendments:Proposed sentence: "This additional information in no way affects the messages exchanged with the service and ..."s/by the interface message reference components of the/in/"If no Operation component can simultaneously satisfy all of the styles, the document is invalid."Update URI to IRI.Section 2.4.1.2 needs to be amended to include Faults and to not just be applied to the {element declarations} but to the actual components since the style MAY be dependent on direction or possibly sequence.

Arthur

Consider a service that takes a URI and returns a picture.
Input message:
<element name="input">
<complexType>
<sequence>
<element name="id" type="xsd:string"/>
</sequence>
</complexType>
</element>
Output message:
<element name="output">
<complexType>
<sequence>
<element name="image" type="xsd:base64"
xmime:expectedContentType="image/*"/>
</sequence>
</complexType>
</element>
Operation:
<operation name="gimme-image"
style="style/iri style/one-binary-thing">
<input message="tns:input"/>
<output message="tns:output"/>
</operation>
Note that the use of the style "style/iri" on /operation effectively
constrains the input element. The addition of the style
"style/one-binary-thing" constrains the output schema to be of the
pattern above: exactly one child in the sequence and it must be declared
as xsd:base64 along with the xmime:expectedContentType attribute.
And now the all important binding:
<binding name="foo" interface="..">
<operation name="gimme-image" whttp:operation="GET"
whttp:outputSerialization="image/jpg"/>
</binding>
When we document the "one-binary-thing" style we say that that if that
style is used then the output serialization must be set to something
that conforms to the expected content type given in the schema.
This obviously needs to be spec'ized to become real, but is it really
that simple?
Sanjiva.

Acknowledgment cycle

Regarding...
C. IRI References for WSDL 2.0 Components
http://www.w3.org/TR/2005/WD-wsdl20-20050803/#wsdl-iri-references
Those URIs are much more complicated than they need to be:
http://example.org/TicketAgent.wsdl20#xmlns(xsTicketAgent=http://example.org/TicketAgent.xsd)
wsdl.elementDeclaration(xsTicketAgent:listFlightsRequest)
In the simple case, if there's only one component named CN in
a namespace TNS, then TNS#CN should be a standard URI for it.
e.g. given
targetNamespace="http://www.w3.org/2005/08/sparql-protocol-query"
and
<interface name="SparqlQuery"
Then we should be able to use
http://www.w3.org/2005/08/sparql-protocol-query#SparqlQuery
to refer to that interface.
FYI, I think Henry made this argument in the TAG
regarding issue abstractComponentRefs-37
http://www.w3.org/2001/tag/issues.html?type=1#abstractComponentRefs-37
... for example at our june meeting.
http://www.w3.org/2001/tag/2005/06/14-16-minutes.html#item031
Henry should get only credit, not blame, in case I'm misrepresenting
his position.
See also similar comments on XML Schema component designators...
simple barenames for schema component designators 31 Mar 2005
http://www.w3.org/2002/02/mid/1112297140.32006.540.camel@localhost;list=www-xml-schema-comments
p.s. thanks to Bijan for helping me find the relevant part of the spec
in IRC discussion
http://www.ilrt.bris.ac.uk/discovery/chatlogs/swig/2005-09-09#T19-51-41