RE: I18N Comments, WSDL 2.0 Part I (partial)

Thank you for your comments on the WSDL 2.0 spec.  Their dispositions
are indicated below.

The latest editor's drafts incorporating these fixes are at [1, 2].  We
plan to issue a second Last Call shortly, and welcome additional review
of that spec.  For the comments below, we will assume these resolutions
are acceptable to you if we don't hear from you within two weeks.

[1] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html
[2]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.
html

> -----Original Message-----
> From: public-ws-desc-comments-request@w3.org [mailto:public-ws-desc-
> comments-request@w3.org] On Behalf Of Addison Phillips [wM]
> Sent: Friday, November 05, 2004 10:28 AM
> To: public-ws-desc-comments@w3.org
> Cc: public-i18n-ws@w3.org; w3c-i18n-ig@w3.org
> Subject: I18N Comments, WSDL 2.0 Part I (partial)
> 
> 
> Dear WSD WG,
> 
> Following is the first part of our comments on WSDL 2.0. These
> comments apply to Part I, "Core Language". We realize that these
> comments are late, but hope that you will consider them carefully.
> Internationalization-related comments are presented first. Editorial
> and other comments are presented at the end.
> 
> ---
> [I18N Comments]
> 
> 1. Section 2.1. In the following quote, the reference to URI should
> explicitly include IRIs (as the type xs:anyURI allows for these). In
> fact, there should be some care taken to clarify that URIs in this
> document mean IRIs, if possible:
> 
> <quote>
> Note that it is RECOMMENDED that the value of the targetNamespace
> attribute information item SHOULD be a dereferencible URI and that it
> resolve to a WSDL document which provides service description
> information for that namespace.
> </quote>

We tracked this issue as LC74a [3].  We accepted the comment, and as a
result have changed URI to IRI throughout most of the document,
reserving a few exceptions for the name of the "uri" attribute on
features and properties, references to namespace URIs, and similar
items.

[3] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC74a

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

We tracked this issue as LC74b [4].  There was insufficient support in
the WG for making an attempt to tackle this problem.

[4] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC74b

> 3. Section 2.1.2, Section 5.0. The <documentation> element presents a
> number of internationalization concerns to us. Here is some of the
> text of Section 5:
> 
> <quote>
> WSDL uses the optional documentation element information item as a
> container for human readable and/or machine processable documentation.
> The content of the element information item is arbitrary character
> information items and element information items ("mixed" content in
> XML Schema[XML Schema: Structures]). The documentation element
> information item is allowed inside any WSDL element information item.
> </quote>
> 
> The problem here is that the documentation is supposed to describe,
> either in plain-text or in markup, aspects of the WSDL for
> documentation purposes. Human readable text has two problems here.
> First, it need to be tagged with the natural language (by referencing
> xml:lang, xsi:language, or by directly referencing RFC 3066 or its
> successors) and second, it may need to be repeated in different
> languages (which may be but are not necessarily translations).
> 
> We suggest that:
> 
> a) The <documentation> element require an xml:lang attribute. The
> attribute may be empty (xml:lang="")
> b) The <documentation> element be allowed to be repeated, provided the
> xml:lang attributes in each of the elements be unique.
> 
> You may wish to reference the <documentation> element (under
> annotations) in XMLSchema, although it is not as clear about the above
> as we would probably like :-).

We tracked this issue as LC74c [5].  The WG agreed to make improvements
to the documentation element for I18N purposes.  Multiple documentation
elements will be allowed, and extension attributes will be allowed on
them (so xml:lang can appear.)  While we won't make xml:lang required
(it may be specified globally instead), we will recommend using it to
our readers.

[5] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC74c


