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

[FS] Editorial comments on section 7

From: Michael Rys <mrys@microsoft.com>
Date: Fri, 9 Jul 2004 13:47:11 -0700
Message-ID: <EB0A327048144442AFB15FCE18DC96C7035C3DD7@RED-MSG-31.redmond.corp.microsoft.com>
To: <public-qt-comments@w3.org>

MS-FS-LC1-070
Sections 7.2.2.1/7.2.3.1
Editorial	

Add more whitespace before the inferences 
statEnv |- axis Axis of none : none 
statEnv |- axis Axis of empty : empty 

MS-FS-LC1-075 
Section 7.1.4
Editorial	

Sometimes the type lookup results in just a type name, sometimes it
returns "of type Typename". Please be consistent.

MS-FS-LC1-077 
Section 7.1.10
Editorial

Can you add a more complex example that shows restrictions and
derivation?

MS-FS-LC1-080	
Section 7.1.7
Editorial

"if the complex type is mixed, interleaves the type with a sequence of
text nodes and xdt:anyAtomicType.": Note that the atomic type is or'ed
and not part of the interleave adjustment.

MS-FS-LC1-081
Section 7.1.9
Editorial/Technical

"statEnv |- Type2 is Type1 extended with union interpretation of
TypeName 
statEnv |- Mixed? Type1 adjusts to Type2 
------------------------------------------------------------------------
--------
statEnv |- of type TypeName expands to Type2 
" -> Are the number mixed up?

MS-FS-LC1-084
Section 7.1.6
Editorial	

Please add example.

MS-FS-LC1-095	
Section 7.2.2.1
Editorial	

Please remove the "improved" version for ancestor axis unless we fix the
type inference for the parent axis!

MS-FS-LC1-096
Section 7.2.3.1.1
Editorial

"statEnv |- QName1 of elem/type expands to expanded-QName 
statEnv |- QName2 of elem/type expands to expanded-QName": 
Add subscripts to expanded-QName and add an equality condition of the
two expanded Qnames (same for attributes)

MS-FS-LC1-097	
Section 7.2.3.1.1
Editorial	

Please add more whitespace between inference rules. The current spacing
is unreadable.

MS-FS-LC1-098
Section 7.2.3.1.1
Editorial

Replace 
"statEnv |- test * with "element" of element prefix:local TypeSpecifier?
: element prefix:local TypeSpecifier?"
With
"statEnv |- test * with "element" of element QName TypeSpecifier? :
element QName TypeSpecifier?"

Not every QName has a prefix! (same holds for attributes)

MS-FS-LC1-099
Section 7.2.3.1.1
Editorial	

How do we deal with testing an element name foo against element() ? I
would assume that the inferred type is element(foo)? and not
element(foo). Same for a against a|b. The result should be a? and not a
or raise an error. Same issues with *:b test a:*: should be a:b? and not
a:b. Please clarify the use of ? for syntactic purposes and as
Occurrence indicator

MS-FS-LC1-100
Section 7.2.3.1.1
Editorial	

With the adoption of element(name) being the same as the name name test,
can we simplify the specification by making them map to the same rules?

MS-FS-LC1-101
Section 7.2.3.1.2
Editorial	

"Document kind test" etc: What should be the editorial status of these
words? Title? Sentence?

MS-FS-LC1-102
Section 7.2.3.1.2
Editorial	

What should the following inferred type be: Inferred:
document(element(A), Kindtest: document(element(*,T)). That seems to be
document(element(a,T)?). However, I think it should be
document(element(a,T))?

MS-FS-LC1-103
Section 7.2.3.1.2
Comment	

We have not reviewed Element and Attribute kind tests since they will be
changed due to the change in SequenceType semantics.

MS-FS-LC1-108
Section 7.4
Editorial

The quantifier composition | and . (dot) are the same. Just use one of
them.
Received on Friday, 9 July 2004 16:47:16 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:20 UTC