Proposal to support optional parameters that bind to the context item.

[rhdunn]

This proposal formalizes the definition of the 0-arity versions of fn:string, fn:data, etc. that bind to the context item.

Motivation

This allows fn:string to be defined and implemented in a single function of the form:

declare function fn:string($item as item()? := .) as xs:string { ... }

Notes

When the default value is specified, the function is ·context-independent·, and ·focus-independent· at this point.

When the default value is not specified, the function is ·context-dependent·, and ·focus-dependent· at this point.

This allows users to define their own functions that can be used at the end of path expressions, e.g. /color/hexcode/to-int(16).

Once this proposal has been accepted, we should go through the XSLT and XQFO specifications and use defaults for all the relevant functions.

[rhdunn]

Depends on #155.

[michaelhkay]

This reads more like a requirement than a specification. What exactly is allowed and what isn't? A lot more detail is needed. The default for normalize-space() and string-length(), for example, is not .butstring(.) (string-length(32)is an error, but32!string-length()is not -- a legacy of XPath 1.0). Are there any restrictions on the expression that can be used as the default value of a parameter (for example, can it reference a global variable or a user-defined function? Can it call doc()? If the default value is given as an element constructor

, do all invocations of the function supply the same

element, or does each invocation supply a different

` element? (Note, XSLT named templates can define default values in this way, and these edge-case issues only came to light after many years. For XSLT, of course, we would want the rules for functions to be as close as possible to the rules for named templates.)

[rhdunn]

I wanted to capture this separately as IIUC, supporting . (and string(.)) is a harder problem than just getting the basic optional parameters correct. As such, I'm saying that for #155 we should ignore this problem (so you can't support these context capturing functions in that proposal).

This is part of simplifying the problem domain so that when it comes to standardizing this we have an easier task of reviewing and accepting the proposals. This is not yet a full specification -- I just wanted to capture the problem domain/requirement initially as a starting point for the discussions and outlines for a complete specification with all the details and nuances.

[michaelhkay]

The pull request for issue #155 provides this feature.

[michaelhkay]

I believe this can now be closed as completed.