- From: Michael Rys <mrys@microsoft.com>
- Date: Fri, 9 Jul 2004 13:47:11 -0700
- 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