RE: XML 1.1 support proposals

this all seems very reasonable to me.

+1

Paul

-----Original Message-----
From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
Behalf Of Jonathan Marsh
Sent: 08 June 2004 21:08
To: www-ws-desc@w3.org
Subject: XML 1.1 support proposals



Follows are proposals for resolving our XML 1.1-related issues:

  - Issue 174: Tie WSDL conformance to XML conformance? [1]

Arthur suggests that XML versions may cause a loss of interoperability.
That's true, but I propose that such concerns are out of scope for WSDL.

The WSDL component model is the abstraction we use for interoperability.
It's based on the Infoset, which is in turn an abstraction of XML
syntax.  These layers provide necessary flexibility, to abstract away
serialization details, from what character encoding is in use, to
whether WSDL parts reside in the same physical file or not.  We should
be very careful about breaking this layering.

It's clear for interop that you want to deliver WSDL serializations in a
format most likely to be acceptable to the receiver.  There are a lot of
choices that govern that format, such as whether the character encoding
is accepted (use UTF-8 or UTF-16 if you want to be sure), which XML
version is in use (currently XML 1.0 is the most widely deployed), which
URI schemes your imports use (http is a good bet but might not be
universally acceptable).  WSDL should not limit future innovations (XML
2.0, Binary XML).  If the industry needs to improve interoperability in
the short run through profiles, they should be developed separately from
the core WSDL language rather than compromise the long-run applicability
of WSDL.

Therefore I propose we close this issue with no action.


  - Issue 175: Is it valid for a XML 1.1 document to import or 
               include a XML 1.0 document (and vice versa)? [2]

Since the component model is built on the Infoset, which makes no
distinction between XML 1.1 and 1.0 documents, I think we are insulated
from which version any particular resource is expressed in (except for
parts handled in Issue 177 below.)  Each component is built from
info-items (XML version is orthogonal) and the components are combined
into the final complete component model.  Of course, a parser that only
understands XML 1.0 will not be able to create infosets for all the
necessary components, so this issue is essentially a duplicate of Issue
174, and should follow the resolution of that issue.

Proposal: If #174 is closed with no action, also close this issue with
no action.

  - Issue 176: Can a WSDL 2.0 XML 1.1 document contain (or 
               reference), a XML Schema 1.0 type description? [3]

The potential problem here would be a mismatch of the "QName" datatype,
where the names syntactically allowed in the definition of the type (in
the Schema) might be different than those syntactically allowed in the
reference (in the WSDL).  For the case above, the WSDL QName syntax
would be a superset of the Schema QName syntax, and there is no problem.
For the opposite scenario, a WSDL 2.0 in XML 1.0 document referencing an
XML Schema 1.0 in XML 1.1 document, there might be a mismatch.  The
manifestation of this is that copying the name from XML Schema to WSDL
might make the WSDL invalid.

Therefore I propose to close this issue as a duplicate of issue 177.

  - Issue 177: Normative dependence on XML Schema 1.0 precludes 
               XML 1.1 [4]

To avoid mixing layers, our component model should be orthogonal to
which XML version is in use (including XML 2.0).  We should not impose
constraints on the component model that will make new features defined
in future languages (e.g. NUL in strings) to be non-conformant to WSDL.

I propose that we define our own types for use in the component model,
corresponding to xs:anyURI, xs:NCName, xs:QName, xs:Boolean, xs:Token,
but derived from an unconstrained sequence of Unicode characters
(0-0x1fffff inclusive).  We should note that certain component models
might not be serializable in particular formats (ASCII character
encoding, XML 1.0, XML 1.1, etc.).  We can still provide a conformance
option including a normative schema for WSDL 2.0 encoded in XML 1.0, but
we should also say that overall conformance to WSDL 2.0 is not
predicated upon XML 1.0 encoding.

Furthermore, there is an issue with mapping abstract structures into
bindings.  Names and values that are not allowed in XML 1.0 are not
allowed in SOAP 1.2 messages.  Our SOAP 1.2 binding needs to specify the
behavior in this case (e.g. it's an error? It depends on a style?), but
should not preclude the use of other bindings that might be able to
handle the additional character range.

[1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x174
[2] http://www.w3.org/2002/ws/desc/2/06/issues.html#x175
[3] http://www.w3.org/2002/ws/desc/2/06/issues.html#x176
[4] http://www.w3.org/2002/ws/desc/2/06/issues.html#x177

Received on Wednesday, 9 June 2004 10:17:20 UTC