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

Re: Issue 177: XML 1.1 support

From: Umit Yalcinalp <umit.yalcinalp@oracle.com>
Date: Mon, 28 Jun 2004 14:42:12 -0700
Message-ID: <40E090B4.3060102@oracle.com>
To: Jonathan Marsh <jmarsh@microsoft.com>
Cc: www-ws-desc@w3.org


Jonathan Marsh wrote:

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

>
>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
>conformant."
>
>"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
>the 
>    _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_
>    <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#string>
>datatype.
>  * [Definition] a =token= is a _string_ <link to def above> that
>contains
>    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 
>    <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#token>
>datatype.
>  * [Definition] a =NCName= is a _token_ (link to def above) 
>    that also satisfies the NCName 
>    <http://www.w3.org/TR/2004/REC-xml11-20040204/#NT-Char#NT-NCName>
>    production of Namespace in XML 1.1, which is a superset of the 
>    characters allowed in the Namespaces in XML 1.0 _NCName_ 
>    <http://www.w3.org/TR/1999/REC-xml-names-19990114#NT-NCName>
>production
>    and the _xs:NCName_ 
>    <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#NCName>
>datatype.
>  * [Definition] a =QName= is a sequence of characters that satisfies
>the
>    that also satisfies the QName 
>    <http://www.w3.org/TR/2004/REC-xml11-20040204/#NT-QName> 
>    production of Namespace in XML 1.1, which is a superset of the 
>    characters allowed in the Namespaces in XML 1.0 _NCName_ 
>    <http://www.w3.org/TR/1999/REC-xml-names-19990114#NT-NCName> 
>    production and the _xs:NCName_ 
>    <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#NCName>
>datatype.
>
>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
>definitions.
>
>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
>change.
>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.
>
Following what you have proposed, the types that are used in the 
component model, namely xs:string, xs:token, xs:NCName, xs:QName, are no 
longer what they appear to be. It seems to me that I can not consume the 
WSDL schema which will be using these types as they are defined by 
schema and assuming XML 1.0 definitions with the current tools that I 
have and validate it.

My concern is for current tools to be able to consume WSDL documents 
with the published WSDL 2.0 schema and validate them. This definition 
allows XML 1.1 types to be permissible, so tools that are built by using 
the datatypes as defined using xsd types today will choke on content 
that are allowed by XML 1.1 and not be compliant. It seems that the 
intent was to be permit XML 1.1 types, but the current situation appears 
to be "requiring" these types.

If we were to allow the "extended" types for XML 1.1, the type 
definitions have to reflect them so that the tools that consume them 
know how to interpret these types. I don't see a way to automate this by 
just changing the definition of types, without redefining these types as 
wsdl specific types really.

Can you clarify again why we can not wait for Schema support for XML 1.1 
and have a rev of WSDL for that again?

Thanks.


--umit

>
>  
>
>>-----Original Message-----
>>From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]
>>    
>>
>On
>  
>
>>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
>>    
>>
>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
>>
>>    
>>
>
>
>  
>

-- 
Umit Yalcinalp                                  
Consulting Member of Technical Staff
ORACLE
Phone: +1 650 607 6154                          
Email: umit.yalcinalp@oracle.com
Received on Monday, 28 June 2004 17:43:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:31 GMT