- 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