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 1694 - [FS] editorial: 5 Modules and Prologs
Summary: [FS] editorial: 5 Modules and Prologs
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 22:36 UTC by Michael Dyck
Modified: 2007-09-29 20:53 UTC (History)
0 users

See Also:


Attachments

Description Michael Dyck 2005-07-17 22:36:31 UTC
5 Modules and Prologs

Core Grammar
[1 (Core)] Module ::= ...
[3 (Core)] MainModule ::= ...
[4 (Core)] LibraryModule ::= ...
[6 (Core)] Prolog ::= ...
[7 (Core)] Setter ::= ...
[8 (Core)] Import ::= ...
[29 (Core)] QueryBody ::= ...
    These productions are never used. Might as well delete them.

Notation

"In the Formal Semantics, it is simpler to assume the declarations can
appear in any order,"
    Yes, but then there's the question of how an XQuery Prolog is
    restructured into a Formal PrologDeclList.

[80 (Formal)] PrologDeclList ::= ...
    The inference rules assume a right-recursive syntax, e.g.:
       PrologDeclList ::= | PrologDecl Separator PrologDeclList
    or
       PrologDeclList ::= ( PrologDecl Separator PrologDeclList )?

Norm
    There's no text in the "Normalization" section. Delete header?
    Or is it meant to be a co-header with "Static Context Processing"?
    If so, it could be clearer.

SCP

SCP / rule 1 / conclusion
"statEnv |- () =>stat statEnv with ()"
DCP / rule 1 / conclusion
"dynEnv |- () =>dyn dynEnv"
    These use '()' to stand in for an empty PrologDeclList. This is not a
    good idea, since there's possible confusion with '()' denoting the
    empty sequence in the XQuery/Core syntax.

Notation 2

"under the static environment statEnv1"
"the static environment statEnv2"
    s/static/dynamic/
    s/statEnv/dynEnv/

"and the normalized sequence of prolog declarations in the Core grammar."
    Delete.

DCP

"The first rule specifies for an empty sequence"
    Insert "that" after "specifies"

"the initial dynamic environment is the default dynamic context."
    No, it doesn't say that. (Typically, when this rule holds, dynEnv will
    *not* be dynEnvDefault.)

DEv / rule 1 / premise 2
"dynEnv |- [[ QueryBody ]]_Expr Expr2"
    Insert "==" before "Expr2".

    And s/dynEnv/statEnv/

    But then (it becomes clearer that) you need to show where statEnv
    comes from. Presumably you need to repeat
      statEnvDefault |- PrologDeclList =>stat statEnv with PrologDeclList1
    from STA / rule 1.

SCP / rule 2 / premise 1
STA / rule 1 / premise 2
DEv / rule 1 / premise 2
    Change "==" to "=", see Bug 1548.
Comment 1 Jerome Simeon 2006-04-18 03:19:36 UTC
Fixed as suggested, including the removal of unused grammar productions from the XQuery core.
- Jerome
Comment 2 Michael Dyck 2006-10-04 08:45:52 UTC
I said:
>
> DEv / rule 1 / premise 2
>     Presumably you need to repeat
>       statEnvDefault |- PrologDeclList =>stat statEnv with PrologDeclList1
>     from STA / rule 1.
And you did, except you're missing the 'with PrologDeclList1' part.

Also, this hasn't been done:
> SCP / rule 2 / premise 1
> STA / rule 1 / premise 2
> DEv / rule 1 / premise 2
>     Change "==" to "=", see Bug 1548.
Comment 3 Michael Dyck 2006-10-04 22:25:45 UTC
Further to DEv / rule 1:
    In premise 2, remove the subscript '1' from statEnv1, so it unifies with the
    statEnv in premise 3.

    In premise 1, add a subscript '1' to PrologDeclList, so it unifies with the
    PrologDeclList1 that will be in premise 2 (because =>dyn operates on a
    normalized PrologDeclList).

    And it'll make more sense if you move premise 1 down a couple lines to
    become premise 3. 
Comment 4 Michael Dyck 2007-09-29 20:52:53 UTC
The unresolved portions of this issue (listed in Comment #2 and Comment #3) have been entered as FS erratum E007. A fix (incorporating all the given suggestions) has been committed to the source files for the next edition of the FS document.
Consequently, I'm marking this issue resolved-FIXED, and CLOSED.