3183 2006-05-03 18:41:21 +0000 [FS] editorial: 4.1.5 Function Calls: []_FunctionArgument 2007-11-04 06:00:04 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Formal Semantics 1.0 Candidate Recommendation All All ASSIGNED P2 minor --- 1 jmdyck jmdyck public-qt-comments oldest_to_newest 9576 0 jmdyck 2006-05-03 18:41:21 +0000 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 14194 1 jim.melton 2007-02-26 00:11:11 +0000 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).