Re: Feedback for "9.9.5.1 The copy Element (for itemset)"

>
>     <select>
>         <item>
>             <label>Chocolate</label>
>             <value ref="instance('chocolate')"/>
>         </item>
>         <item>
>             <label>Strawberry</label>
>             <value ref="instance('strawberry')"/>
>         </item>
>     </select>
>
> Did you mean to use <copy/> here?
>

Yes!

So your proposal is that wherever <value/> can be used, <copy/> can be used
> too?
>

Exactly.

For `select1`:
>
> - Deselecting an item should clear the content of the bound element (for
> attributes, if supported, see below).
> - Selecting an item inserts all the items returned by `xf:copy` into the
> bound element following `xf:insert`.
> - It's ok if `xf:copy` return an empty sequence (simply nothing gets
> inserted upon selection).
> - Attributes nodes could be supported or not, but if so the behavior
> should be described.
>
> I think this matches what is there for select1, although I'm not sure what
> you are proposing for attributes.
>

    <select ref="selection">
        <item>
            <label>foo</label>
            <copy ref="xf:attribute('foo', 'foovalue')"/>
        </item>
        <item>
            <label>bar</label>
            <copy ref="xf:attribute('bar', 'barvalue')"/>
        </item>
    </select>

This would, on the `selection` element, add or remove the given attributes.

For `select`:
>
> - I don't think it makes sense for `xf:copy` to support more than one
> item, so `xf:copy` follows the first-item rule.
>
> Hmm. I hadn't thought about this before, but what about
>
> <select ref="selection">
> <item label="red" copy="choices[colour='red']"/>
> <item label="green" copy="choices[colour='green']"/>
> <item label="blue" copy="choices[colour='blue']"/>
> </select>
>

Yes, this could work. I had assumed some kind of ordering would be
relevant, but if we just look at all nodes independently that's easier.

As discussed in the call, the only thing is to consider overlap: two items
returning identical, say, element subtrees. In this case, I suggest:

- If two items include the same subtrees and are selected, only one copy of
the tree is inserted.
- If one of the two items is deselected, the subtrees remains.
- When both items are deselected the subtrees is removed.


> - An item for which `xf:copy` returns the empty sequence must be ignored.
>
> I believe this is already so described.
>
> - Deselection requires deep comparing the result of `xf:copy` with the
> bound element's children nodes. Any tree found is deleted following
> `xf:delete`.
>
> "For complex selections, the individual subtrees associated with the newly
> selected and deselected items are added or removed individually by using
> insert and delete;" However, it only used the word "matches" rather than
> "deep compare".
>

That's probably fine. Our code uses the Saxon `deep-equal()` logic to do
compare subtrees:


https://www.saxonica.com/html/documentation/functions/saxon/deep-equal.html

    - What happens if `xf:copy` returns an atomic value?
>
> What does <insert/> do in this case?
>

"a text node is created for each atomic value."

(This should probably say more, since text nodes are merged in the data
model.)

As discussed during the call, this part is ok. But say you have:

    <item>
        <label>Foo</label>
        <copy ref="'foo'"/>
    </item>
    <item>
        <label>Bar</label>
        <copy ref="'bar'"/>
    </item>

If you select both, then you would get, in the resulting node:

    <selection>foobar</selection>

or maybe:

    <selection>barfoo</selection>

So you wouldn't be able to distinguish those anymore, except with a
possibly complicated and unreliable algorithm. So I think that text nodes
and atomic values should not be allowed with the `<select>` / `<copy>`
combo.

>
> - Selection requires inserting the items following `xf:insert`.
> - Attributes nodes could be supported or not, but if so the behavior
> should be described.
>
> What would you propose as being the behaviour?
>

See above.


> 3. Mix and match of `xf:copy` and `xf:value`
>
> A selection control can have multiple `xf:itemset` and `xf:item`.
>
> As children of <choices/> you mean?
>
> <select ref="x">
>   <choices label="a">
>      <item label="a1" value="1"/>
>   </choices>
>   <choices label="b">
>      <itemset .../>
>   </choices>
> </select>
>

My understanding was that you can have any of those, but maybe I am
mistaken:

    <select ref="x">
        <itemset>
            ...
        </itemset>
        <item>
            ...
        </item>
        <itemset>
            ...
        </itemset>
        <item>
            ...
        </item>
        <choices>
            ...
        </choices>
    </select>


> What happens if there is a mix and match of `xf:copy` and `xf:value`? We
> could say that this is implementation-dependent or that this follows the
> `xf:copy` logic, with an `xf:value` values behaving like an `xf:copy` that
> returns an XPath string value.
>
> Are there use cases?
>

I am not sure, but I think, as discussed in the call, that it makes sense
to disallow the use of both `<value>` and `<copy>` within a given selection
control, in the same way that we should disallow text nodes/atomic values
returned by `<copy>`.

-Erik