- From: Guntur Wiseno Putra <gsenopu@gmail.com>
- Date: Thu, 5 Mar 2020 13:20:30 +0700
- To: Erik Bruchez <ebruchez@orbeon.com>
- Cc: Steven Pemberton <steven.pemberton@cwi.nl>, XForms <public-xformsusers@w3.org>
- Message-ID: <CAKi_AEtoyXp9=Pdq+OX1g+ZrpEHBz5=nVGFjsYmC_7LfZCdeTQ@mail.gmail.com>
Dear Erik, Steven, &
public-xformsusers,
A CORRECTION (to the previous message):
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...?
And the "text" we are dealing with: May we refer them to
"cyberexperiences", "cyberworld", thus there are experiences on
"cyberform", "cyberspace" and "cyberorder" in relation with them...?
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,
>
>
> 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 06:20:46 UTC