I don't think there's anywhere in the spec that says "in natural language"
that with the expression E1 < E2, the operand E2 can be a function call; and
I don't think there should be.
I differ from that opinion: the ability to specify a function call as
a location step is one of the radical changes from XPath 1.0 to XPath
2.0 and right now it is hidden in the grammar and requires a
three-step deduction from the grammar rules.
The result -- almost three years after the XPath 2.0 spec was
published -- is that very few people realize they can specify a
function call where a location step is expected.
While the specification should not be a tutorial, groundbreaking
changes and the most powerful new features should be at least
summarized in a special section of the document so that this could be
referenced when answering a question. When answering a question it
isn't at all convincing to ask the user to follow a traversal of
grammar rules in order to show that a major new feature really exists.
Even a single example in the spec. would also be of great help and a
step forward.
--
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play
On Thu, Jul 29, 2010 at 2:00 AM, Michael Kay <mike(_at_)saxonica(_dot_)com>
wrote:
XPath 2.0 changed the syntax so that "/" behaved like a proper orthogonal
binary operator by allowing any expression (subject only to precedence and
type rules) as its operands. It is of course a higher-order operator in that
it evaluates the right-hand operand repeatedly.
Quite properly, the semantics of E1/E2 are explained in terms that are
independent of the syntactic form of E1 and E2, and it's the grammar rules
that tell you what kind of expressions are allowed in E1 and E2. This is in
my view the correct way to describe an orthogonal functional language.
I don't think there's anywhere in the spec that says "in natural language"
that with the expression E1 < E2, the operand E2 can be a function call; and
I don't think there should be. People should expect to be able to use
function calls anywhere an expression is allowed, and the spec should only
draw notice to something that's an exception to the general rule.
When writing a tutorial, of course, different rules apply. In my book,
there's extensive discussion of the binary "/" operator on pages 602-604.
But the spec is not a tutorial.
Michael Kay
Saxonica
On 29/07/2010 06:11, Dimitre Novatchev wrote:
I can see from the productions of the XPAth 2.0 grammar that:
A StepExpr can be a FilterExpr (27)
and
A FilterExpr can be PrimaryExpr (38)
and
A PrimaryExpr can be FunctionCall (41)
However I cant see anywhere a description in natural language that a
step can be a function call, and I think it is important that this
fact be stated clearly enough.
Am I missing this text?
--~------------------------------------------------------------------
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>
--~--
--~------------------------------------------------------------------
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>
--~--