1798 Function fn:function-identity

[dnovatchev]

The function fn:identity as already described and discussed in #1798

[michaelhkay]

"can be assigned permanent identities in the official documentation, requiring every implementation to use exactly the published identity value for the official, system functions, thus achieving efficiency, uniformity, and a degree of interoperability. - this is the official documentation, so it's inappropriate to include such a statement here. (I suggest saying that for these functions the result of function-identity is the URI-qualified name followed by '#' and the arity.)

[dnovatchev]

"can be assigned permanent identities in the official documentation, requiring every implementation to use exactly the published identity value for the official, system functions, thus achieving efficiency, uniformity, and a degree of interoperability. - this is the official documentation, so it's inappropriate to include such a statement here. (I suggest saying that for these functions the result of function-identity is the URI-qualified name followed by '#' and the arity.)

I am deleting this text now.

Defining the exact values for the function identity of the system functions is probably better done separately, and could be discussed.

[michaelhkay]

The Data Model spec, where it introduces function identity, needs to be updated (because it currently implies that function identity cannot be exposed in this kind of way).

The Data Model spec also states that "Function identity is not currently defined for maps and arrays", which leaves an open question as to what the proposed fn:function-identity() returns if supplied with a map or array.

[dnovatchev]

The Data Model spec, where it introduces function identity, needs to be updated (because it currently implies that function identity cannot be exposed in this kind of way).

Yes, it only says that the function identity is "abstract"

It probably would be best to update the DM in a separate PR.

The Data Model spec also states that "Function identity is not currently defined for maps and arrays", which leaves an open question as to what the proposed fn:function-identity() returns if supplied with a map or array.

This negative statement simply needs to be removed from the documentation. If the generated identity value is "abstract", then it can be generated the same "abstract" way as done for (non-array and non-map) functions.

We probably should not prescribe what values are generated for non-system functions, we only need a bijective projection of whatever they use internally, into xs:string.

Of course, if I am an implementor, I will probably use GUIDs, but some other implementors may prefer to use something entirely different.

[michaelhkay]

The material question for maps and arrays is whether there are any circumstances in which two expressions that return maps or arrays are guaranteed to return the same map or array. For example, we might want to specify that all evaluations of {} return identical maps; we might also want to extend this to other expressions that return empty maps.

Another significant question is whether function identity is affected by the presence of labels. This applies particularly strongly to maps and arrays: does pin($map) have the same identity as $map? (Note that we have explicitly said that labels have no effect on node identity).

[dnovatchev]

The material question for maps and arrays is whether there are any circumstances in which two expressions that return maps or arrays are guaranteed to return the same map or array. For example, we might want to specify that all evaluations of {} return identical maps; we might also want to extend this to other expressions that return empty maps.

It would be good to avoid proving function identity. In some simple/regular cases this can be done, but not in every case.

The ways identity is generated (by the implementation) is orthogonal to this issue - which is the specification of just the function that returns this identity-value to the caller.

This said, and talking beyond the subject of this PR, one obvious way of assigning identity to maps and arrays is producing the hash of their normalized serialization. But again, why not leave this to the specific implementations?

Another significant question is whether function identity is affected by the presence of labels. This applies particularly strongly to maps and arrays: does pin($map) have the same identity as $map? (Note that we have explicitly said that labels have no effect on node identity).

Again, beyond of the coverage of this PR:
I am ignorant of labels/pinned-maps.
I am aware of some cases of functions that are produced from other functions, such as the partial application of a given function. In such cases, using the identity of the original function and concatenating it with an identity of the particular operation upon this function (such as partial application by fixing arg#N with particular value), will be a guarantee that if the same operation is performed on the same function, then the result(_2) of this operation will be given the same identity as the result(_1) of performing this same operation for the first time. Thus regardless of how many different partial applications (fixing the same argument with the same code) we have in our code, they all will be given the same identity.

[michaelhkay]

Fix #1798

[dnovatchev]

Fix #1798

And isn't this cryptic?

Sorry, what does this mean?

MHK> It's a magic incantation understood by GitHub to mean that when this PR is merged, issue 1798 can be automatically closed.

[ndw]

At meeting 112, the CG agreed to merge this PR.