WSDL 2.0 Part 1 I18N Comments

All:

Following are some preliminary comments on the document in the subject line for your consideration.

Addison
----------

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

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

3. Section 2.1. In the following quote, the reference to URI should include IRIs. In fact, there should be some care taken to clarify that URIs in this document mean IRIs, if possible:

<quote>
Note that it is RECOMMENDED that the value of the targetNamespace attribute information item SHOULD be a dereferencible URI and that it resolve to a WSDL document which provides service description information for that namespace.
</quote>

4. Section 2.1. (considering.....) Name uniqueness. While QNAME defines uniqueness in an internationalized way, it may be useful to reference what makes a name unique in this document.

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

5. Section 2.1.2. The <documentation> element is not allowed to be repeated and appears to describe documentation in a single language. We'll deal with the structure of the <documentation> element in section 5. In this location though additional thought should be given to handling it.

6. Section 2.18. Qname resolution. This section should directly reference the definition of QName, where internationalization concerns are dealt with. Perhaps point them out here? QName uniqueness is so deeply ingrained into the requirements of this document that some care should be given to actually determining equivalence. Furthermore, non-ASCII QNames represent potential challenges to testing and interoperability of many requirements.

7. Section 2.19. Comparing URIs. Again, no mention of IRIs (which are supported by xs:anyURI). There is mention of the TAG finding in which comparison is done character-by-character (but no text dealing with normalization required to perform character sequenced comparison).

8. Section 2.2.1.1. (editorial) This is fairly murky.Also, the "either one" should be just "one". 

9. Section 5. Documentation. This is important to I18N, since there is no support for multiple languages provided and there should be. Here is the text of Section 5:

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

Since this item is supposed to be human readable and since it has no defined structure, it should be:

a) (provisionally) required to have an xml:lang attribute indicating the language. Provisionally because one and only one may omit the xml:lang and be considered the "default language". This item may contain machine processable documentation, of course.
b) allowed to be repeated so long as the xml:lang attribute is unique.

10. Section 2.3. Interface Fault. This is a semi-pedantic comment. Faults indicate error conditions in a MEP. They can contain an element information item which represents the actual error, but this doesn't appear to allow for multiple language renditions. See WSUSI.

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

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

This seems reasonable at first glance: for operation "foobar", the response is called "foobarResponse". But is it less helpful in cases where the original operation name is non-ASCII in nature. Consider an operation named in Arabic, for example...

It isn't clear why the name needs to be quite so determinate (and thus a concatenated construct) in the first place. Is there some reason why the return message needs a name based on the request message's?

=== stopped at section 2.5.1 ===

Addison P. Phillips
Director, Globalization Architecture
webMethods | Delivering Global Business Visibility
http://www.webMethods.com
Chair, W3C Internationalization (I18N) Working Group
Chair, W3C-I18N-WG, Web Services Task Force
http://www.w3.org/International

Internationalization is an architecture. 
It is not a feature.

Received on Wednesday, 3 November 2004 17:09:24 UTC