W3C home > Mailing lists > Public > public-qt-comments@w3.org > April 2004

ORA-FS-003-E: Formal Semantics comments, bugs

From: Stephen Buxton <stephen.buxton@oracle.com>
Date: Thu, 15 Apr 2004 20:56:52 -0700
Message-ID: <407F5984.6000300@oracle.com>
To: public-qt-comments@w3.org

These are Oracle's Formal Semantics Last Call comments, editorial.

By "bugs" we mean mistakes in the text. "bugs" differ from "editorial" 
in that "bugs" significantly change the meaning of the document.

Each comment has a header, with a number, the section, section title, an 
internal-to-Oracle comment number, and a 1-line summary.


B1. SECTION F9.3, Sequence Group

429: Sequence Vs Choice Group

Immediately below schema mapping section, "Choice groups" should be 
"Sequence groups".


B2. SECTION, Static Semantics of axes

443: axis:child:: of document {Type} should include text *

The inference rule for child axis of document node type should include 
text nodes as well.

statEnv |- axis child:: of document {Type} : Type & 
processing-instruction *&
comment*  & text*

Note text* is missing here.


B3. SECTION, Dynamic semantics of node tests

449: bug in the example conclusion

For the 1st example,
element bar:c of type xs:int {5}

should be

element foo:d of type xs:int {5}

since we test for foo:*


B4. SECTION 3.5.3, Errors and Optimization

452: add 'NOT' in the last sentence of the section

The last sentence of 3.5.3 says
"In the example above, a static type error would be
raised because a path expression may be applied to an atomic value"

It should be

"In the example above, a static type error would be
raised because a path expression may NOT be applied to an atomic value"


B5. SECTION 3.1.2, Dynamic Context

462: dynEnv.varValue can also map an expanded variable name to #EXTERNAL

In addition to Value or #IMPORTED(URI), an expanded variable name can 
also be mapped to #EXTERNAL.


B6. SECTION 3.4.4, Sequence Type Matching

453: normalization of  document-node(ElementTest)

There should be NO () after
processing-instruction, comment, text types
when defining normalization of document-node(ElementTest)
because XQuery formal semantic type has no () for 
processing-instruction, comment, text types.


B7. SECTION 4.7.1, Direct Element Constructor

404: Normalization rule for Direct element constructor

The normalization rule for a Direct element constructor distinguishes
between the constructor having one element-content unit from the one having
more than one element-content unit as illustrated in 4.7.1 section.

The contructor containing one element-content unit preserves the typeinfo.

== element date {xs:date("2003-03-18")}

This rule appears to contradict the XQuery 1.0 language spec section,
type of a constructed element.
In XQuery 1.0, there is no distinction between a construct having one
element-content unit vs the one having more than one element-content unit.

If we plan to implement Michael Kay's suggestion
(documented as an editorial note in 
http://www.w3.org/TR/2003/WD-xquery-semantics-20030502/ section 4.7.1),
then the XQuery 1.0 spec needs to be changed to accommodate this.


B8. SECTION 7.6.3, Atributes in validation context

466: inference rule for the case of no attribute name present

The inference rule for the case of no attribute name present is not right.

The rule is stated as:

statEnv |- axis attribute:: of element of TypeName: Type1
statEnv |- in context type(TypeName) with mode ValidationMode resolves to

The conclusion should refer to Type1, NOT Type2.

Received on Friday, 16 April 2004 00:00:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:56:56 UTC