Question related to action item "Nick to propose note to for http://www.w3.org/TR/xforms11/#expr-dependencies to explain rationale for bind causing dependencies on node-test and predicate conditions."

The reasoning from Leigh sounded good "Isn't is to allow the bind to match 
a different node if the predicate condition changes, such as if you 
setvalue @id in one of these examples?"[1] but this reasoning breaks (at 
least I think that it breaks when you have another NameTest sstep 
following the first NameStep with filter.

Let me explain in more detail:


If you have the instance:

<xforms:instance>
   <data xmlns="">
      <a attr="X">
         <b attr="Y">
            <c/>
         </b>
         <d>
      </a> 
      <a attr="Z">
         <b attr="Y1">
            <c />
         </b>
         <d/>
      </a> 
   </data>
</xforms:instance>


and an XPath eexpression  :

a[@attr='X']/b[@attr='Y1']/c

If you execute [2] you will see that the following nodes are referenced:
 - both 'a' nodes
 - the first 'b' node (with attribute attr equal to 'y')

If a setvalue now changes the attr attribute of the second 'a' element to 
'X' a naive form author would think our dependency would pickup that there 
is now a node that matches the xpath expression but it doesn't. We still 
need to do a rebuild to let the dependency engine see the new dependant 
nodes. Which is not a real problem because [2] explains that this is a 
dynamically dependency. But now I'm lost again  why the rule of only using 
the NameStep is in the spec... The minutes of the Madrid FtF don't 
enlighten me either[3] 

Any help is welcome, again....

Regards,

Nick Van den Bleeken  -  Research & Development Manager
Inventive Designers
Phone: +32 - 3 - 8210170
Fax: +32 - 3 - 8210171
Email: Nick_Van_den_Bleeken@inventivegroup.com

1: 
http://lists.w3.org/Archives/Public/public-forms/2008Apr/att-0099/2008-04-23.html
2: http://www.w3.org/TR/xforms11/#expr-dependencies
3: http://www.w3.org/2007/09/14-forms-minutes.html (search for Things 
wrong with 7.5)

--------------------------------------------------

Inventive Designers' Email Disclaimer:

http://www.inventivedesigners.com/email-disclaimer