- 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