> Is it that big an ask to be able to set a variable from an extension element?
Specifically, to set a variable to something other than XPath-compatable data, since of course the syntax you show already works for result tree fragments... ... I'm really not sure. Probably worth drafting a prototype to see just how much it affects. Don't forget to consider both compiled and interpreted modes, and to make sure it's not going to adversely affect performance when the new feature is not in use. Conceptually the changes would all be local to xsl:variable. But I find myself nervous about whether and how they would propagate through the rest of the system -- whether we might wind up relaxing typechecking elsewhere and losing some of the strength of error detection. Personally, I'm always nervous about extensions generally, given their inherent nonportability and the debugging hassles they can entail. With the exception of the EXSLT set -- much of which was folded into XSLT 2.0, and all of which was designed to be fairly cleanly isolatable/reimplementable -- I've seen them misused more often than I've seen them used well. If I were in your shoes, I would be thinking more in terms of creating a separate preprocessing stage (possibly taking advantage of Xalan's XPath support) than embedding the new language into the XSLT stylesheet; that would be a much more robust solution. ______________________________________ "... Three things see no end: A loop with exit code done wrong, A semaphore untested, And the change that comes along. ..." -- "Threes" Rev 1.1 - Duane Elms / Leslie Fish ( http://www.ovff.org/pegasus/songs/threes-rev-11.html)
