ORA-FS-001-E: Formal Semantics comments, editorial

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