Re: [xsl] Using or ignoring Types in XSLT 2.0 / XPath 2.0

Subject: Re: [xsl] Using or ignoring Types in XSLT 2.0 / XPath 2.0
From: "Mike Haarman" <mhaarman@xxxxxxxxxxxxxxxxxx>
Date: Wed, 14 May 2003 17:44:49 -0500
----- 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.


Mike Haarman,
Developer and Information Architect,
Infinite Campus

 XSL-List info and archive:

Current Thread