- From: <bugzilla@wiggum.w3.org>
- Date: Wed, 03 May 2006 18:41:21 +0000
- To: public-qt-comments@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=3183
Summary: [FS] editorial: 4.1.5 Function Calls:
[]_FunctionArgument
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
4.1.5 Function Calls
Notation
[]_FunctionArgument
First, picking up on Bug 1576 comment #2, note that the conditional
structures of []_AtomizeAtomic and []_Convert are now identical,
so the two can be merged (into []_ConvertAtomic, say):
[ Expr ]_ConvertAtomic(SequenceType) denotes
fs:convert-simple-operand(fn:data(Expr),PrototypicalValue)
If [SequenceType]_sequencetype <: xdt:anyAtomicType*
Expr
Otherwise
Second, note that, as seen at the end of Bug 1680 comment #4,
[]_FunctionArgument() is actually invoked with a Type, not a
SequenceType (because when you look up the function name/arity in
statEnv.funcType, you get a signature with Types, not SequenceTypes).
This modifies the above definition to:
[ Expr ]_ConvertAtomic(Type) denotes
fs:convert-simple-operand(fn:data(Expr),PrototypicalValue)
If Type <: xdt:anyAtomicType*
Expr
Otherwise
Finally, I suggest that rather than using this ad hoc If/Otherwise
notation, the whole []_FunctionArgument() mapping would be better
expressed as two inference rules:
statEnv |- Type <: xdt:anyAtomicType*
-------------------------------------
statEnv |- [ Expr ]_FunctionArgument(Type) =
fs:convert-simple-operand(fn:data( [Expr]_Expr ),ProtoValue)
statEnv |- not( Type <: xdt:anyAtomicType* )
--------------------------------------------
statEnv |- [ Expr ]_FunctionArgument(Type) = [Expr]_Expr
Received on Wednesday, 3 May 2006 18:42:47 UTC