This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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?
All fixed as suggested except the last comment. About the last comment, it does make a difference if static typing for the 'gt' expression fails, you get a static type error in that case. - Jerome
I think that could be made plainer in the text then. "An OrderByClause is normalized ..., which guarantees that the OrderSpecList is well typed." Actually, an OrderSpecList doesn't have a type, so saying that it's well typed is odd. Moreover, successful normalization alone doesn't guarantee that the OrderSpecList doesn't cause any type errors; you need successful STA too. "but this normalization does provide the correct static type." Normalization does not provide a type, it yields an expression for which STA will provide a type. Anyway, the point is not to get the correct type (since that's independent of the OrderByClause), it's to prevent the inference engine from succeeding when it shouldn't.
Yep. I agree. Fixed the corresponding paragraphs to better explain the role of normalization in the case of order by clauses. - Jerome
This one wasn't done properly: > > Norm / rule 2 > "for $fs:new1 in Expr" > Append "return". > > Also, Expr should be normalized. When normalizing Expr, you need the 'Expr' subscript on the big brackets. You also need to insert a "return" after it. And I still think the general point could be clearer. How about changing: Because an OrderByClause does not affect the type of a FLWORExpr expression, the static semantics of a FLWORExpr expression with an OrderByClause ... to: Although an OrderByClause does not affect the type of a FLWORExpr, it must still undergo static analysis, in case this raises a static error. The static semantics of a FLWORExpr with an OrderByClause .... (Note that this also handles the redundant "FLWORExpr expression".)
Both remaining issues fixed as suggested. - Jerome