- From: Stephen Buxton <stephen.buxton@oracle.com>
- Date: Thu, 15 Apr 2004 20:56:28 -0700
- To: public-qt-comments@w3.org
These are Oracle's Formal Semantics Last Call comments, editorial.
By "editorial" we mean typos, plus suggestions on markup and wording to
make the spec more readable.
Each comment has a header, with a number, the section, section title, an
internal-to-Oracle comment number, and a 1-line summary.
----------------------------------------------------
E1. SECTION F10: Particles
430: Typo
editorial
"Particles can be either and element reference ..."
"and" should be "an"
----------------------------------------------------
E2. SECTION 4.4: Arithmetic Expressions, Core Grammar
433: Typo
editorial
"There are no Core grammar rules for value comparisons ..."
Should be:
"There are no Core grammar rules for arithmetic expressions ..."
----------------------------------------------------
E4. SECTION 4.12.4 Castable, Normalization
437: Castable normalization rule is specified twice (cut-paste error ?)
editorial
The "normalization of castable" expr rule is listed twice.
----------------------------------------------------
E5. SECTION 7.2.2.1, Static Semantics of axes
446: Suggest subsections under 7.2.2.1
editorial
Please subsection 7.2.2.1 based on the axes access section
(child axes, parent axes, attribute axes etc.) for readability.
----------------------------------------------------
E6. SECTION 7.2.2.1, Static Semantics of axes
444: possibly missing words 'type of'
editorial
"The static type of the attribute axis is similar to the static the
child axis."
Should be ?
"The static type of the attribute axis is similar to the static [type
of] the child axis."
----------------------------------------------------
E7. SECTION 2.1.3, Notations for inference rules
448: inference rules need clearer markup
editorial
The inference rules are written as a collection of premises and a
conclusion,
written respectively above and below a
dividing line.
Having seen these rules in different fonts, browsers, print-outs, it is
clear
that some more markup is needed to make it easier to read the rules.
Suggest: draw a box around the entire rule and/or make some
other markup around the entire rule, such as background shading.
When there are multiple inference rules listed together,
it is very hard for the reader to mentally draw the boundary around
each inference rule. This is especially true for inference rules without
premises. When there are many inference rules, some of which have
no premises and some of which have premises, listed in a cluster under
a section, it is hard for reader to separate the inference rules.
See especially 7.2.3.1.1, 7.2.3.1.2, 7.2.3.2.2
----------------------------------------------------
E8. SECTION 7.2.3.1.2, kind tests
450: possible mis-wording in 7.2.3.1.2, 3rd paragraph
editorial
"After normalization of the kind test an XQuery type, the expression's
type is compared to the normalized XQuery type."
Should be ?
"After normalization of the kind test [as] an XQuery type, the
expression's type is compared to the normalized XQuery type."
----------------------------------------------------
E9. SECTION 3.4.1, Predefined Types
458: xdt:untyped definition
editorial
The definition of xdt:untyped includes xdt:untypedAny.
Presumably this was overlooked when changing xdt:untypedAny to xdt:untyped.
----------------------------------------------------
E10. SECTION 6.1.4, The fs:convert-simple-operand function
465: reference to convert_untypedAtomic
editorial
fs:convert-simple-operand function makes a reference to a function
convert_untypedAtomic. Please make a reference to 6.2.6 where
convert_untypedAtomic is defined.
convert_untypedAtomic is also used in 6.2.1, with no reference to a
definition.
----------------------------------------------------
E11. SECTION 3.6.7, Static Typing Extensions
464: There is no definition of '<:' in 3.6.7
editorial
Suggest: add a reference to the definition of '<:' in 7.3.2.
----------------------------------------------------
E12. SECTION 4.1.4, Context Item Expression
455: static type analysis missing for context item expression
editorial
In the introduction section, it states that the context item may
be either a node or an atomic value. However, it does NOT explcitly
state that this as an inference rule in a 'static type analysis' rule.
----------------------------------------------------
E13. SECTION 6.2.2, The fn:collection and fn:doc function
439: The first premise of the first inference rule for fn:doc() is done
twice
editorial
StatEnv |- statEnv.docType(string) = Type
premise for fn:doc() first inference rule is listed twice
----------------------------------------------------
E14. SECTION 7.2.3.2, Dynamic semantics of node tests
469: Singular used when plural required
editorial
In the second paragraph under Semantics, the phrase "are similar to
those for axis" should read "are similar to those for axes".
----------------------------------------------------
E15. SECTION 4.7.1, Direct Element Constructors
467: Two typos
editorial
Under Normalization, the paragraph beginning "So to preserve useful type
information" includes the phrase "constructor's that contain"; the
apostrophe between the "r" and "s" is incorrect, because the constructor
being discussed does not posess "that contain"...it's merely a plural
form of "constructor".
In the same paragraph, the last sentence reads "Here is the
normalization of the first and fourth examples above:" There are two
things wrong with this sentence. First, it's unclear whether "first"
and "fourth" are counting in reverse document order ;^) or in document
order starting at the subheading "Normalization". More importantly,
the shaded text that follows that sentence makes it clear that the
examples are not the "first and fourth", but either the "second and
fourth" (if in reverse document order) or the "first and third" (if in
document order from the subheading).
----------------------------------------------------
E16. SECTION 4.7.3.6, computed comment constructors
436: computed processing-instruction
editorial
Under the normalization section, the first 3 words
"Computed processing-instruction
should be
"Computed comment"
----------------------------------------------------
E17. SECTION 4, Expression
456: static type analysis for expressions with empty type
clarification
It is a static type error for most (but not all) expressions to have the
empty type.
Is '3+()' a static type error ?
We expect NO, because + is normalized into fs:plus() (6.1.1), which can
return empty type.
Does 'local namespace declaration' defined in 4.7.4 raise a static type
error,
as the static type analysis yields empty type ?
----------------------------------------------------
E18. SECTION 3.4.1, predefined types
457: definition of fs:numeric
editorial
The definition of fs:numeric does not appear to be right.
The usage of '&' and ';' and usage of _ do not seem to be right.
It should be:
define type fs:numeric restricts xs:anyAtomicType
{ xs:decimal | xs:float | xs:double}
----------------------------------------------------
E19. SECTION 2.3.3, Content models
461: '&' operator and XML SChema All
editorial
The definition in Formal Semantics of '&' operator is,
(element a & element b) =
element a, element b
| element b , element a
The text says "The interleaved product represents all groups in XML Schema.
But "all groups in XML Schema" would result in:
(element a & element b) =
element a, element b
| element b , element a
| element a
| element b
| empty
Suggest changing this text"
"The interleaved product represents all groups in XML Schema. All groups
in XML Schema are restricted to apply only on global or local element
declarations with lower bound 0 or 1, and upper bound 1."
to e.g.
"The interleaved product represents all groups in XML Schema, restricted
to apply only on global or local element declarations with lower bound 0
or 1, and upper bound 1."
----------------------------------------------------
E20. SECTION 7.2.3.2.2, kind tests
451: The conclusion of the inference rule for comment() test is incomplete
editorial
When the Formal Semantics document is printed (using Netscape),
the inference rule for comment nodes is printed as:
not(fn:node-kind(NodeValue) = "comment")
-----------------------------------------------------
()
The () conclusion should be replaced as
dynEnv|- test comment() with PrincipalNodeKind of NodeValue => ()
When the Formal Semantics document is displayed directly in a browser
(including Netscape),
the conclusion displays as expected.
----------------------------------------------------
E21. SECTION 6.2.7, 6.2.8, fn:remove and fn:reverse function
441: 'factored type' not defined
editorial
There is no definition of 'factored type'.
Suggest defining it in 7.4 where prime type and its computation is defined,
and then reference this definition wherever 'factored type' is used.
----------------------------------------------------
E22. SECTION 5.11 - variable declaration
434: no 'static type analysis' section
editorial
There is no 'static type analysis' section for Variable declaration.
----------------------------------------------------
E23. SECTION 6.2.6, The fn:min, fn:max, fn:avg, and fn:sum functions
468: Incomplete list of types for fn:mix and fn:max
editorial
Under the subheading "Semantics", the paragraph starting "Instead of
writing a separate judgement",
the second sentence deals with fn:min and fn:max.
That sentence has a list of data types that incorrectly omits the types
xs:date, xs:time, and xs:dateTime.
As evidenced by F&O section 15.4.3, fifth paragraph, sentence beginning
"If date/time values do not have a timezone...",
F&O properly handles fn:max and fn:min applied to those three types.
Please add these three types to the list in the second sentence.
(Do not add it to sentences dealing with fn:avg and fn:sum, of course.)
----------------------------------------------------
E24. SECTION 2.3.2, Item types
460: element content nodes
editorial
Section 2.3.2 says:
"We distinguish between document nodes, attribute nodes,
and nodes that can occur in element content (elements, comments,
processing instructions, and text nodes), as we need to refer to
element content nodes later in the formal semantics."
The spec refers to "element content type" elsewhere, but not "element
content NODES".
----------------------------------------------------
Received on Friday, 16 April 2004 00:00:48 UTC