- From: <bugzilla@jessica.w3.org>
- Date: Tue, 04 Oct 2016 12:00:06 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29900
Bug ID: 29900
Summary: [XP31] Prepublication check of XP31: Section 2 Basics
Product: XPath / XQuery / XSLT
Version: Candidate Recommendation
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: XPath 3.1
Assignee: jonathan.robie@gmail.com
Reporter: mike@saxonica.com
QA Contact: public-qt-comments@w3.org
Target Milestone: ---
1. In the paragraph "The EQName production allows a QName to be written in one
of three ways:" several sentences are missing full stops; and it would probably
be better to write "uri" at the start of a sentence as "URI" or "Namespace
URI".
2. In the following paragraph the first sentence "The EQName production allows
expanded QNames to be specified using either a QName or a URIQualifiedName,
which allows the namespace URI to be specified as a literal. " is a restatement
of what goes immediately before and could be dropped. Then start the para with
"The namespace URI value *in a URIQualifiedName* is whitespace normalized...
3. The definition of "lexical QName" is misplaced at the end of this paragraph.
It should probably go into the separate para above this one.
4. In the paragraph starting "This document uses the following namespace
prefixes to represent the namespace URIs with which they are listed. Use of
these namespace prefix bindings in this document is not normative.": (a) the
list of prefixes seems incomplete - what about map, and array (and for
completeness, math)?
- I think that when we write, for example, "$array($key) is equivalent to
array:get($array, $key)" then there is a sense in which the prefix binding is
indeed normative. What I think we mean to say is "Although these prefixes are
used within this specification to refer to the corresponding namespaces, these
bindings will not necessarily be present in the static context of every XPath
expression, and XPath authors are free to use different prefixes for these
namespaces, or to bind these prefixes to different namespaces".
5. The two paragraphs starting with "Element nodes have a property called
in-scope namespaces." are misplaced. We talked about the data model, then we
talked about some basics in the grammar, now we're talking about the data model
again, but we didn't warn the user of the change of topic. The two paras would
be better moved up the section to go with other stuff on the data model.
6. §2.1.1. (Probably out of scope for an editorial bug): Static context /
statically known collations - there are no XPath expressions that require
static knowledge of collation URIs.
7. §2.1.1. Statically-known-documents and statically-known-collections are
written very much as if the mapping is expected to be an enumeration of known
URIs. But I think it's perfectly valid to read it as a functional mapping,
including for example a rule about the type of documents whose name ends in
".html". Perhaps a note saying that the mapping may be a function rather than
an enumeration could be added?
8. §2.1.2 Dynamic context "that is available at the time the expression is
evaluated". It would be nice to avoid the temporal language: "The dynamic
context of an expression is defined as information that needed for the dynamic
evaluation of an expression."
9. §2.1.2, para starting "Certain language constructs, notably the path
operator E1/E2, the simple map operator, and the predicate E1[E2]," For
symmetry, expand "the simple map operator E1!E2", and give a hyperlink.
10. §2.1.2 "The inner focus exists only while E2 is being evaluated. When this
evaluation is complete, evaluation of the containing expression continues with
its original focus unchanged" Again it would be nice to avoid the temporal
language. With lazy evaluation, parallel processing etc this use of "while" and
"when" is potentially misleading. Try "The inner focus is used only for the
evaluation of E2. Evaluation of E1 continues with its original focus
unchanged."
11. §2.2.1 Data model generation. The title of the section is wrong; W3C
generates the data model, it doesn't happen as part of this process.
(Unfortunately the title also appears on the diagram). What the process is
actually describing is construction of a data model instance from external data
sources.
12. §2.2.1 "Before an expression can be processed, its input data must be
represented as an XDM instance." As a temporal statement, this is plain wrong.
The processes can be concurrent (with streaming they are definitely
concurrent). Change to "The input data for an expression needs to be
represented as an XDM instance".
12a. Same sentence, "an XDM instance". We have defined "XDM instance" as a
synonym for "value". But throughout this section we are clearly using the term
to mean a set of values. For example, the Variable Values in the dynamic
context is clearly a set of values (or XDM instances), not a single XDM
instance. We either need to change the way we define the term or the way we use
it.
13. §2.2.3.1 " In XQuery 3.1 and XPath 3.1, the rules for static type
inferencing are entirely implementation-defined." Implementation-defined or
-dependent? Do we really want to require an implementation to publish its
static type inferencing rules? (Speaking as an implementor, I have no intention
of doing so.)
14. §2.2.3.1 and elsewhere. There are about 15 references to the "Static Typing
Feature" all of which could usefully be hyperlinked to the definition of the
term.
15. §2.2.3.2 "It occurs after completion of the static analysis phase." Again,
temporal language that appears to preclude techniques such as JIT compilation.
Change to "It is dependent on successful completion of the static analysis
phase."
16. §2.2.4 talks of "the XDM instance" - see 12a above.
17. §2.3.1 para 3, stray whitespace towards end of para.
18. §2.3.1 para 9, "An implementation can raise a dynamic error for *a an*
XPath expression"
19. Same para, more substantively, "query" should be "expression".
20. §2.3.4 refers to "Conditional, switch, and typeswitch expressions must not
raise a dynamic error..." Switch and typeswitch expressions are XQuery-only.
21. §2.5 first note "XQuery continues to use". This spec is about XPath. The
note is in any case unhelpful. Both XSD 1.0 and XSD 1.1 use the terms "type"
and "datatype" pretty well interchangeably. Certainly in both cases "datatype"
is used only in part 2, whereas our type system is equally concerned with the
types of part 1.
22. §2.5.1 "[Definition: xs:error is a simple type with no value space,
available defined in Section 3.16.7.3 xs:error XS11-1. can be used in the 2.5.4
SequenceType Syntax to raise errors.]" Some typo here around "available
defined.".
23 § 2.5.5.2 penultimate bullet, "The ItemType array(T) matches any array in
which the type of every entry is T." The things in an array are members, not
entries.
24. §2,5,7 In the Note, ungrammatical sentence "Although the practical uses of
xs:error as a sequence type are limited, but they do exist."
--
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Tuesday, 4 October 2016 12:00:32 UTC