On 24/04/2012 20:41, ihe onwuka wrote:
key() in an XSLT 2.0 pattern must have exactly two arguments
Correct. See http://www.w3.org/TR/xslt20/#pattern-syntax
how come?
When people ask for reasons why the spec is as it is, there are two ways
of answering:
(a) the historically accurate response. This involves searching the
archives of working group discussions to see whether any relevant
proposals were made, and whether they were accepted or rejected; if a
proposal was rejected it then involves asking individual members of the
WG why they voted one way or the other, since individual reasons for
voting will not be recorded in the minutes; if no proposal was made it
involves asking indivdual members of the WG why they did not see fit to
make a proposal, and indeed it involves asking the user community why
they did not request the feature in response to one of the many drafts
issued for consultation.
(b) the post-hoc justification: "can you defend the fact that the spec
is the way it is?". Here I think my answer would be that the syntax for
patterns is a very restricted subset of the syntax of XPath expressions,
and the WG has been traditionally conservative about extending it,
probably in the belief that a smaller language is much more susceptible
to the kind of analysis needed to build an efficient decision tree.
There has also been historically little demand for a more powerful
pattern language, with most users keeping patterns very simple most of
the time.
key() in patterns is used very little, and serves very little purpose,
since unlike key() in XPath expressions an index does not help
evaluation and there is really no strong reason to use key() in
preference to using a predicate. Adding the third argument to key()
would be oddly asymmetric: since there is no way in XSLT 2.0 of rooting
a pattern such as $x/a/b/c at a specific document node, it would be odd
to allow a key() pattern to be rooted in that way.
Michael Kay
Saxonica
--~------------------------------------------------------------------
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>
--~--