This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
1. The first sentence of A.1.1 ("The following definitions will be helpful in defining precisely this exposition.") is ghastly and can simply be deleted. Readers can judge for themselves whether the definitions are helpful. 2. A.1.2 says "Therefore to reduce the need for lookahead, if the token immediately following a slash can form the start of a RelativePathExpr, then the slash must be the beginning of a PathExpr, not the entirety of it." This implies that the rule is only needed to avoid the need for lookahead. However, it is also needed to disambiguate expressions like "/union/*" where there are two valid interpretations which cannot be distinguished by any amount of lookahead. 3. A.1.2 says "Unprefixed function names spelled the same way as language keywords could make the language harder to recognize.". For "harder" read "impossible" (and for "recognize" read "parse"). Without this rule the expression "element(foo)" would be ambiguous. 4. A.4, row 20, is I believe using "?" to mean the binary/postfix lookup operator. The unary lookup operator has highest precedence of all and should perhaps be in a new row 21. 5. In B.2 para 1, the sentence "In some cases, the operator function does not implement the full semantics of a given operator." is misleading. I think it should say "The operator function fully defines the semantics of a given operator for the case where the operands are single atomic values of the types given in the table". 6. In the operator mapping table, the entries where xs:anyURI is one of the types are redundant, since the entry for xs:string suffices (and fortunately is always the same) - the rules say that the anyURI can be promoted to xs:string to find the applicable entry in the table. 7. E.1 Inconsistent use of space within entries like "RFC 2119" or "RFC3986". 8. XQuery 3.0 is listed in the non-normative references, but the document does not refer to XQuery 3.0. 9. Ditto for Document Object Model. 10. Ditto for XPath 2.0 11. There is a non-normative reference to XPath 3.1. It is not usual for a specification to refer non-normatively to itself. 12. It is not clear what purpose the references in E.3 (Background material) serve 13. In Appendix F, error XQST0052, it's not clear what construct this refers to. Change to "The type *named in a cast or castable expression* must be... 14. The description of error XQST0070 includes conditions that cannot arise in XPath. 15. Error XPST0080, missing comma after NOTATION. 16. The description of XPDY0130 is the only place it suggests that limits are implementation-defined. If a conformant implementation is required to document its limits, this is not the right place to say so. 17. Error XPST0133 is an orphan. 18. Appendix G: the glossary should be sorted using a caseblind collation.
19. The change log refers to the "first Candidate Recommendation" and the "Second Candidate Recommendation" [sic]. It is difficult for readers to identify the documents associated with these phrases. Use specific dates of publication and link to the relevant dated drafts. 20. I.3.1 item 2 is about annotations and assertions, which is XQuery-only. Item 5 is about library modules which is XQuery-only. 21. There is a reference to "Resolves Action A-598-05" which seems inappropriate. Every substantive change made after CR should have a bugzilla entry for traceability. 22. I.3.1 list item 13 could usefully be absorbed into item 1, thus losing the problem that there is no Bugzilla reference. 23. I.3.2 item 5, something missing in the sentence "Modified 4 Conformance to use the term . Resolves Bug 28023." 24. I.3.2. list item 9 "Significantly changed description of names in Basics. Resolves Bug 28241." Here "Basics" should be a specref. 25. I.5 consists entirely of its only subsection; there is a redundant level. 26. I.5 item 5 "Fixed an example" is not a substantive change, it's editorial. Drop it. 27. I.5 item 11 "Eliminated use of to array functions that are no longer in Functions & and Operators, such as fn:seq(). Changed ay: prefix to array: to match current Functions & and Operators." - I don't think we need to list minor changes between working drafts like this. Items 6-9 and 11-15 in this list are subsumed by item 1 "added maps and arrays". 28. The presentation of information about incompatibilities is somewhat incoherent. I would be inclined to structure appendix H as H.1 Incompatibilities relative to XPath 3.0 -- (map and array become reserved function names, from I.1) H.2 Incompatibilities relative to XPath 2.0 -- (union types, from I.1) -- (function, namespace-node, and switch become reserved, from the XPath 3.0 incompatibility list H.3 Incompatibilities relative to XPath 1.0 -- the existing appendix H.
29. A.1 bullet 2, "It adds a notation for referring to productions in external specs." should say "specifications".
How would "element(foo)" become ambiguous without reserved function names?
For 27, I like the additional detail Jonathan added since it helps highlight changes an implementer will need to make.
Fixed except for the items mentioned in Comment 3 and Comment 4.
(In reply to Josh Spiegel from comment #3) > How would "element(foo)" become ambiguous without reserved function names? StepExpr would derive "element(foo)" in two different ways: (1) the currently-valid way, via AxisStep -> ForwardStep -> AbbrevForwardStep -> NodeTest -> KindTest -> ElementTest, and (2) the not-currently-valid way, via PostfixExpr -> PrimaryExpr -> FunctionCall.
Thanks Michael. I should have seen that...
3 is now fixed as well.