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

RE: Issue 177: XML 1.1 support

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Thu, 8 Jul 2004 07:41:54 -0700
Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA2042B5E66@RED-MSG-30.redmond.corp.microsoft.com>
To: "Umit Yalcinalp" <umit.yalcinalp@oracle.com>
Cc: <www-ws-desc@w3.org>
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 GMT

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