RE: Resolution of XSLT issue 99: Constructing Sequences in XSLT

Thanks for the comment.
 
This wasn't an easy decision to make, we revisited it several times and
there were good arguments on both sides.
 
From my point of view, the compelling arguments in favour of the resolution
that we decided on were:
 
* we have a two language model, and it is desirable to avoid duplication
between the two languages. That means there should be a clear separation of
responsibilities between the two languages. There are various possible
boundaries that one could draw, but to my mind the most natural is that XSLT
(with its XML-based syntax) is good for creating nodes, while XPath (with
its algebraic syntax) is good for computing values; the distinction between
nodes and values is a very strong one in the data model. A separation of
concerns based on what objects each language manipulates is more likely to
work than a split based on functionality.
 
* it is important to have absolute clarity about whether two adjacent
instructions in the stylesheet are creating two sibling nodes (which might
be merged, if they are text nodes) or two values in a sequence (which will
not be merged). XQuery achieves this by allowing the node-construction
expressions to be composed with the sequence-construction syntax. Being a
two-language system, XSLT doesn't have this luxury. I don't think any of the
proposals for doing sequence construction in XSLT created a clear enough
distinction between sequence construction and tree construction.
 
* backwards compatibility is not an optional extra, nor is it something we
should begrudge. We have inherited the stewardship of a successful language,
and we need to respect the essential characteristics of the language.
Changing the type system is radical enough, but changing the very clear
processing model - in which the stylesheet tree acts very directly as a
template for the result tree - would in my view be a step too far.
 
The asymmetry between XSLT and XPath is deliberate. We regard XSLT as a
language that is closed with respect to trees, in the same way as SQL is
closed with respect to relations. Within that we have a sublanguage that is
closed over sequences of the 19 primitive types. This is a similar model to
SQL, which does arithmetic and boolean operations on working data, but
always delivers tables as its final result.
 
As far as xsl:value-of is concerned (and AVTs equally), we have adopted the
same solution as XQuery (generally, in the model for constructing typed
trees, we decided to let the XQuery WG beat the path through the jungle).
Like XQuery, we found it difficult to come up with a model for putting typed
values on trees directly, rather than going through the two-stage process
(at least conceptually) of taking the string value and then validating it
using a schema processor. This was a long and difficult debate.
 
Thanks for your comments, anyway. It's good to force us to stand back from
the detail and ask ourselves why the big decisions were made they were.
Deadlines didn't come into it, except from the viewpoint that you can't sit
on the fence for ever.
 
Michael Kay
 
 
 -----Original Message-----
From: David Holmes [mailto:davidgholmes@mindspring.com] 
Sent: 26 November 2002 02:43
To: public-qt-comments@w3.org
Subject: Re: Resolution of XSLT issue 99: Constructing Sequences in XSLT



This note responds to an issue originally raised on 11 Jan 2002 by Jeni
Tennison, which is archived at:

 <http://lists.w3.org/Archives/Public/xsl-editors/2002JanMar/0050.html>
http://lists.w3.org/Archives/Public/xsl-editors/2002JanMar/0050.html

and to the response provided by Michale Kay:
 
http://lists.w3.org/Archives/Public/public-qt-comments/2002Sep/0043.html
<http://lists.w3.org/Archives/Public/public-qt-comments/2002Sep/0043.html> 
 
I was disappointed and concerned to hear that  XSL WG has decided against
incorporating the idea that XSLT should be generalized to generate
sequences.  As a designer of an XSLT 2.0 engine I can report first hand that
this proposal has an aesthetic quality which should be compelling to any
architect in a similar position to myself and I would hope that the
conceptual simplification would be attractive to an XSLT developer.  As
arguments, I do not intend to reproduce the level of detail provided in Jeni
Tennison's proposal since I believe that that proposal was thorough enough
to show that the approach is workable.  Instead, I would like to make the
more general architectural observation that there exists asymmetry (based on
the current XSLT spec) between the result produced by an XPath evaluation
tree, and an XSLT evaluation tree.  Whereas the XPath evaluation tree is
thought of as returning a sequence, the XSLT tree generates a pseudo data
model - most often a single document but perhaps multiple documents, if the
XSLT 1.1 instruction <xsl:document> is employed.  In truth there should
exist a symmetry between a compiled XPath expression and a compiled XSLT
"Push Instruction" (using Michael Kay's own terminology) where the only
distinction is whether you are "pulling" (returning) a sequence (as in
XPath) versus "pushing" a sequence (as in XSLT).  In fact, originally, my
main motivation for seeking a symmetry was to define a uniform expression
model for XPath and XQuery, but it became obvious that XSLT should be no
different.  In general I feel that the XSLT specification is being loaded
with new functionality (most of which I think is good), but the integration
with the XPath 2.0 and XQuery 1.0 Data Model is being treated as a
second-class citizen, almost an inconvenience.  For a concrete example,
consider <xsl:value-of>.  This tried-and-trusted friend deserves a better
fate than producing just strings for evermore.  Clearly it was destined to
generate typed-values (atomic-value*).  The same should be true of attribute
value templates - aren't attribute values typed-values?
    I understand that backwards compatibility is a keen consideration and
that deadline goals should be strived for, but I can't help wondering
whether we are getting the cart before the horse; can these really be our
priorities?
 
    Finally, I would like to add a simple endorsement to Jeni's lonely voice
and a reminder that the W3C WGs focus should be less to produce a CR by a
certain date, and more to provide a firm conceptual foundation for XML
processing over a time frame that should far exceed the specification
development time.
 
    And since this is my first note, I should add that I am enthusiastic
about helping XML having a bright future through the W3C process.
 
Cheers,
 
David Holmes