This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Anonymous functions are useful, but only if you don't want to create elements or attributes using them. In the absence of XPath-level constructors for elements and attributes, it remains necessary to use a XSLT function definition if you want to write a function that creates elements or attributes. E.g., from https://github.com/MenteaXML/xslt3testbed/blob/table-map/xml/table-test/orange.xsl: ---- <xsl:function name="x3tb:orange-table" as="attribute()*"> <xsl:param name="context" as="element()" /> <xsl:attribute name="background-color" select="'orange'" /> </xsl:function> <xsl:template match="table[@style eq 'orange']"> <xsl:next-match> <xsl:with-param name="table-functions" as="map(xs:string, function(element()) as attribute()*)" select="map { 'table' := x3tb:orange-table#1 }" tunnel="yes" /> </xsl:next-match> </xsl:template> ---- The definition of the $table-functions parameter would have been simpler and clearer if the attribute was able to be constructed in an anonymous function. In this instance, an anonymous function could have referred to a XSLT variable defining the constant attribute, but as this is just one instance of a general mechanism that could return multiple attributes with values based on the context, returning multiple attributes defined in multiple XSLT variables would be even messier.
XSLT is a two language system: XSLT instructions invoking XPath expressions. This means that the language is not fully composable (XSLT instructions cannot be invoked from XPath expressions). For some constructs, we have got around this problem by replicating functionality in the two languages (templates/functions, XSLT variables vs XPath let, XSLT for-each vs XPath "!", xsl:choose vs XPath conditional expressions). However, the logical conclusion of a pursuit for full composability would be for all XSLT functionality to be reproduced in XPath. We don't think this amount of duplication would be good for the language. There is a general workaround, which is that if you need to access some XSLT functionality from XPath, you can wrap it in a function. For example you could write a function library for element and attribute creation. (personal response)
(In reply to Michael Kay from comment #1) > XSLT is a two language system: XSLT instructions invoking XPath expressions. > This means that the language is not fully composable (XSLT instructions > cannot be invoked from XPath expressions). Yet there is some drift between specs over time: e.g., document() and doc(). This is marked as an enhancement, not a bug, to point out something that you might look at in the future, not something you have to fix today. Yes, current stylesheets are inelegant and harder to read than they could be, but they are not unworkable. ... > There is a general workaround, > which is that if you need to access some XSLT functionality from XPath, you > can wrap it in a function. For example you could write a function library > for element and attribute creation. Good point. And presumably if you do see it happening often enough, you'd think about adding it to a later version. > (personal response) Understood.
The WG discussed this during the ftf meeting in Prague. We agree that this is a possible path for growth of XPath, though it is a path the WG is not inclined to take at this time. In the discussion, a few technical points were made which may be worth recording. - Functions to construct nodes will feel most convenient to many users if they can be chained (so one could write an expression like element('x').att('id', 'x0001').att('code',3) to produce <x id='x0001' code="3"/>). (The alternative of element('x', (att('id', 'x0001'), att('code'3))) was also mentioned; the function library of SQL/XML. Or the set of attributes can be defined by a map from names to values.) - Having the same expression language in XSLT and XQuery might be another approach. - Since the F and O function library already has crossed the boundary line of including functions which return nodes (doc()), it is conceivable that functions for constructing elements and attributes could be specified and prototyped in EXPath. Strictly speaking, this issue seems to involve XPath, not XSLT; should it be reassigned to XPath 3.0 or 3.1?
The XSL WG determined at our 24 April 2014 meeting that this bug should be considered by the Joint Group as an XPath enhancement.
The XSLT and XML Query working groups discussed this issue during a joint teleconference today. There was some sentiment that in a more purely and completely functional language, one might well wish to eliminate this and other places where special-purpose syntax can do things that cannot be done in functions. The historically conditioned role of XPath in relation to its host languages, however, means that the 3.0/3.1 versions of our specifications are not such a language. After some discussion, the working groups decided to resolve the issue as LATER. There was some dissent from this: some working-group members did not agree that this would ever be a useful idea and would prefer to resolve it in some other way (not clear whether they preferred INVALID, WONTFIX, or WORKSFORME). In the course of the discussion, some members of the working groups argued strongly against the view that the doc() function is parallel to the constructors proposed here: doc() is not described as creating nodes, but as returning nodes which already exist in the dynamic context. Some participants in the discussion regarded this as a distinction without a difference, and there were mentions of angels and heads of pins; for other participants the distinction does make a difference. Tony, in your role as originator of the issue, we ask you to close the issue to indicate your willingness to accept this resolution of the issue, or to re-open it to indicate unwillingness to accept it. If we don't hear from you before two or three weeks have passed, we will assume that your silence indicates assent.