On Sun, Mar 30, 2014 at 10:28 AM, Michael Kay <mike(_at_)saxonica(_dot_)com>
wrote:
Personally I'm happy to go to three or four lines for an XPath expression,
but beyond that I start to feel uncomfortable with it; can't really explain
why.
In my Balisage-2013 article "Programming in XPath 3.0" [1], I raised
the need for an XPath "import clause". I believe that if we have such
feature in XPath, this will be used by developers to keep their XPath
programs short -- exactly as in the case of XSLT and any other
language with include/import facility.
Simpler than this, we only need a standard XPath (3.1 ?) function
eval(string) and combining it with the unparsed-text(URI) function,
which is now XPath (3.0) standard function, we achieve the wanted
import effect.
In case eval() doesn't become a standard function in XPath 3.1, there
could be a de-facto standard such function -- similarly to the case of
xxx:node-set() function for XSLT 1.0. Similarly to exsl:node-set(), we
could have a portable standard expath:eval().
Personally, I *had* to use rather long XPath expressions, because such
facility didn't exist at the time I was writing FXSL 2.0. In case a
modularization facility is provided in XPath, I would like to use
multiple short modules. This not only makes the code shorter and more
readable, but is also a great way to make reusable XPath expressions
-- and most likely these will be predominantly function items, or,
more precisely, maps that have as values function items and as keys
their corresponding string names.
Cheers,
Dimitre
[1] http://www.balisage.net/Proceedings/authors.html#NovatchevDimitre
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--