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



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:


	-----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


	Following what you have proposed, the types that are used in the


	model, namely xs:string, xs:token, xs:NCName, xs:QName, are no


	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


	XML 1.0 definitions with the current tools that I have and

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


	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

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


	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

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


	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


	the definition of types, without redefining these types as wsdl


	types really.
	Can you clarify again why we can not wait for Schema support for


	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. 



	        -----Original Message-----
	        From: www-ws-desc-request@w3.org [mailto:www-ws-desc-
	        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


	          - Issue 177: Normative dependence on XML Schema 1.0


	                       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

	        constraints on the component model that will make new


	        in future languages (e.g. NUL in strings) to be


	        I propose that we define our own types for use in the


	        corresponding to xs:anyURI, xs:NCName, xs:QName,


	        but derived from an unconstrained sequence of Unicode
	        (0-0x1fffff inclusive).  We should note that certain


	        might not be serializable in particular formats (ASCII
	        encoding, XML 1.0, XML 1.1, etc.).  We can still provide


	        option including a normative schema for WSDL 2.0 encoded

in XML

	        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


	        bindings.  Names and values that are not allowed in XML

1.0 are

	        allowed in SOAP 1.2 messages.  Our SOAP 1.2 binding

needs to

	        behavior in this case (e.g. it's an error? It depends on


	        should not preclude the use of other bindings that might


	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
	Phone: +1 650 607 6154
	Email: umit.yalcinalp@oracle.com


Umit Yalcinalp                                  
Consulting Member of Technical Staff
Phone: +1 650 607 6154                          
Email: umit.yalcinalp@oracle.com
Received on Thursday, 8 July 2004 10:42:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:42 UTC