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

David Holmes:
 
It strikes me that the key paradigm that flies in the face of having an XSLT
engine emit/return sequences is that there is an implicit assumption that
you are generating a principal document - a singleton sequence containing
one document node and all its descendants.  

MK: not necessarily one result document, but certainly a set of documents:
i.e. not a set of integers or strings. The latest drafts take us in the
direction of transforming a set of input documents into a set of result
documents. I think that reflects the role of XSLT: it's an XML
transformation language, it produces trees from trees.

DH: No question for backwards compatibility that we can't break that
paradigm. Suppose, however, that we define a new XSLT document element, call
it <xsl:query/> for grins (<xsl:procedure/> might be less controversial!).
Under <xsl:query> we have the usual compliment of XSL instructions that can
appear under <xsl:stylesheet/>.  ....

MK: there's no question that it's possible. The question is, do you get a
better language as a result? Would you be able to take anything out of
XPath, and if so, what? Would it be easier for users to do things at the
XSLT level rather than, as currently designed, doing it at the XPath level?
And would it be sufficiently better than it's worth reducing the amount of
functionality that's shared in the XPath core, which is available in
contexts other than XSLT?

The question of shared functionality is a real one. There is an argument
that we should be sharing more: for example, why have different syntax in
XQuery and XSLT for defining functions? Hopefully, vendors will ensure that
function libraries written in XSLT are usable from XQuery and vice-versa.
But do we actually need two different languages?

Most approaches to "constructing sequences in XSLT" seem to depend on
overloading <xsl:value-of> so that in some circumstances it produces a text
node and in other circumstances it produces a string (or some other typed
value). I just think that kind of overloading gets very messy, especially if
you can't decide statically which it's going to do; and it's unnecessary,
because the functionality is available in XPath, and I don't think we want
to take it out of XPath, because that would reduce composability.

But as I say, these are my views, and reflect the reason we took this
decision. I'm not saying that alternatives weren't viable, or that they
wouldn't have any advantages. We had to make a judgement on balance.

Michael Kay

Received on Wednesday, 27 November 2002 09:48:48 UTC