Re: [exsl] Draft 0.1 - call for comments
Hi David, As usual, I agree with most of the points that you make, so I'll leave others to argue their case on: (a) restricting the content of exsl:function (b) disallowing the creation of result nodes > (I've also moved the param element into the exsl namespace, bit wary > of overloading xsl:param for this as it's not being used with > standard xsl constructs, and in particular it isn't being paired > with with-param, but rather it's setting up a positional context. ) I guess the benefit of using xsl:param rather than exsl:param/exsl:argument/exsl:arg would be that it's something that's already familiar to XSLT users. I wonder how many times we'd have to repeat "templates take parameters, functions take arguments". But that's the extent of my argument. >> Issue: Wrapper - should there be a wrapper element to contain the >> exsl:function elements in a document? > > Not if this is an XSLT 1.0 extension. > For XSLT 1.0 you might want to look at what would be involved with > merging this wth xsl:script. With the current XSLT 1.1 WD, this can't be merged with xsl:script because xsl:script allows only text as content. It would have to exist side-by-side. The XSLT 1.1 WD explicitly says that xsl:script doesn't prohibit other ways of defining extension functions, so that would be OK... ...But obviously not perfect. Really, we want to be able to take advantage of the defaulting mechanism in xsl:script that would allow EXSLT or VBScript or Java versions of the same functions to sit side by side and let the application choose which would be best. The only big impact that I can see at the moment is that the names of the functions should be declared as NCNames rather than QNames, with the relevant namespace prefix held in the 'implements-prefix' attribute on xsl:script. > Hmm does the XSLT 2.0 requirement to offer a mechanism for > specifying the namespace for unprefixed names in XPath affect > function (and mode and variable and .. ) names as well? (Not that > that affects your paper, I'm just musing) The XSLT 2.0 Requirements document only mentions *matching* with the default namespace, not *selecting* or any other use of qualified names (like the ones you mention), so I guess not. >> Issue: Optional arguments - should there be an extension attribute >> on xsl:param that indicates whether an argument is optional? > > If the element was out of xsl namespace, the attribute could be > unprefixed but yes you might want such a thing, although it only > makes sense to have things being optional "from the right" and so it > might be simpler to just mandate that everything is optional an that > a default is always specified (as is the case with named templates) > >> An XSLT processor must not signal an error if an extension function >> is called with fewer arguments than there are parameters defined >> for the extension function > > If you say this (which might be reasonable) then every argument is > optional, so I'm not sure I understand the issue quoted above. Put it another way - should there be something that indicates that an argument is *required*? It doesn't make sense to call set:intersection with less than two arguments - should there be some way of indicating that? Also, with recursive functions (and with recursive templates), might there be something to indicate whether a particular argument/parameter is private - only used for the recursion rather than for direct use? >> If no exsl:return element is instantiated during the execution of a >> function, the return value for the function is the empty string >> (''). > > see above for a possible alternative So, if we allow result nodes to be created by exsl:function then the lack of an exsl:return element indicates the return of an empty RTF (node-set in new money). Makes sense to me. >> Issue: exsl:return expressions - should the select attribute on >> exsl:return hold an extended XPath syntax that includes things such >> as conditional constructs? > > I don't know what you have in mind here, but probably, no. David Rosenborg argued that the bare minimum should be allowed in exsl:function (i.e. just xsl:param, xsl:variable and exsl:return) and that extra functionality like conditions should be included through extending XPath within the select attribute of exsl:return to include conditional constructs e.g.: test ? true : false I don't personally think it should, but that's what I had in mind. >> Extension functions defined using exsl:function can be called in the >> same way as XPath functions. Calling extension functions in this way >> causes arguments to be passed by position. > > I think this should say that functions defined via exsl:function > should be added to the current XPath context. Thus the following two > issues re calling syntax are moot. (They may be desirable features > but they would need to apply to any XPath extension function not > just these ones) Can you explain what you mean by 'current XPath context'? [Hmm... thinking about it, there are issues with imported and included stylesheets and repeated exsl:function elements with the same name that I haven't touched on in the draft - have to add that...] Allowing calls by name is an interesting issue because it's not something that makes sense for built-in functions (although I suppose we could assign their arguments names of 'arg1', 'arg2' and so on. >> Issue: exsl:if - should this specification define an exsl:if >> function for conditional processing that doesn't involve evaluating >> both the true and false parts? > > It would be nice but I'm not sure it can be done (as a pure XPath > 1.0 extension) > >> Issue: exsl:if - should this specification define an exsl:if >> function for conditional processing that doesn't involve evaluating >> both the true and false parts? > > You'll need something like that, I think. One of those times when your split personality comes through? ;) I agree with the former. I don't think we *need* exsl:if() if we can use xsl:choose. >> com:eval > > Maybe it's just because I've a headache, and no voice, but this one > eludes me at present, I'm sure it's doing something jolly useful > but.... Oh it's jolly useful. Basically it's a hack to allow the pseudo-dynamic evaluation of an XPath relative to the context node. If you look at a lot of Mike's extensions on Saxon, e.g. saxon:max(), they have optional second arguments that give an expression to be evaluated for each node, so you can get the maximum of a number of items with simply saxon:max(item) but you can get the maximum number of cells in the rows in a table with: saxon:max(tr, saxon:expression('count(td)')) So, to emulate that functionality I wanted to be able to have: num:max(tr, 'count(td)') Now ideally I'd have an evaluate() function. Then com:eval will simply be: <exsl:function name="com:eval"> <exsl:arg name="node" select="/.." /> <exsl:arg name="expr" /> <xsl:for-each select="$node"> <exsl:return select="exsl:evaluate($expr)" /> </xsl:for-each> </exsl:function> (or some other hack around it if exsl:return isn't allowed in xsl:for-each.) However, I don't, so this is a way to do it without. The second argument and the relevant tr element is passed to the com:eval() function. At the moment, com:eval() just shifts it out to a template - the idea is that users can add their own templates to deal with the particular expressions that they use in their stylesheet. So if I want to deal with that 'count(td)' I have to write: <xsl:template match="tr" mode="com:eval"> <xsl:param name="expr" /> <xsl:choose> <xsl:when test="$expr = 'count(td)'"> <xsl:value-of select="count(td)" /> </xsl:when> <xsl:otherwise> <xsl:value-of select="." /> </xsl:otherwise> </xsl:choose> </xsl:template> or something similar. >> Function: node-set num:highest(node-set, string?) > > I'd call this max (a name you'd stolen earlier) Again, following the Saxon names. (Aside: these functions are just use cases, we can start real arguments about naming and functionality when we start discussing what should be in the core set of extension functions.) Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/ XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format