RE: Issue 177: XML 1.1 support

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.

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

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

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

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

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

Received on Wednesday, 30 June 2004 12:50:10 UTC