- From: <bugzilla@wiggum.w3.org>
- Date: Sat, 28 Oct 2006 06:46:41 +0000
- To: public-qt-comments@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=3875
Summary: [FS] editorial: 3.1.2 Dynamic Context
Product: XPath / XQuery / XSLT
Version: Candidate Recommendation
Platform: All
OS/Version: All
Status: NEW
Severity: minor
Priority: P2
Component: Formal Semantics
AssignedTo: simeon@us.ibm.com
ReportedBy: jmdyck@ibiblio.org
QAContact: public-qt-comments@w3.org
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.)
Received on Saturday, 28 October 2006 06:46:49 UTC