W3C home > Mailing lists > Public > www-forms@w3.org > April 2007

Re[2]: <repeat/> Element

From: Ivan Latysh <IvanLatysh@yahoo.ca>
Date: Tue, 17 Apr 2007 17:19:01 -0400
Message-ID: <1211685990.20070417171901@yahoo.ca>
To: John Boyer <boyerj@ca.ibm.com>
CC: www-forms@w3.org, www-forms-request@w3.org

Hello John,

Tuesday, April 17, 2007, 4:49:49 PM, you wrote:

> You're suggesting that the repeat nodeset should be able to cover any set of nodes without further restrictions.
> This is likely to happen for 1.1 because it is a last call comment and because there is good support in the group to
> do so.  In fact, this is what we mean when we say we will "get rid of homogeneous collection" so I don't understand
> why you think there is a difference.

> All of the nodes in a nodeset can indeed have a common parent node in the instance data.  XPath does not require that
> the nodes in the nodeset must be somehow owned by the nodeset and hence not still in the instance tree from which they
> were drawn, and I have never seen any technology that does this.  Indeed, XPath is internally driven by nodesets to
> drive each location step, so if nodes in a nodeset have no parents, then how could you process the ancestor axis on
> the next location step?
[xml] <color>blue<mix><color>red</color></mix></color> [/xml]
XPath "//color" will return the root node <color/> that has no ancestor and ancestor step will be processes according to
the XPath rules.

> Clearly, every node in the nodeset has a parent
It is not true, as I just demonstrate.

> , and the XForms 1.0 spec places the further restriction on repeats
> that the nodeset over which it operates must contain nodes that have the same parent.
This is what should be avoided at any cost, synthetic rules that make technology not compatible with each other.
XPath defines node-set quite well, so no need to for any custom rules here.

> To check this is a trivial
> matter of post-processing the nodeset returned by XPath and producing an xforms-binding-exception if any node of
> instance data has a parent different from the one that is the parent of the first node.  But most implementations did
> not add the extra check.
As you just proved, having this synthetic restriction already cause different implementation to be not compatible
between each other, because team A decided to follow the spec up to the letter, when the team B decide to keep
this door opened.

> Finally, by the same arguments, an XForms processor could indeed impose the restriction that the nodes in the nodeset
> must be contiguous elements.  The instance data is considered to be an XPath data model, and the nodeset identifies
> nodes in the instance data.  So, a simple post-processing step to XPath evaluation can determine, for each node, do
> the preceding and succeeding elements in the XPath data model appear in the nodeset or not? 
> For what it's worth, the sentence is missing a comma at the end of the parenthetic phrase "with the same local name
> and namespace name".  However, it does not appear to me that this minor grammatic error gives rise to the issues you raised.
I am sorry, I belive I wasn't been clear enough on my proposal, so let's do it again.

I propose to change the following:
This element defines a UI mapping over a homogeneous collection selected by Node Set Binding Attributes.
This node-set must consist of contiguous child element nodes, with the same local name and namespace name of a common parent node.
The behavior of element repeat with respect to non-homogeneous node-sets is undefined.

This element defines a UI mapping over a node-set selected by Node Set Binding Attributes.

Making <repeat/> element compatible with node-set returned by an XPath.

Best regards,
 Ivan                            mailto:IvanLatysh@yahoo.ca
Received on Tuesday, 17 April 2007 21:22:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:20 UTC