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

and to the response provided by Michale Kay:

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