- 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