This is the second last call issues list for:
And the last call issues list for:
Please send comments about those documents to the public-ws-desc-comments@w3.org mailing list (see public archive).
Also see the first Last Call Issues List.
Issues list for other deliverables of the WG can be found on the WS Description WG Issues List.
This document is live and can change at any time.
Color key: error warning note
Id: Title | State | Type | Open actions | Ack. |
---|---|---|---|---|
LC311 : What is the extension type system URI? | agreed | clarification | No reply from reviewer | |
LC313 : Part 2: Mapping from XML Representations to Component Properties | agreed | clarification | No reply from reviewer | |
LC319 : SOAP and HTTP binding: definition of {soap fault code} and wsoap:code | agreed | clarification | No reply from reviewer | |
LC323 : HTTP binding: Use of HTTP accept headers | agreed | clarification | No reply from reviewer | |
LC326 : HTTP binding: whis is {http authentication scheme} an xs:string? | agreed | clarification | No reply from reviewer | |
LC327 : HTTP binding: {http authentication realm} is required | agreed | clarification | No reply from reviewer | |
LC330 : WSDL 2: operation styles should mandate content model | agreed | clarification | No reply from reviewer | |
LC331 : WSDL 2: adjuncts description of #any msg content model unclear | agreed | clarification | No reply from reviewer | |
LC336 : LC ISSUE from WSA: Clarify applicability of wsdx:Interface and wsdx:Binding | agreed | clarification | No reply from reviewer | |
LC339 : Comments on WSDL SOAP Binding Extension section of Adjuncts from WS-Addressing WG | agreed | clarification | No reply from reviewer | |
LC340 : Comments on WSDL SOAP Binding Extension section of Adjuncts from WS-Addressing WG | agreed | clarification | No reply from reviewer | |
LC343 : Comments on Web Services Description Language (WSDL) Version 2.0 Part 0: Primer | agreed | clarification | No reply from reviewer | |
LC363 : WSDL message to SOAP message mapping | agreed | clarification | No reply from reviewer | |
LC300 : Infoset refs | agreed | editorial | No reply from reviewer | |
LC302 : URI comparison reference | agreed | editorial | No reply from reviewer | |
LC303 : Mention IRIs in the primer | agreed | editorial | No reply from reviewer | |
LC304 : Definition of a IANA media type token | agreed | editorial | No reply from reviewer | |
LC305 : Notational conventions | agreed | editorial | No reply from reviewer | |
LC306 : Definition of the wsdlx namespace | agreed | editorial | No reply from reviewer | |
LC308 : Identification of an interface operation | agreed | editorial | No reply from reviewer | |
LC309 : Incomplete list of operation styles in Part 1 | agreed | editorial | No reply from reviewer | |
LC310 : Part 1: use of ws namespace prefix | agreed | editorial | No reply from reviewer | |
LC312 : Predefined MEPs: typo in the definition | agreed | editorial | No reply from reviewer | |
LC314 : Part 2: introduction is incomplete | agreed | editorial | No reply from reviewer | |
LC316 : RPC style: an example defines a type | agreed | editorial | No reply from reviewer | |
LC322 : HTTP binding: Part 2 section 6.3 Default Binding Rules clarification | agreed | editorial | No reply from reviewer | |
LC324 : HTTP binding: error in definition of queryParameterSeparatorDefault and queryParameterSeparator | agreed | editorial | No reply from reviewer | |
LC325 : HTTP binding: defaultTransferCoding typo | agreed | editorial | No reply from reviewer | |
LC328 : editorial comments on WSDL 2 part 1 last call draft | agreed | editorial | No reply from reviewer | |
LC329 : editorial comments on WSDL 2 part 2 - adjuncts - last call draft | agreed | editorial | No reply from reviewer | |
LC341 : Comments on WSDL SOAP Binding Extension section of Adjuncts from WS-Addressing WG | agreed | editorial | No reply from reviewer | |
LC346 : Comments from WS-A on WSDL 2.0 documents | agreed | editorial | No reply from reviewer | |
LC349 : editorial: part 2 section 2 beginning | agreed | editorial | No reply from reviewer | |
LC350 : Editorial: Part 1, Introduction | agreed | editorial | No reply from reviewer | |
LC351 : Editorial: Part 2, XML Namespace Table | agreed | editorial | No reply from reviewer | |
LC353 : What is a valid WSDL component model? | agreed | editorial | No reply from reviewer | |
LC354 : typo in http://www.w3.org/TR/wsdl20/#rfc2119keywords | agreed | editorial | No reply from reviewer | |
LC355 : Error in Part 2, BindingFault | agreed | editorial | No reply from reviewer | |
LC356 : Comments on WSDL 2.0 (Core, Adjuncts, Soap 1.1 Binding) from the i18n core wg (2) | agreed | editorial | No reply from reviewer | |
LC358 : Comments on WSDL 2.0 (Core, Adjuncts, Soap 1.1 Binding) from the i18n core wg (4) | agreed | editorial | No reply from reviewer | |
LC361 : What should be declared as a Fault in a WSDL | agreed | editorial | No reply from reviewer | |
LC315 : HTTP binding: HTTP Header component's {element} property's declaration | agreed | error | No reply from reviewer | |
LC317 : HTTP binding: Misalignment between IRI style and application/x-www-form-urlencoded serialization, and between Multipart style and multipart/form-data serialization | agreed | error | No reply from reviewer | |
LC320 : SOAP and HTTP bindings: {parent} property for nested components | agreed | error | No reply from reviewer | |
LC321 : SOAP binding: clarify that the lack {soap mep} value is an error | agreed | error | No reply from reviewer | |
LC333 : WSDL 2: binding defaults not component model properties? | agreed | proposal | No reply from reviewer | |
LC334 : WSDL 2: HTTP binding error reason phrase unnecessary | agreed | proposal | No reply from reviewer | |
LC359 : binding fault property placement inconsistencies | agreed | proposal | No reply from reviewer | |
LC362 : Re: new section 2.4.1.1 | agreed | proposal | No reply from reviewer | |
LC318 : SOAP and HTTP bindings: Editorial reorganization for defaults | agreed | request | No reply from reviewer | |
LC345 : POST & application/x-www-form-urlencoded serialization | agreed | request | No reply from reviewer | |
LC307 : Description's {type definitions} mapping | declined | clarification | No reply from reviewer | |
LC347 : Interface definition | declined | error | No reply from reviewer | |
LC352 : Bug in RPC Signature Extension Schema | declined | error | No reply from reviewer | |
LC301 : {soap action} granularity | declined | proposal | No reply from reviewer | |
LC332 : WSDL 2: HTTP input, output, fault serialization in the wrong place | declined | proposal | No reply from reviewer | |
LC357 : Comments on WSDL 2.0 (Core, Adjuncts, Soap 1.1 Binding) from the i18n core wg (3) | agreed | clarification | Agreement | |
LC342 : Typos (Adjuncts) | agreed | editorial | Agreement | |
LC348 : Minor errors in adjunct schema | agreed | editorial | Agreement | |
LC337 : fault serialization | agreed | proposal | Agreement | |
LC338 : limitations of {http output serialization} | agreed | proposal | Agreement | |
LC344 : LC ISSUE: Editorial points | declined | editorial | Agreement | |
LC360 : describing a service that returns an image/jpg (for example) | declined | request | Agreement | |
LC335 : simple case of IRIs for Components in WSDL 2.0 | declined | proposal | Objection |
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/
Add clarification that the URI for the extension is the namespace URI, and this URI can be an IRI.
Implement above fix.
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.
Implement above fix.
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
Proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/0012.html accepted.
Implement above resolution.
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
Accept Hugo's proposal in http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/0043.html.
Implement above resolution.
Some primer work involved in this resolution.
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.
Proposal accepted.
Implement above resolution.
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.
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.
Implement above resolution.
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.
Proposal accepted.
Implement above resolution.
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.
Accepted.
Implement above resolution.
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."
Second proposal accepted (softening), plus mention WS-A EPRs here.
Implement above resolution.
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).
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.
Implement above resolution.
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."
Correct the plurals editorially, replace 0 or more with 0 or 1.
Implement above resolution.
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.
Agreed to add a note at the bottom of table that points out that WSDL 2.0 is different that common 1.1 usage patterns. Also adding a negative example.
Implement above resolution.
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.
Proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2005Nov/0022.html accepted, plus sentence on extensions from original proposal.
Implement above proposal.
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.
Accepted.
Implement above fix in Primer.
Implement above fix in SOAP 1.1 Binding.
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.
Implement above fix.
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/
Proposal and amendmentaccepted, in a new subsection.
Implement above resolution.
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
Implement proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2005Oct/0063.html.
Implement above resolution.
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
Proposal adopted.
Implement parts 2, 3, 4 of above resolution.
Implement parts 6, 7, 8 of above resolution.
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".
wsdlx is defined in Core, extended in Adjuncts. Editorial clarifications as necessary to explain this will be made. Hyphen removed as well.
Implement above fix in Part 1.
Implement above fix in Part 2.
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.
Accept in this case, and any other similar cases.
Implement above fix.
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.
Accept a general reference rather than a list.
Implement above fix.
Editorial: Part 1 uses a ws namespace prefix, apparently mainly for ws:import, which is not defined anywhere.
Accept removal of "ws:" prefix and make sure each use of import is clear in scope (section 4.2, elsewhere).
Implement above fix.
This in an editorial comment. Section 2. Predefined Message Exchange Patterns states: Web Services Description Language (WSDL) message exchange patterns (hereafter simply 'patterns') define the sequence and of abstract messages listed in an operation. This should be "sequence and cardinality".
Implement above fix.
This is an editorial comment. Part 2's introduction gives an overview of the document, but doesn't list section 3. This should be fixed.
Implement above fix.
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.
Add the wrpc namespace to table 1-1; in section 4.1.2, insert "excerpt" to clarify that this is not the full normative description.
Implement above fix.
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 ).
Implement above fix.
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").
Implement above resolution.
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:
Implement above fix.
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.
Accepted.
Implement above resolution.
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.
Drop paragraph as requested.
Implement above resolution.
WSLD Adjuncts Section 5.3 (Default Binding rules) Minor comment - comma required after the word 'transmitted' aids understanding of this sentence. Payload Construction. When formulating the SOAP envelope to be transmitted the contents of the payload (i.e., the contents of the SOAP Body element information item of the SOAP envelope) MUST be what is defined by the corresponding Interface Message Reference component. WSDL Adjuncts Section 5.10.3 SOAP Header Block component "{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 SOAP header block." "This element represents a SOAP Header block" is confusing - it refererences the SOAP hdr block representation but doesn't represent it itself.
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.
Implement above resolution.
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.
All typos assigned to the editors. Editors to fix endpoint references. LC346 - #3, add WS-A reference.
Implement above resolutions.
Arthur to reword references in 5.3 to avoid confusing WS-addressing endpoint references
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.
Swap first paragraph fro 1st 2 sentences of 2nd para.
Implement above resolution.
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
Accepted.
Implement above resolution.
XML Namespace "http://www.w3.org/2005/08/wsdl/rpc" is missing in table 1-1 [1]. [1] http://www.w3.org/TR/2005/WD-wsdl20-adjuncts-20050803/#notcon
Accepted.
Implement above resolution.
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
Implement proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2005Nov/0008.html.
Implement above resolution.
EQUIRED/REQUIRED
Proposal accepted.
Implement above resolution.
In Part 2 section "2.10.3 Mapping Binding Fault's XML Representation to Component Properties" table 2-10 has an error: {interface fault} The Interface Component corresponding to the actual value of the ref attribute information item. should say: {interface fault} The InterfaceFault Component corresponding to the actual value of the ref attribute information item.
Proposal accepted.
Implement above resolution.
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."
Proposal accepted.
Implement above resolution.
Core sec. C.2, Binding sec. 2.4 Some examples need better formatting.
Proposal accepted.
Implement above resolution.
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.
Text at http://lists.w3.org/Archives/Public/www-ws-desc/2005Nov/0017.html accepted.
Implement above resolution.
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?
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)
Implement above resolution.
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.
Proposal accepted.
Implement above resolution.
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.
Proposal accepted.
Implement above resolution.
In Table 5-4. Mapping from XML Representation to SOAP Operation Component Properties from 5.8.4 Mapping from XML Representation to Component Properties in Part 2, we say: ┌───────────────┬───────────────────────────────────────────────────────┐ │ Property │ Value │ ├───────────────┼───────────────────────────────────────────────────────┤ │ │ The actual value of the wsoap:mep attribute │ │ │ information item, if present. If not, the actual │ │ │ value of the wsoap:mepDefault attribute information │ │ {soap mep} │ item of the parent wsdl:binding element information │ │ │ item, if present. If not the value as defined by the │ │ │ default SOAP binding rules (for SOAP 1.2, see 5.11.3 │ │ │ Default Binding Rules), if applicable. │ ├───────────────┼───────────────────────────────────────────────────────┤ We should add "Otherwise an error" to clarify that it's not OK for {soap mep} not to have a value.
Proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/0011.html accepted.
Implement above resolution.
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.
Proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2005Oct/0051.html accepted.
Implement above resolution.
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.
Accepted.
Implement above resolution.
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.
Proposal accepted.
Implement above resolution.
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.
Proposal accepted.
Implement above resolution.
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.
Reorganize sections with *default attributes, using 6.10 as a model of excellence.
Implement above resolution.
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/
Implement proposals at http://www.w3.org/2002/ws/desc/5/09/wsdl20-adjuncts.html#_http_serialization and http://lists.w3.org/Archives/Public/www-ws-desc/2005Nov/0020.html, plus change the "/" syntax to an attribute.
Implement above resolution.
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.
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.
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
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
WG consensus was to leave soapaction where it is, clarifying that it only applies to the first message in an exchange pattern.
Add clarification described above.
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.
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.
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.
Implement above resolution.
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"
Accept proposals. Address point 3 with the text at http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/0052.html.
Implement above resolution.
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.
Accept proposed edits.
Implement above resolution.
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/
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.
Implement above resolution.
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/
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.
Partial resolutions recorded at http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/att-0067/20050926-ws-desc-minutes.html.
Implement resolution to #5
Editors to examine use of "Note that" and review those to make sure those are not interpreted as non-normative notes.
Implement resolutions to items #1, #2, #6, #10, #14.
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.
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
Close with no action.
WG feels the commenter's proposal conflicts with the definition of barename pointer. We are defining a new scheme specific to WSDL. We should not override an existing scheme.
Last update: $Date: 2005/12/09 20:50:55 $
This page was generated as part of the Extensible Issue Tracking System (ExIT)
Copyright © 2003, 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.