Re: Issue 177: XML 1.1 support

The proposal seems to future proof WSDL for possible new versions of 
XML, which is a good thing, but it applies only to XML 1.1 and not beyond.
In addition, till XML schema supports XML 1.1, the message reference 
component can only describe XML 1.0 messages. Is that correct?

If that is so, then it seems to me that creating new types to support 
XML 1.1 will be of limited value, especially from tooling perspective.

Is there any reason not to rev WSDL when XML schema supports 1.1?
Has the WG considered a resolution similar to the resolution of issue 
20rec [1] in XMLP WG?

-Anish
--

[1] http://www.w3.org/2000/xp/Group/xmlp-rec-issues.html#x20


Umit Yalcinalp wrote:
> 
> 
> 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 04:19:12 UTC