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 3875 - [FS] editorial: 3.1.2 Dynamic Context
Summary: [FS] editorial: 3.1.2 Dynamic Context
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Formal Semantics 1.0 (show other bugs)
Version: Candidate Recommendation
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: consider for 1.1
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-28 06:46 UTC by Michael Dyck
Modified: 2007-09-21 00:51 UTC (History)
0 users

See Also:


Attachments

Description Michael Dyck 2006-10-28 06:46:40 UTC
3.1.2 Dynamic Context

"some component of the dynamic context"
    s/context/environment/ ?

dynEnv.funcDefn
"The dynEnv.funcDefn environment component maps an expanded function name
and parameter signature of the form "expanded-QName (Type1, ..., Typen)"
to the remainder of the corresponding function definition."
    The domain of dynEnv.funcDefn should be the same as that of
    statEnv.funcType, i.e. (expanded-QName,arity).  By including the
    parameter types in the domain, rather than simply the arity, you allow
    for functions with the same name and arity but different parameter
    types, which there is no need to do.

    This change would only affect a few premises in 4.1.5, 5.11, and 5.15.
    It would especially simplify 5.11 / Notation 3 / rule 4, which is
    currently broken (see Bug 1715).

'If the function is locally declared, the function definition is of the
form "(Expr, Variable1,..., Variablen)", ...'
    I think it would make more sense if the Variables came before the Expr.
    (You have to bind the parameters before you can evaluate the body.)
Comment 1 Jim Melton 2007-02-26 00:18:58 UTC
The fix for this bug does not appear in the Recommendation of 23 January 2007. 
It will be considered for a future publication (either an Errata document or
some possible future version of the specification). 
Comment 2 Michael Dyck 2007-09-21 00:51:05 UTC
(In reply to comment #0)
> 3.1.2 Dynamic Context
> 
> "some component of the dynamic context"
>     s/context/environment/ ?

The FS appears to use "context" and "environment" more or less interchangeably. So, while the suggestion might be an improvement, it's not worth an erratum. I'll consider it for FS 1.1.

> dynEnv.funcDefn
> "The dynEnv.funcDefn environment component maps an expanded function name
> and parameter signature of the form "expanded-QName (Type1, ..., Typen)"
> to the remainder of the corresponding function definition."
>     The domain of dynEnv.funcDefn should be the same as that of
>     statEnv.funcType, i.e. (expanded-QName,arity).

This proposal has been incorporated into the fix for FS erratum E006. The fix has been committed to the source files for the next edition of the FS document.

> 'If the function is locally declared, the function definition is of the
> form "(Expr, Variable1,..., Variablen)", ...'
>     I think it would make more sense if the Variables came before the Expr.
>     (You have to bind the parameters before you can evaluate the body.)

Again, this might be an improvement, but it's not worth an erratum. I'll consider it for FS 1.1.

Based on the outcome of the second item above, I'm marking this bug resolved-FIXED (with a "consider for 1.1" note in the Status Whiteboard), and then closing it.