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

Re: Issue 177: XML 1.1 support

From: Umit Yalcinalp <umit.yalcinalp@oracle.com>
Date: Wed, 07 Jul 2004 18:43:31 -0700
Message-ID: <40ECA6C3.6000703@oracle.com>
To: Jonathan Marsh <jmarsh@microsoft.com>
Cc: www-ws-desc@w3.org


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 Wednesday, 7 July 2004 21:44:15 GMT

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