Function properties and arities (editorial)

[ChristianGruen]

I try to understand the semantics behind the Properties section in the XQFO spec. Here are some examples of existing functions:

1. fn:format-integer

The two-argument form of this function is ·deterministic·, ·context-dependent·, and ·focus-independent·. It depends on default language.
The three-argument form of this function is ·deterministic·, ·context-independent·, and ·focus-independent·.

2. fn:format-time

This function is ·deterministic·, ·context-dependent·, and ·focus-independent·. It depends on default calendar, and default language, and default place, and implicit timezone.

3. fn:index-of

The two-argument form of this function is ·deterministic·, ·context-dependent·, and ·focus-independent·. It depends on collations, and implicit timezone.
The three-argument form of this function is ·deterministic·, ·context-dependent·, and ·focus-independent·. It depends on collations, and static base URI, and implicit timezone.

4. fn:element-number

The zero-argument form of this function is ·deterministic·, ·context-dependent·, and ·focus-dependent·.
The one-argument form of this function is ·deterministic·, ·context-independent·, and ·focus-independent·.
The two-argument form of this function is ·deterministic·, ·context-independent·, and ·focus-independent·.
The three-argument form of this function is ·deterministic·, ·context-independent·, and ·focus-independent·.

I am afraid I cannot give hints for improvement yet; I just noticed it is increasingly difficult to interpret. For the moment, I wonder…

1. Are all of these current definitions correct?
2. In many cases, if the user supplies an empty sequence as argument, the default value is used instead. This contrasts with the current property description that relies a lot on the function arities. For example, fn:index($a, $b) and fn:index-of($a, $b, ()) should have identical properties, but the current wording implies that the three-argument of this function has different properties, e.g., it is said to rely in this case on the static base URI.
3. Some functions with default values have a single property description (see fn:format-integer), other have multiple descriptions (see fn:format-time). Is there a particular rule behind that?
4. Could we merge the descriptions for arities with identical properties?
5. Maybe it will be easier not to consider the arities at all anymore?

[ndw]

I was looking at those sections recently as well. I think it would be nice if we had explicit markup for the properties, so that I could easily and reliably build a table of all the functions and their properites, for example. But I became discouraged by the variety (the two argument form..., the three argument form...) and the comments about dependencies (calendar, time zone, etc.)

[michaelhkay]

The text is generated from structured markup so the presentation could easily be changed.

[michaelhkay]

An observation is that there is no function that is deterministic for some arities and nondeterministic for others, so we could perhaps factor that out.

We could also (at merge-function-specs line 128) look for cases where several different arities have the same property values, and factor that out: "With two or more arguments, the function is context-independent and focus-independent". Or rather than doing it in the stylesheet, we could extend fos:property/@arity to allow values like "2-5" or "2+".

We could also combine the "focus-dependent" and "context-dependent" properties, replacing <fos:property>focus-dependent</fos:property> with <fos:property dependency="focus">context-dependent</fos:property>.

In many cases, if the user supplies an empty sequence as argument, the default value is used instead

This highlights that it is becoming misleading to speak of "the one-argument form of this function". It might be better to say (taking format-integer as an example): "If $language is absent or empty, the function is context-dependent (it depends on default language). In other cases the function is context-independent". This represents a change of the implied data model, so that the context-dependency of a function depends not so much on the arity, as on the presence or absence of specific parameters.