Re: Re[2]: <repeat/> Element

Hi Ivan,

1) Please read the XPath data model again.  The document element (color in 
your example below) has a parent.  It's just not an element.

2) Synthetic rules are unavoidable.  Arbitrary generalization means 
nothing ever ships.  For example, one reason we 

3) The incompatibility between team A and B is supported by the spec. The 
spec says behavior over non-homogeneous collections is "undefined".  This 
means that team A and B can differ in this regard.

4) Yes you were clear in your proposal, and there is a reasonably good 
chance it will happen rather sooner than later.  I only disagreed with 
your rationale for the proposal, not the proposal itself.

But, out of curiosity, have you considered fully the implications of your 
proposal?  I mean, once you open repeat to arbitrary nodesets, then surely 
you will want to insert and delete elements that affect the nodeset over 
which that repeat operates.  So, what happens if you insert between two 
nodes that have different parents?  Does the new node become a following 
sibling of the first node or a preceding sibling of the second?

I think we know how to solve the above problem now, but it a good example 
of a host of problems that we have had to consider.  I believe it is the 
generalization of insert and delete to arbitrary nodesets that is allowing 
us to go back to repeat and make it operate over arbitrary nodesets too.

Cheers,
John M. Boyer, Ph.D.
STSM: Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





Ivan Latysh <IvanLatysh@yahoo.ca> 
04/17/2007 02:19 PM
Please respond to
Ivan Latysh <IvanLatysh@yahoo.ca>


To
John Boyer/CanWest/IBM@IBMCA
cc
www-forms@w3.org, www-forms-request@w3.org
Subject
Re[2]: <repeat/> Element






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:
[quote]
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.
[/quote]

to:
[quote]
This element defines a UI mapping over a node-set selected by Node Set 
Binding Attributes.
[quote]

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

-- 
Best regards,
 Ivan                            mailto:IvanLatysh@yahoo.ca