[Bug 29903] [XP31] Prepublication check of XP31: Expressions

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29903

--- Comment #1 from Michael Kay <mike@saxonica.com> ---
1. §3.1 "Some primary expressions contain enclosed expressions." This seems
like a weak attempt to provide justification for putting enclosed expressions
here, where they don't really belong. I would put them in a level-3 subsection
literals and variable references and other primaries.

2. §3.1.5.3 Function coercion: "The function conversion rules result in
applying function coercion to $f, wrapping $f in a new function ($p) with the
signature function(xs:string) as xs:boolean." Does the new function have a
name? What does function-name($p) return? Does this depend on whether coercion
to the required type was actually necessary?

3. §3.1.5.3 Function coercion, section on maps: "When the fn:filter() function
is called, the following occurs to the function" What means the phrase "to the
function"?

4. Same section, the map example in its explanation has 3 occurrences of
"query" that should be "expression".

5. §3.1.7 " [Definition: An anonymous function is a function created by an
inline function expression.]" I suggest:  [Definition: An anonymous function is
a function with no name. Anonymous functions may be created, for example, by
evaluating an inline function expression or by partial function application.]

6. §3.2, just before 3.2.1, "Dynamic function ^ are described in 3.2.2 Dynamic
Function Call." Insert "calls".

7. §3.2.1 "[Definition: A predicate whose predicate expression returns a
numeric type is called a numeric predicate.]" Expressions do not return types.
Are we talking of the static type here? Surely not. If it's the dynamic type,
as it must be, then being "numeric" is not a property of the predicate, but of
a particular evaluation of the predicate. Fortunately the term "numeric
predicate" is never used so we can delete the troublesome definition.

8. §3.2.2 Dynamic Function Call. Headings describing syntactic constructs are
generally plural: dynamic function calls.

9. §3.3.1 "Relative path expressions are binary operators on step expressions,
which are named E1 and E2 in this section.". No, expressions are not operators.
Furthermore, a RelativePathExpr can clearly contain more than two operands, and
we said earlier that "A path expression consists of a series of one or more
steps". Suggest (a) adding to the previous section a para:

A path expression that starts with "/" or "//" selects nodes starting from the
root of the tree containing the context item; it is often referred to as an
*absolute path expression*.

Then (b) replacing the first two paras of §3.3.1 with:

A relative path expression is a path expression that selects nodes within a
tree by following a series of steps starting at the context node (which, unlike
an absolute path expression, may be any node in a tree). 

Each non-initial occurrence of "//" in a path expression is expanded as
described in 3.3.5 Abbreviated Syntax, leaving a sequence of steps separated by
"/". This sequence of steps is then evaluated from left to right. So a path
such as E1/E2/E3/E4 is evaluated as ((E1/E2)/E3)/E4. The semantics of a path
expression are thus defined by the semantics of the binary "/" operator, which
is defined in §3.3.1.1

I would also suggest adding a Note: Although the semantics describe the
evaluation of a path with more than two steps as proceeding from left to right,
the "/" operator is in most cases associative, so evaluation from right to left
usually delivers the same result. The cases where "/" is not associative arise
when the functions fn:position() and fn:last() are used: A/B/position()
delivers a sequence of integers from 1 to the size of (A/B), whereas
A/(B/position()) restarts the counting at each B element.

10. §3.3.2.2 "A name test is true if and only if the kind of the node is the
principal node kind for the step axis and the expanded QName of the node is
equal (as defined by the eq operator) to the expanded QName specified by the
name test." We've just said that a wildcard is a name test, and this doesn't
"specify" an expanded QName. I suggest structuring this as:

A node test is either an EQName, a wildcard, or a kind test.

and then split the rules that follow into these three cases.

11. §3.5 last bullet "Unary operators have higher precedence than binary
operators" - should qualify this with: (other than "!", "/", and "[]")

12. The Note just before 3.6 "Multiple consecutive unary arithmetic operators
are permitted by XPath 3.1 for compatibility with [XML Path Language (XPath)
Version 1.0]." seems unnecessarily apologetic. It's a perfectly natural thing
to allow, not some strange XPath 1.0 weirdness that we perpetuate only because
we have to.

to be continued

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 4 October 2016 14:58:59 UTC