- From: Erik Bruchez <ebruchez@orbeon.com>
- Date: Wed, 28 Feb 2007 13:04:41 +0100
- To: www-forms@w3.org
Joern & all, > Well, yes i understand that XPath taken for itself will select 6 Nodes > here. I also understand that the homogeneous collection restriction > solves this problem. > > But if there's intend to remove this restriction there's obviously some > further work needed. > > Just consider the case that the author want to insert an item at > position 4 in the nodeset. Will it be a child of level[1] or of > level[2]? The answer is that it depends on how you configure your xforms:insert action! In XForms 1.1, while the homogeneous collection concept has not been removed from the xforms:repeat text, it has been removed from xforms:insert and xforms:delete, with one exception: the point regarding the update of the repeat index. And I would be really fine if we got rid of the mention of "homogeneous collection" there as well for XForms 1.1. So in the current XForms 1.1 text, xforms:insert and xforms:delete are just general-purpose actions to add and delete nodes to and from an XML document. The behavior of these actions does not imply any knowledge of the existence of xforms:repeat elements, except again when it comes to updating of repeat indexes. But this part does not change the way xforms:insert and xforms:delete work and you can just see this as a sort of notification to xforms:repeat. In the future, we would like to remove any mention of xforms:repeat in the spec for xforms:insert and xforms:delete, and define repeat index updates simply in terms of the xforms-insert and xforms-delete events with their associated context information. In fact it may already be possible in XForms 1.1 to implement repeat index updates based on this event context information. It is my very strong opinion that there is absolutely no need for the constraint of homogeneous collection in XForms. We have never enforced it in Orbeon Forms, and other implementors don't enforce it either, which is proof that it is technically unnecessary. I supposed the initial idea was that this constraint would make implementations simpler, but that is not the case at all in my opinion, which makes this restriction doubly unnecessary. You raise a good point that depending on your xforms:insert/@nodeset expression, you may, as a form author, have difficulty performing insertions of nodes where it makes sense, but then that's up to you, the form author, to figure it all out and configure xforms:insert and xforms:delete appropriately ;-) -Erik -- Orbeon Forms - Web Forms for the Enterprise Done the Right Way http://www.orbeon.com/
Received on Wednesday, 28 February 2007 12:04:52 UTC