Re: Select-like attributes in extension elements?

[keshlam]

Just making sure I understand the question: Is the user looking for arbitrary XPath interpretation, similar to
http://www.exslt.org/dyn/
or are they specifically looking for the equivalent of select?

We do have an implementation of exslt:dyn, though of course it works only in interpretive mode and any interactive XPath evaluator would be likewise constrained. If someone's looking for an "API", adding one to that code is the best solution I can think of offhand.

Something more select-like (with hardcoded path), theoretically might be implementable even in compiled mode, if there was some way for us to recognize that this particular attribute was supposed to be a nodeset retrieval request. I guess, since the extension behivor is specific to the implementation, we could reserve a specific namespaced attribute (or namespace alone, so multiple selects could exist?) to cue the processor that this is our intent. This would be roughly equivalent to setting a variable to a nodeset using select, then passing that variable into the extension; just a bit less verbose.

Of course all of this is going to be emphatically nonportable to other processors, which makes me a bit nervous about investing too much effort in it.

______________________________________
"... 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)