This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 1672 - [FS] editorial: 4.8.4 Order By and Return Clauses
Summary: [FS] editorial: 4.8.4 Order By and Return Clauses
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Formal Semantics 1.0 (show other bugs)
Version: Last Call drafts
Hardware: All All
: P2 minor
Target Milestone: ---
Assignee: Jerome Simeon
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-07-17 02:13 UTC by Michael Dyck
Modified: 2007-02-25 23:16 UTC (History)
0 users

See Also:


Attachments

Description Michael Dyck 2005-07-17 02:13:38 UTC
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?
Comment 1 Jerome Simeon 2006-04-11 22:45:04 UTC
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
Comment 2 Michael Dyck 2006-04-12 04:19:31 UTC
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.
Comment 3 Jerome Simeon 2006-04-21 14:47:57 UTC
Yep. I agree.
Fixed the corresponding paragraphs to better explain the role of
normalization in the case of order by clauses.
- Jerome
Comment 4 Michael Dyck 2006-10-04 00:59:02 UTC
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".)
Comment 5 Jerome Simeon 2007-01-16 18:03:23 UTC
Both remaining issues fixed as suggested.
- Jerome