- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Thu, 8 Jul 2004 07:41:54 -0700
- To: "Umit Yalcinalp" <umit.yalcinalp@oracle.com>
- Cc: <www-ws-desc@w3.org>
- Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA2042B5E66@RED-MSG-30.redmond.corp.microsoft.com>
We appear to agree on the desired behavior. A friendly amendment to my proposal: say explicitly in the Conformance section that processing of documents encoded in XML 1.1 is not a conformance requirement. Alternatively, say explicitly in the Conformance section that processing of documents encoded in a particular version of XML is not a conformance requirement. ________________________________ From: Umit Yalcinalp [mailto:umit.yalcinalp@oracle.com] Sent: Wednesday, July 07, 2004 6:44 PM To: Jonathan Marsh Cc: www-ws-desc@w3.org Subject: Re: Issue 177: XML 1.1 support Jonathan Marsh wrote: Below... -----Original Message----- From: Umit Yalcinalp [mailto:umit.yalcinalp@oracle.com] Sent: Monday, June 28, 2004 2:42 PM To: Jonathan Marsh Cc: www-ws-desc@w3.org Subject: Re: Issue 177: XML 1.1 support <snip/> 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. I don't propose changing the behavior of existing schema types, but using new types in the component model which indeed have a greater repertoire of allowed characters than the corresponding schema types. That is exactly my problem. I don't think we can pnly express this in wording. Our schema is normative, therefore, if those types are not defined in our schema, I don't see how one can process with these types. 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. The WSDL schema wouldn't change, and would continue to be a valuable tool, and indeed conformance criteria, for WSDL documents encoded in XML 1.0. It's value is limited, and therefore not a conformance criteria, for WSDL documents encoded in XML 1.1. That is an interesting way of wording it. What is the conformance criteria for XML 1.1 then? We don't have one. My concern is for current tools to be able to consume WSDL documents with the published WSDL 2.0 schema and validate them. My proposal is designed not to break this as long as you use XML 1.0. Validating a document in XML 1.1 is a problem the Schema WG is working on, and my proposal assumes that we can use their solution when it emerges. I agree with the intent. However, I still don't see how a WSDL processor who can process only XML 1.0 will not break when presented with XML 1.1 based WSDL documents. That is the case, the encoding of the WSDL documents that worry me. Perhaps, we can explicitly state that WSDL processors are not required to process WSDL documents that depend on XML 1.1. and we should address this issue when Schema WG do their job. 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. There is no requirement that a WSDL processor accept XML 1.1 documents (or XML 1.0 documents for that matter). Perhaps this needs to be made clear. Again, I am worried about the encoding of the WSDL documents themselves. As long as there is a normative schema, there is an implicit requirement that WSDL documents that use the schema to be compliant and WSDL processors to accept documents that conform to the schema, which is only for XML 1.0, but not XML 1.1. It seems that the intent was to be permit XML 1.1 types, but the current situation appears to be "requiring" these types. That is not the intention. The component model is an abstraction, and there is no requirement to expose it in certain ways or to refrain from limiting it. 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? We could, but the WG seemed to be in favor of future-proofing our spec to the extent we can. If schema comes out with a solution prior to completion of WSDL, we will have to revisit this, but my intention is to have a solution in place that is sufficiently flexible if they can't solve this problem in time. The solution appears to be problematic as it implies WSDL processors to process WSDL documents with data types which are not even accounted for in the schema itself. --umit 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 -- Umit Yalcinalp Consulting Member of Technical Staff ORACLE Phone: +1 650 607 6154 Email: umit.yalcinalp@oracle.com
Received on Thursday, 8 July 2004 10:42:20 UTC