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