Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Enlightenment via avoiding the T-word
 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@A...] > Sent: Sunday, August 26, 2001 11:10 PM > To: xml-dev@l... > 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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
