- From: Guntur Wiseno Putra <gsenopu@gmail.com>
- Date: Thu, 5 Mar 2020 12:40:01 +0700
- To: Erik Bruchez <ebruchez@orbeon.com>
- Cc: Steven Pemberton <steven.pemberton@cwi.nl>, XForms <public-xformsusers@w3.org>
- Message-ID: <CAKi_AEtuBa-T4qEWq=7YhmaA+wz_n9it=5BWoUbt7DkCq4G+Ug@mail.gmail.com>
Dear Erik, Steven, &
public-xformsusers,
To the matter of "Text" & "Architecture" I said earlier:
If "Architecture" is about "form", "space" and "order" (1), thus
"Network" refers to "form" --if by the latter we mean "general arrangement
or structure; way in which parts are put together to make a whole or a
group; style or manner of presentation (2).
What are about "space" and "order" then...?
May we refer them to "cyberexperiences", "cyberworld", thus there are
experiences on "cyberspace" and "cyberorder"...?
Note:
(1) F.D.K. Ching, "Architecture: Forms, Space & Order", John Wiley & Sons,
New Jersey & Canada, 2007
(2) Oxford English Dictionary
Regard,
Guntur Wiseno Putra
Pada Kamis, 05 Maret 2020, Guntur Wiseno Putra <gsenopu@gmail.com> menulis:
> 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/saxo
>> n/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:40:16 UTC