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 1787 - [FS] editorial: problems re VarRef, Variable
Summary: [FS] editorial: problems re VarRef, Variable
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-20 07:36 UTC by Michael Dyck
Modified: 2007-01-16 17:46 UTC (History)
0 users

See Also:


Attachments

Description Michael Dyck 2005-07-20 07:36:59 UTC
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".
Comment 1 Jerome Simeon 2006-04-10 14:59:02 UTC
Fixed as suggested.
- Jerome