Yes, the change to make these functions work on sequences of nodes was clearly only implemented partially.

John Lumley also points out that we ought to be clear in the case where the same node is present more than once in the input sequence whether the output sequence will also contain the same node more than once, or whether each gets a different copy, or whether this is implementation-dependent. In keeping with the use of new-each-time="maybe", I think it should be implementation-dependent. 

More complex scenarios are also possible, where the input sequence to copy() or snapshot() contains a node N and also one or more of its ancestor or descendant nodes. We could either allow the result to contain overlapping copies in this case, or we could insist that in the result of copy-of, each node is parentless and siblingless, and in the result of snapshot, each node is siblingless (which would imply multiple copies).

(In reply to Michael Kay from comment #1)

> More complex scenarios are also possible, where the input sequence to copy()
> or snapshot() contains a node N and also one or more of its ancestor or
> descendant nodes. We could either allow the result to contain overlapping
> copies in this case, or we could insist that in the result of copy-of, each
> node is parentless and siblingless, and in the result of snapshot, each node
> is siblingless (which would imply multiple copies).

You mean as in:

copy-of(.. | .)

to return only the parent, as it already includes the current node? I think as presently written, it returns a deep copy of the parent and a deep copy of the current node, both being parentless. I think snapshot() should work the same way.

Which is in line with applying templates with on-no-match="deep-copy".


(In reply to Michael Kay from comment #1)
> John Lumley also points out that we ought to be clear in the case where the
> same node is present more than once in the input sequence whether the output
> sequence will also contain the same node more than once, or whether each
> gets a different copy, or whether this is implementation-dependent. In
> keeping with the use of new-each-time="maybe", I think it should be
> implementation-dependent. 

I agree, it should be implementation-dependent.

Does it make sense (and isn't it too big a change) to allow any sequence as input to copy-of() and snapshot(), where in the case of atomic values, it is simply a no-op? Apart from the signature, I don't think the rules have to change.

I think it makes things simpler, i.e. it would help with generic scenarios where input can be anything, and users won't have to write the following, which seems silly:

> if($input instance of node()) then copy-of($input) else $input

It also helps with making streaming xsl:merge behave more stable and less surprising in the event the xsl:merge-source/@select selects non-nodes or a mix of nodes and atomic values (see bug 29142)

In response to comment #2, I think the question is, what can we say about the following expressions:

(a) count($X) eq count(copy-of($X))

(b) every $x in copy-of($X) satisfies empty($x/..)

(c) let $R := copy-of(.., .) return $R[1] is $R[2]/..

I think (a) should always be true (for any input $X)

On balance I think (b) should always be true (i.e. all nodes in the result are parentless)

That would mean that (c) is false: although you've already copied "." in the course of copying "..", you have to copy it again when processing the second item in the input sequence, because the first copy wasn't parentless.

In response to comment #3, although one could specify copy-of and snapshot to be no-ops when applied to atomic values or functions, I don't think it's useful enough to justify a spec change at this stage.

In discussion we were inclined to propose:

* copy-of follows the same rules as xsl:copy-of

** therefore it accepts items of any kind

** copy-of($seq) delivers the same result as $seq!copy-of(.), that is, each item is copied independently; if the same node appears twice you get two different copies; all nodes in the result are parentless

** snapshot, similarly, accepts items of any kind

The changes were approved and have been applied.

Some minor improvements to the stylesheet were suggested in email and have been incorporated.