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

Received on Wednesday, 18 April 2007 00:47:51 UTC