- From: Guntur Wiseno Putra <gsenopu@gmail.com>
- Date: Thu, 5 Mar 2020 12:05:26 +0700
- To: Erik Bruchez <ebruchez@orbeon.com>
- Cc: Steven Pemberton <steven.pemberton@cwi.nl>, XForms <public-xformsusers@w3.org>
- Message-ID: <CAKi_AEshOZY3yTz2suLqz6_Y+8XktFFvNyggd8QbkJEFmpEGmg@mail.gmail.com>
Dear Erik, Steven, &
public-xformsusers,
EB:
"a text node is created for each atomic value."
(This should probably say more, since text nodes are merged in the data
model.)
... So I think that text nodes and atomic values should not be allowed
with the `<select>` / `<copy>` combo.
... 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>`.
GWP:
By such a logic of :
- Text Nodes,
- Text Networks
- Networks Architecture
- Text Networks Architecture
Are we not dealing with a matter on "Text" and "Architecture"...?
Regard,
Guntur Wiseno Putra
Pada Kamis, 05 Maret 2020, Erik Bruchez <ebruchez@orbeon.com> menulis:
> <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
>
Received on Thursday, 5 March 2020 05:05:41 UTC