W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2003

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

From: Michael Rys <mrys@microsoft.com>
Date: Wed, 14 May 2003 19:45:53 -0700
Message-ID: <5C39F806F9939046B4B1AFE652500A3A05467B4D@RED-MSG-10.redmond.corp.microsoft.com>
To: "Mike Haarman" <mhaarman@infinitecampus.org>, <xsl-list@lists.mulberrytech.com>, <public-qt-comments@w3.org>

Dear Mike 

Thanks for your comment. But I have to ask you to give us a bit more
concrete examples where you think the typing is giving you problems and
what range of XPath 2 functions display problems for you. 

Given that XSLT provides for a conformance level that is without typing
and given that we work hard to provide week typing on untyped data and
strong typing on typed data, I think we aim to provide a good combined

The type annotations in the data model can occur in any way that satisfy
certain integrity constraints. They do not have to involve validation,
although often they will.

So while I appreciate philosophical discussions on this topic, we need
actional feedback and not philosophical design discussions at this

Best regards

PS: I am not sure I should take the flame bait about Microsoft, but I
can assure you that there is no evil Microsoft plot behind adding typing
to XPath/XSLT. Such comments don't help making your point...

> -----Original Message-----
> From: Mike Haarman [mailto:mhaarman@infinitecampus.org]
> Sent: Wednesday, May 14, 2003 15:45 PM
> To: xsl-list@lists.mulberrytech.com; public-qt-comments@w3.org
> Subject: Re: [xsl] Using or ignoring Types in XSLT 2.0 / XPath 2.0
> ----- Original Message -----
> From: "Kurt Cagle - Olywa" <cagle@olywa.net>
> 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.
> and
> better informed minds than mine have been chewing on this for some
> but now
> is the time to make my voice heard, if it is to be heard at all, and
> reply
> has been cross posted to public-qt-comments@w3.org.
> > I still contend that type doesn't belong in XSLT, but if it is in
> 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
> a very
> large set of XML applications, that is: web-facing ones.  Validation
> remains far
> too expensive for non-trivial network applications.  We validate
> 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
> statements in well-formed XML 1.0 for presentation.  Business logic
> continue to live largely in SQL statements and Java classes where
> is
> managed in their conventional ways.
> The pfaffing of strings (love that word, Andrew) will continue, but
> 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
> functions to get what I need, but three discrete functions on dateTime
> a
> test and a cast in the absence of validation.
> 2) A consequence of this reliance on validation-driven type annotation
> to
> effectively deprecate well-formedness in XML processing.  X(Path|SLT)
> 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
> that
> implicates other choices.  It is a paradigmatic shift, not a
> one
> and entails validation.
> This is where political and philosophical considerations enter.  I
> 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
> 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
> 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
> 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
> of
> XML, not two flavors; the two cannot relate directly from the
> view of a
> stylesheet author.  A stylesheet that behaves as expected over one
> not
> necessarily behave the same over the other, including the possibility
> run-time failure.  Validated XML and that which is merely well-formed
> each
> require distinct XSL programming idioms.
> The drafts should be adapted to reflect this distinction.  I feel
> that,
> at the least, functions with unsafe behavior in the absence of PSVI
> annotation must be noted in the specification.  It would be better
> to
> accommodate the type annotation of XML data external to validation.
> of all
> would be to acknowledge that type-annotated XML is a separate and
> beast
> with its own infoset; from an XSL perspective, it already is.
> Sincerely,
> Mike Haarman,
> Developer and Information Architect,
> Infinite Campus
Received on Wednesday, 14 May 2003 22:46:03 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:12 UTC