> 4. Section 2.4.2. RPC Style. There is a requirement on the local part
> of the output element name that says:
> 
> <quote>
> The LocalPart of the output element's QName is obtained by
> concatenating the name of the operation and the string value
> "Response".
> </quote>
> 
> We understand that this is historically the way that it has been done
> and that some implementations, at least, rely on this. However, while
> it seems reasonable at first glance that, say, for operation "foobar",
> the response is called "foobarResponse", it may be less helpful in
> cases where the original operation name is non-ASCII in nature. It
> isn't clear why the name needs to be quite so determinate (and thus a
> concatenated construct) in the first place. Is there some reason why
> the return message needs a name based on the request message's plus
> some English ("Programmer-ese") token? Since in the RPC style the
> "out" message is presumably the response, can this requirement be
> relaxed?

We tracked this issue as LC74d [6].  The WG relaxed the requirement for
generating names in this fashion.

[6] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC74d

> 5. Section 2.15. Simple Types. This section gave us a great deal of
> concern. In this section WSDL defines seven simple types used in the
> component model of WSDL 2.0. These types are: string, Token, NCName,
> anyURI, QName, boolean and int. The argument presented in this section
> is that these needed to be redefined because "the types defined here
> go beyond the capabilities of XML Schema to describe."
> 
> We are not sure why you consider this to be the case (our suspicion is
> that it is to ensure XML 1.1 compatibility). However, the definitions
> presented here are much less mature than those in XML Schema for
> internationalization purposes. We would strongly urge you to
> reconsider and use the XML Schema definitions directly. If there is a
> good reason not to use XML Schema directly, then we urge you to
> import, fully, the definitions in XML Schema for each of these types.
> A cursory review of our issues with the types you define are:
> 
> 5a. string. The definition includes all code points between U+0000 and
> U+10FFFF. It doesn't deal with illegal characters in XML, such as
> surrogates, unassigned, or non-characters (like U+FFFF or U+10FFFF).
> XML 1.0 and XML 1.1 define various productions that can be used to
> avoid this problem, but we don't see why you don't just use the
> definition found in http://www.w3.org/TR/xmlschema-2/#string
> 
> 5b. Token. This definition is similar to the one in XML Schema, but
> leaves out the prohibition on character #0xD. It is not usefully
> different than the one in XML Schema.
> 
> QName, NCName. The NCName and QName definitions say more-or-less what
> they are, but the productions cited in XML Schema (Namespaces in XML,
> http://www.w3.org/TR/1999/REC-xml-names-19990114/) should be
> explicitly cited.
> 
> 5c. anyURI. This implicitly disallows IRIs. You should include the
> text from the second and subsequent paragraphs in XML Schema's
> defintion. In particular, anyURI in XML Schema represents the
> *unescaped* sequence (it is, effectively, an IRI).
> 
> 5d. int. This is problematic on two fronts. First, it is different
> from the "int" type in XML Schema (it is very similar to the "integer"
> type: "int" in XML Schema is derived from "long", which is derived
> from "integer" and has a maximum and minimum value corresponding to an
> integer type of a specific size). Second, you don't define the lexical
> representation, which may present problems for internationalization.
> One presumes that the lexical description is the same...

We tracked this issue as LC74e [7].  The WG had several comments related
to XML 1.1 support and it's interaction with Schema, and decided to drop
the definition of these abstract types.  While we don't preclude the use
of XML 1.1 for WSDL documents, we don't describe how XML 1.1 features
can be used in conformant documents or support them abstractly in the
component model.

[7] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC74e

> ---
> [Non-I18N Comments]
> 
> 6. 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.

We tracked this issue as LC74f [8].  The WG closed this issue with no
action, declining to formalize our glossary.  Though if you find a
problem with a particular definition, we'd be interested in hearing
about it.

[7] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC74f

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

We tracked this issue as LC74g [8].  The editors have fixed this
editorially.

[8] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC74g

> Thank you for considering our comments. We may have (intend to have)
> some addition comments on these documents within a week.
> 
> Best Regards,
> 
> Addison (For I18N WG and the Web Services I18N Task Force),
> 
> 
> Addison P. Phillips
> Director, Globalization Architecture
> 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 Thursday, 9 June 2005 20:47:51 UTC