W3C home > Mailing lists > Public > www-ws-desc@w3.org > June 2004

Issue 177: XML 1.1 support

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Thu, 24 Jun 2004 17:40:53 -0700
Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA20409B9D0@RED-MSG-30.redmond.corp.microsoft.com>
To: <www-ws-desc@w3.org>

How's this for a concrete proposal addressing XML 1.1 support:

1) Augment Mark's proposal (adopted by WG) for Issue 223,224 [1] to say:

"Components are named collections of properties that correspond to
different aspects of Web services. Properties are unordered and unique
with respect to the component they are associated with. Individual
properties' definitions may constrain their content (e.g., to a typed
value, another component, or a set of typed values or components), and
components may require the presence of a property to be considered

"Properties with typed value can have a schema type (e.g. xs:Boolean),
or one of the following types, which accommodate characters that may be
found in an XML 1.0 or XML 1.1 infoset:

  * [Definition] a =string= is a sequence of characters that satisfies
    _Char_ <http://www.w3.org/TR/2004/REC-xml11-20040204/#NT-Char>
    production of _[XML 1.1]_, which is a superset of the characters 
    allowed in the _[XML 1.0]_ _Char_ 
    <http://www.w3.org/TR/2004/REC-xml-20040204#NT-Char> production and 
    the _xs:string_
  * [Definition] a =token= is a _string_ <link to def above> that
    no carriage returns (#xD), line feed (#xA) nor tab (#x9) characters,
    that have no leading or trailing spaces (#x20) and that have no 
    internal sequences of two or more spaces.  This is a superset of 
    the characters allowed in the xs:token 
  * [Definition] a =NCName= is a _token_ (link to def above) 
    that also satisfies the NCName 
    production of Namespace in XML 1.1, which is a superset of the 
    characters allowed in the Namespaces in XML 1.0 _NCName_ 
    and the _xs:NCName_ 
  * [Definition] a =QName= is a sequence of characters that satisfies
    that also satisfies the QName 
    production of Namespace in XML 1.1, which is a superset of the 
    characters allowed in the Namespaces in XML 1.0 _NCName_ 
    production and the _xs:NCName_ 

Note: Changes to XML Schema to address the mismatch between Schema 1.0
datatypes and XML 1.1 may occur prior to the finalization of this spec,
in which case we may be able to reference external datatype definitions.

2) Replace all occurrences of xs:string, xs:token, xs:NCName, xs:QName
as the type of component model properties with references to the above

3) Augment the normative reference to the WSDL schema in our conformance
section as follows:

"An element information item coming from an XML 1.0 document and whose
namespace name is "http://www.w3.org/@@@@/@@/wsdl" and whose local part
is definitions conforms to this specification if conforms to the XML
Schema for that element as defined by this specification family and
additionally adheres to all the constraints contained in this
specification.  Conformance of element information items coming from XML
1.1 documents cannot be fully assessed at this time using XML Schema,
and failure of an information item to validate solely because of
differences between XML 1.0 and XML 1.1 must not be considered as a
failure to conform to this specification."

Notes on this solution:
1) if XML 2.0 came out, and allowed NUL's in strings, for example, we
would be unable to accommodate it under the formulation above.  A more
generic solution referencing Unicode directly would be immune from this
2) xs:anyURI is not derived from xs:string, so it doesn't appear to
change its meaning under XML 1.1.  That is, a 0x1 already seemed to be
part of the lexical space of xs:anyURI.

> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]
> Behalf Of Jonathan Marsh
> Sent: Tuesday, June 08, 2004 1:08 PM
> To: www-ws-desc@w3.org
> Subject: XML 1.1 support proposals
> Follows are proposals for resolving our XML 1.1-related issues:

>   - 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
> 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,
> 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
> behavior in this case (e.g. it's an error? It depends on a style?),
> 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 Thursday, 24 June 2004 20:41:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:41 UTC