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

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

--- Comment #2 from Michael Kay <mike@saxonica.com> ---
13. §3.11.1.1 Map Constructors. First note is broken: "In some circumstances,
it is necessary to include whitespace before or after the colon of a
MapConstructorEntry to ensure that this grammar is correctly parsed it is
parsed as intended. MapKeyExpr ends with a name and the MapValueExpr starts
with a name.".

14. §3.11.1.1. This Note should be deleted as it is no longer true: "In some
edge cases involving numerics, the same key value relationship is not
transitive."

15. §3.11.3.2. Note, "the focus for evaluating S is the same ..." Sentence
should start with capital letter.

16. §3.11.3.2. I think it's worth a mention (e.g. by way of an example) that
$A?2 fails FOAY0001 if ANY array in $A has no member at position 2. (Generally,
I think the section on arrays could do more to point out that referencing a
non-existent position is a dynamic error).

17. §3.14 "sequence types are used in instance of, cast, castable, and treat
expressions." Find some way to start with a capital letter, e.g. "The instance
of, cast, castable, and treat expressions are used to test whether a value
conforms to a given type or to convert it to an instance of a given type." (No
need to mention sequenceType syntax here, it's not used in all these
expressions anyway.)

18. §3.14.2 The simplified treatment of cast expressions is good but I would
add back: The result of a cast expression is one of the following: (a) a value
of the target type (or, in the case of list types, a sequence of values that
are instances of the item type of the list type), (b) a type error, if casting
from the source type to the target type is not supported (for example
attempting to convert an integer to a date), or (c) a dynamic error, if the
particular input value cannot be converted to the target type (for example,
attempting to convert the string "three" to an integer).

19. §3.14.3 castable. We say correctly that this gives an error if evaluating E
fails, and returns false if the resulting value cannot be cast to the target
type. We've had debates about whether a failure to atomize the result of E
throws an error or returns false. I'm surprised that the spec doesn't give the
answer to this question. I think the agreed answer is that a failure to
evaluate E *or to atomize its value* is reported as an error.

20. §3.15 simple map operator. Let's try to introduce this with something less
vacuous than "The simple map operator "!" is used for simple mappings". Replace
the first para by "A mapping expression S!E evaluates the expression E once for
every item in the sequence obtained by evaluating S. The simple mapping
operator "!" can be applied to any sequence, regardless of the types of its
items, and it can deliver a mixed sequence of nodes, atomic values, and
functions. Unlike the similar "/" operator, it does not sort nodes into
document order or eliminate duplicates."

21. §3.15 The second para ends with "otherwise the order of the returned
sequence is implementation-dependent." There is no "if" to go with this
"otherwise". I suspect it is XQuery text that's conditional on ordering mode.

22. §3.15 We provide some rather complex examples where "!" is combined with
"/", but we don't provide any simple examples where it is used on its own.
Suggestions:

fn:string-join((1 to $n)!"*") - returns a string containing $n asterisks

$values!(.*.) => fn:sum() - returns the sum of the squares of a sequence of
numbers (useful in statistical calculations)

string-join(ancestor::*!name(), '/') - returns a path containing the names of
the ancestors of an element, separated by '/' characters

23 §3.16 arrow expression. We say "applies a function to the value of a primary
expression", but in the syntax it's a unary expression, which doesn't have to
be a primary. For example it can be /*/empl/remun/@salary => avg(), where the
LHS is quite complex.

24. §3.16 arrow expression. I suggest avoiding the term "unreadable", which is
a matter of opinion, by replacing the para under the definition with

This syntax is particularly helpful when applying multiple functions to a value
in turn. For example, the following expression invites syntax errors due to
misplaced parentheses:

and then replace the unsubstantiated claim "Many people consider the following
expression easier to read, and it is much easier to see that the parentheses
are balanced:" by "In the following reformulation, it is easier to see that the
parentheses are balanced". I would also put whitespace around the arrows to
improve readability.

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

Received on Tuesday, 4 October 2016 17:32:33 UTC