- From: <bugzilla@wiggum.w3.org>
- Date: Sun, 17 Jul 2005 02:13:47 +0000
- To: public-qt-comments@w3.org
- Cc:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=1672 Summary: [FS] editorial: 4.8.4 Order By and Return Clauses Product: XPath / XQuery / XSLT Version: Last Call drafts Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Formal Semantics AssignedTo: simeon@us.ibm.com ReportedBy: jmdyck@ibiblio.org QAContact: public-qt-comments@w3.org 4.8.4 Order By and Return Clauses Intro "The dynamic semantics ... is not specified formally. The dynamic semantics is not specified formally ..." Again, repetitive. "Because an OrderByClause does not effect the type" s/effect/affect/ "in which the OrderByClause is omitted but a gt comparison is applied." If the OrderByClause clause really has no effect on the type, why do you need to add "but a gt comparison is applied"? And applied to what? Notation "... == [[ LetClause ... LetClause ]]" There shouldn't be big brackets around the RHS. It's a bit sneaky how you go back to the non-recursive FLWOR syntax for this []-form. "the following rule ... which specify that" s/specify/specifies/ "mapped to Expr" Change to "mapped to a sequence of LetClauses". Normalization "using the same static typing rules" Same as what? "Each OrderSpec is normalized the ..." s/the/by the/ "auxiliary atomization normalization rule." Delete "atomization"? This rule doesn't appear to be doing atomization. Norm / rule 2 [[ Expr OrderModifier, OrderSpecList ]]_OrderSpecList Italicize OrderModifier. Norm / rule 2 "for $fs:new1 in Expr" Append "return". Also, Expr should be normalized. Norm / rule 2 [[ $fs:new1 gt $fs:new2 ]]_Expr 'gt' always yields boolean, so it appears that $fs:new0 : xs:boolean? But since $fs:new0 won't appear anywhere else in the FLWORExpr, how does that make a difference to its static typing?
Received on Sunday, 17 July 2005 02:15:51 UTC