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

Hi Ivan,

Erik already addressed the distinction between root node and document 
node, so I won't dwell on that.  But your feedback is good, so I don't 
want you bolting from participation because you believe I may have 
disagreed with your want of technology interoperability.

I do agree that we want as much interoperability as possible.  But 
standardization is a human process, not a machine process, so it includes 
compromises and areas left undefined to allow major use cases to take 
priority over regular and minor use cases.  For example, it was more 
important to have repeat, insert and delete operate over homogeneous 
collections than it was to have them operate over arbitrary nodesets, and 
leaping from one to the other is not without difficulty.  If we had 
decided to make that leap in XForms 1.0, it would have shipped years later 
than it did, which would have been a disaster.

A couple of years ago, Sebastian provided a great saying that is quite 
applicable here: "Perfection is the devil of excellence."

Of course, over time the bar of excellence has to rise, and indeed XForms 
1.1 makes the leap to arbitrary nodesets for insert/delete, and last call 
feedback has already requested the same for repeat.  The "rationale" of 
yours that I disagreed with was not technology interoperability, but the 
statement that the definition of homogeneous collection contradicts itself 
and/or is somehow in violation of other W3C specs.  The contradiction has 
been resolved now based on the parent issue, and the XPath spec does not 
specify how its results will get used, so the additional constraints of 
homogeneous collections can indeed be legally added as post-processing 
steps after the XPath evaluation occurs.  And, for 
excellence-versus-perfection reasons, it was necessary at the time.

If you would like to hear about the group's decision on whether to allow 
repeat to operate over arbitrary nodesets and not just homogeneous 
collections, then please send a last call comment to 
www-forms-editor@w3.org saying something along the lines of "Insert and 
delete actions now operate over arbitrary nodesets.  For language 
consistency, repeat should do the same.  The limitation to homogeneous 
collections was made to simplify insert and delete, not repeats".

While you're in the neighborhood, could you also send a last call comment 
about that evaluation context issue please?

Thanks,
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> 
Sent by: www-forms-request@w3.org
04/17/2007 05:41 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[4]: <repeat/> Element







Hello John,

Tuesday, April 17, 2007, 5:51:00 PM, you wrote:

>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.
"Every node other than the root node has exactly one parent" ...

> 2) Synthetic rules are unavoidable.  Arbitrary generalization means 
nothing ever ships.  For example, one reason we
I do not propose "Arbitrary generalization" I propose technology 
interoperability.
In other words I propose to make the toaster to work with 110V grid 
instead making it to work with 139V just because
it happen to toast a piece of bread in perfect bronze in exactly 3 
minutes.

> 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.
Please correct me if I am wrong, but it is defeat the point of having the 
spec.
The purpose of the spec is to make sure that the same Form will work for 
team A and team B.
I do perfectly understand that it is not humanly possible to foresee all 
possible use-cases and some part of the spec
stay "undefined" until the time to define them.
So I belive that it is the time to define this particular part of the 
spec.

> 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.
I am surprised that you would disagree with "technology interoperability 
and compatibility" reason ...

> 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?
Yes I did.
We are dealing with dynamic XML data model, in case it has been changed - 
fire an event.
But the issue will arise when <repeat/> element change it's own node-set, 
in this case the decision should be made when
to fire an event and how to deal with infinite cycles.

> 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. 
I would love to know about the solution.

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