RE: Enlightenment via avoiding the T-word

[Michael Brennan <Michael_Brennan@allegis.com>]

There seems to be quite a tendency to conflate the SOAP and WSDL specs with
what individual toolkits are doing with these. This is like conflating how
individual XML applications deal with schema types and namespaces, and the
specs themselves. There are plenty of non-SOAP applications that leverage an
XML Schema for databinding. That doesn't mean that XML Schema provides a
mechanism for type conversions, although supporting that sort of use case
seems to have clearly influenced the design of XML Schema.

SOAP and WSDL do not do any type conversions. Individual toolkits that use
these specs often do use schema info to do such type conversions, and that
is even a use case that SOAP explicitly intends to support, but the SOAP
spec and WSDL spec do not specify any type mapping and do not specify any
interpretation of "types" beyond that of XSDL itself. If you specify in SOAP
that a parameter is of type "xsd:int" (where the "xsd:" prefix is
appropriately mapped to the XML Schema namespace), that means only that the
parameter in the XML is an element of type "xsd:int". It is up to invididual
toolkit implementations to do what they want with that info, just as other
types of applications may elect to use PSVI info for purposes other than
validation. The spec itself only concerns itself with the format of XML over
the wire.

In WSDL, the use of schema is for nothing other than to define simple
message patterns: what message structures are allowed as requests, what
message structures may be received as a response.

In other words, the use of "types" in SOAP is simply the same use of types
that is in XML Schema; no more, no less.

With that said, though, I do think XML Schema errs in conflating the roles
of validation and these other use cases. I think taking a more layered
approach -- similar to what the RELAX NG folks are doing with annotations --
would have been a sounder approach. I really hope that at some point the
philosophy driving RELAX NG work finds its way into the hearts and minds of
the drivers at the W3C. I think we need a foundation that does not layer
concepts such as types and inheritance -- or even a PSVI -- onto XML
instance documents, and use cases that require such facilities can leverage
upper layers that rest upon this foundation, without mechanisms for these
narrower and more demanding use cases being inextricably intertwined with
the foundation. Data-binding, defaulted attributes and other PSVI artifacts,
these are IMO in the realm of how a particular application may choose to use
XML, but are not aspects of an XML instance itself. We may wish to constrain
the content of an XML instance in such a manner that it can support such
uses, but this should not require that every XML application must think of
that instance as anything other than just an XML document.

> -----Original Message-----
> From: Paul Prescod [mailto:paulp@ActiveState.com]
> Sent: Sunday, August 26, 2001 11:10 PM
> To: xml-dev@lists.xml.org
> Subject: Re: Enlightenment via avoiding the T-word
> 
> 
> Tim Bray wrote:
> > 
> >...
> > 
> > The original XML recommendation included the specification of
> > a constraint language.  This has supported the mistaken belief
> > that validation is uniquely special and important among all
> > the classes of applications which process XML.
> 
> For better or for worse, the emerging XML architecture DOES elevate
> schemas, validation and ty*e declarations above other "XML processing
> applications". For example SOAP and WSDL implementations use 
> XML schema
> types to do type conversions. WSDL actually uses XML Schema 
> as some kind
> of abstract type definition system (completely distinct from 
> its use as
> an XML validation tool).  XSLT 2.0 and XPath 2.0 are also going to use
> information from the schema.
> 
> These specifications do not build on XML Schema for its validation
> facilities. They do for its t*** system. So flaws in that system will
> eventually become material to all XML users. Some future applications
> may not deal with element labels (or ulabels) at all. They will deal
> with t*** names.
> -- 
> Take a recipe. Leave a recipe.  
> Python Cookbook!  http://www.ActiveState.com/pythoncookbook