- From: Kay, Michael <Michael.Kay@softwareag.com>
- Date: Wed, 27 Nov 2002 15:48:40 +0100
- To: David Holmes <davidgholmes@mindspring.com>, "Kay, Michael" <Michael.Kay@softwareag.com>, public-qt-comments@w3.org
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