Re: Using or ignoring Types in XSLT 2.0 / XPath 2.0
----- Original Message ----- From: "Kurt Cagle - Olywa" <cagle@xxxxxxxxx> Hey all, I recognize that the typing debate is quickly approaching perma-thread status on XML-DEV and I did not intend to start that pillow fight over here. Better and better informed minds than mine have been chewing on this for some time, but now is the time to make my voice heard, if it is to be heard at all, and this reply has been cross posted to public-qt-comments@xxxxxxx > I still contend that type doesn't belong in XSLT, but if it is in there, it > should make processes more efficient, not less. If type needs to be there, > then all of XSD should be supported, such that an XSLT function can return > an object of complex type Foo. I concur. Two points to note: 1) A range of XPath 2 functions display indeterminate behavior in the absence of PSVI type annotation. I believe this practically voids their utility for a very large set of XML applications, that is: web-facing ones. Validation remains far too expensive for non-trivial network applications. We validate coming in, but we can't afford to validate going out. Validation is a useful tool, but a glaring inefficiency. As a consequence of this practical consideration, typing offers little value for us. We will continue to rely on Java adaptors to wrap the results of our SQL statements in well-formed XML 1.0 for presentation. Business logic will continue to live largely in SQL statements and Java classes where typing is managed in their conventional ways. The pfaffing of strings (love that word, Andrew) will continue, but has never been a particular burden. I wrote a lovely universal calendar, porting a day-of-week algorithm from C to XSLT and the sum of string pfaffing consisted of three substring functions; a v2 of this stylesheet will still use three functions to get what I need, but three discrete functions on dateTime and a test and a cast in the absence of validation. 2) A consequence of this reliance on validation-driven type annotation is to effectively deprecate well-formedness in XML processing. X(Path|SLT) 2.0 does not represent an evolutionary step. Developers and architects cannot simply decide to use 2.0 because "it's the latest". It is a revolutionary change that implicates other choices. It is a paradigmatic shift, not a generational one and entails validation. This is where political and philosophical considerations enter. I think that the drafts as currently constituted are a death sentence for userspace XML. Whether you think that is a problem is, as I say, a political issue. Microsoft loves the idea of obfuscating XML to the point of inutility and the complexity of XSD is just one facet of their push to stub out userspace XML. I feel strongly that XSL is currently a valuable userspace tool. This is at least partly a consequence of the relative absence of datatyping. The essential goal of XML, to my mind, was to get data and process out of the binary silos, out of the hands of ISVs and developers and into the hands of users. Userspace XML is a three-legged stool and the application support and training legs have long been broken. Deprecating well-formedness as the current drafts effectively do leaves us sitting on the floor. If xdt:untypedAtomic is the gesture intended to decouple type annotation from validation, it does not go far enough. The current drafts try to strike a balance but to no purpose. In the world projected by the May 2 drafts, there are effectively two different species of XML, not two flavors; the two cannot relate directly from the point-of-view of a stylesheet author. A stylesheet that behaves as expected over one will not necessarily behave the same over the other, including the possibility of run-time failure. Validated XML and that which is merely well-formed will each require distinct XSL programming idioms. The drafts should be adapted to reflect this distinction. I feel strongly that, at the least, functions with unsafe behavior in the absence of PSVI type annotation must be noted in the specification. It would be better still to accommodate the type annotation of XML data external to validation. Best of all would be to acknowledge that type-annotated XML is a separate and distinct beast with its own infoset; from an XSL perspective, it already is. Sincerely, Mike Haarman, Developer and Information Architect, Infinite Campus XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
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