[Bug 1787] New: [FS] editorial: problems re VarRef, Variable

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1787

           Summary: [FS] editorial: problems re VarRef, Variable
           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


VarRef:
Other than in EBNF productions, all occurrences of 'VarRef' are incorrect.
The only way that VarRef shows up in the grammar (XQuery or Core) is as
an alternative for PrimaryExpr. Thus, [4.1.2 Variable References] is the
only section where rules could legitimately use the symbol 'VarRef'
(although they don't!). Everywhere else, 'VarRef' is being misused.

Generally, it's used as an abbreviation for "$VarName". But note that,
except in a PrimaryExpr context, "$VarName" is a variable binding or a
variable declaration, not a variable reference. So:

(1) In rules, when 'VarRef' occurs in the context of an XQuery or Core
    expression, it should be changed to "$VarName".

(2) In 'of var expands to' judgments, the left-hand "operand" is a QName,
    not a VarRef or even a $VarName, so judgments like:
        VarRef of var expands to ...
    should be changed to:
        VarName of var expands to ...
    (leftover from last year, comment #007)

(3) The domain of varType is expanded-QName, not VarRef or $VarName or
    VarName.  So judgments like:
        statEnv + varType(VarRef => ...)
    should be changed to:
        VarName of var expands to expanded-QName
        statEnv + varType(expanded-QName => ...)
    (Or else with 'Variable' instead of 'expanded-QName', see next.)
    (leftover from last year, comment #086)

Variable:
The symbol 'Variable' is not a non-terminal, so it's not immediately clear
what it signifies. In practice, it's used where an expanded-QName would be
expected. Things would be simpler if you changed all occurrences of the
symbol 'Variable' to 'expanded-QName' (taking care in the few rules where
there's already a pattern by that name).
(leftover from last year, comment #008)

But, if you feel that the 'Variable' symbol is preferable, then please
explicitly say that it's equivalent to 'expanded-QName', and use it
consistently. Specifically:

(1) Change 'expanded-QName' to 'Variable' in the following contexts:

    statEnv.varType(expanded-QName)
        2.1.5 / rule (2|4)
        4.1.2 / STA / rule 1

    dynEnv.varValue(expanded-QName)
        4.1.2 / DEv / rule (1|2)
        5.11 / DCP / rule 1

    VarName of var expands to expanded-QName
        2.1.5 / rule (2|4)
        3.1.1.1 / Notation
        4.1.2 / STA / rule 1
        4.1.2 / DEv / rule (1|2)

(2) Don't use the phrase "expanded Variables" because it makes Variables
    sound like QNames.

(3) In 5.15 / DCP / rule 2 / conclusion, change "Variable" to "$VarName".

Received on Wednesday, 20 July 2005 07:37:04 UTC