- From: Michael Rys <mrys@microsoft.com>
- Date: Mon, 14 Jun 2004 17:51:47 -0700
- To: <public-qt-comments@w3.org>
MS-FS-LC1-058 Section 4.1.3 Editorial "It is a static error for any expression other than () to have the empty type (see [4 Expressions].)": Make this statement less absolute: "Often it is a static error for any expression to have the empty type. See [4 Expressions] for the detailed rules." MS-FS-LC1-059 Section 4.1.5 Editorial "xdt:anyAtomic" -> "xdt:anyAtomicType" MS-FS-LC1-061 Section 4.1.5 Editorial Instead of listing prototypical values, just explain what it is being used for, MS-FS-LC1-063 Section 4.1.5 Editorial Please clarify when dispatch based on provided union type is needed. Most function dispatches are based on arity and not type and thus would not lead to a successful application of this rule. MS-FS-LC1-066 General Editorial Please provide op: functions with links to their definition in the F&O spec. MS-FS-LC1-067 Section 4.2.1/4.3.2 Editorial It would be better to combine the rules into one section. MS-FS-LC1-069 Section 4.2.1 Editorial The remainder of the static semantics of axis and node test is given in section 7. But there is no link visible that takes one there and it is not clear in this section how the semantics play out. Either move parts up or add references. MS-FS-LC1-105 Section 4.3.3 Editorial Please link to section 6.2.10 where the op:union et al are defined instead to 6. MS-FS-LC1-112 General Editorial/Technical Please also refer to the section where the dynamic semantics of the functions is specified. Not only the function invocation! MS-FS-LC1-115 Section 4.7.1 Editorial "The next example contains six element-content units:": depends on the XQuery boundary whitespace handling rules since you have boundary whitespace in your query. MS-FS-LC1-117 Section 4.7.1 Editorial The section numbering needs to be better. Elements do not have their own subsections but attributes do. Others are in separate 4.7.2. MS-FS-LC1-124 Section 4.7.3.4 Editorial "The static semantics checks that the argument expression has type xs:string." This is guaranteed by the normalization. So why do we need this condition? MS-FS-LC1-128 Section 4.8 Editorial There are several places (including the title) where we refer to FLWR instead of FLWOR. Please fix. MS-FS-LC1-131 Section 4.12.2 Editorial Replace " an optional VarRef, which is bound the value of the input expression" with " an optional VarRef, which is bound to the value of the input expression"
Received on Monday, 14 June 2004 20:51:52 UTC