14996 2011-11-29 15:24:50 +0000 [FO30] function-lookup, function-arity, function-name 2011-12-06 22:07:32 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Functions and Operators 3.0 Member-only Editors Drafts PC Windows NT RESOLVED FIXED P2 normal --- 1 tim mike public-qt-comments oldest_to_newest 60622 0 tim 2011-11-29 15:24:50 +0000 In WG meeting #491 (2011-11-15), it was decided that: DECISION: To close bug #14330 with the following resolution: 1. function items can refer to context-independent built-in functions 2. function items can not refer to context-dependent built-in functions 3. you can create an inline function to wrap a context-dependent built-in function Will referencing a context-dependent built-in function raise err:XPST0112, or will a new error be created? 16.1.1 fn:function-lookup The first example fn:function-lookup(xs:QName('fn:contains'), 2)('aa', 'a') makes a call to function-lookup which would return a context-dependent built-in function. This funciton will now need to raise a dynamic error (i.e. an error other than XPST0112). Note that the function doesn't currently handle the case of focus-dependent functions. 16.1.2 fn:function-name The first example The expression fn:function-name(fn:contains#2) returns fn:QName("http://www.w3.org/2005/xpath-functions", "fn:contains"). references a context-dependent built-in function. 16.1.3 fn:function-arity The first example The expression fn:function-arity(fn:contains#2) returns 2. references a context-dependent built-in function. 60637 1 mike 2011-11-29 18:28:41 +0000 Yes, you are right, I failed to spot that our decision on context-dependent functions invalidated these examples. 60917 2 tim 2011-12-04 20:48:05 +0000 I'd like the following to be considered. Rather than it being an error to reference a context or focus dependent function, instead make it an error to invoke/apply such a function reference. This would avoid having to add an error condition for function-lookup. It would also mean that function-lookup, function-arity and function-name functions could operate on any function. There may well be other functions not yet defined (e.g. Is-function-context-sensitive) which could usefully operate on all function items, and the current ruling precludes them. 60927 3 mike 2011-12-05 09:13:28 +0000 I guess a natural development of this idea is to make context-sensitivity a kind of function annotation, and provide methods to interrogate the annotations of a function. 60928 4 tim 2011-12-05 09:26:45 +0000 It might also be useful to be able to mark an argument as being the context item in a user defined function, for example, to indicate that $implicit-context-item is an implicit argument of '.' in the following. declare function local:foo($implicit-context-item as item(), $arg2) { number($implicit-context-item) + $arg2 } //bar/local:foo(8) or alternatively, permit use of the context item in user defined functions e.g. declare function local:foo($arg2) { concat(string(), $arg2) } //bar/local:foo(" element") causing local:foo to be annotated as being context-dependent. 61056 5 mike 2011-12-06 22:07:32 +0000 The incorrect examples will be fixed. The WG resolved that function-lookup applied to a context-dependent function would succeed (returning the function), but that subsequent invocation of the function would fail with a dynamic error.