Re: Suggestions for the Master Dependency Graph

We have built a non-XForms complex graph dependency based observer based 
evaluation engine. We have in place a cycle detection mechanism and the 
user can attach a 'listener' to its detection. At this point the 
'listener' may indicate by false to discontinue the cycle, or true to 
continue the cycle.




"David Landwehr" <david.landwehr@solidapp.com> 
Sent by: www-forms-request@w3.org
03/22/2006 01:20 AM

To
"David Landwehr" <david.landwehr@solidapp.com>
cc
"Allan Beaufour" <beaufour@gmail.com>, www-forms@w3.org
Subject
Re: Suggestions for the Master Dependency Graph








>> 3) Today the following type of binds:
>> <xforms:bind nodeset="/a/b/c" calculate="../d[number(/a/@pos)]"/>
>> are static between rebuilds since the predicate expression /a/@pos is
>> considered to create dynamic dependencies. I would like to suggest that
>> this type of expression is not static between rebuild but updated in 
the
>> xforms-recalculate processing. This would mean a change to @pos will
>> update <c>'s value but also change the dependencies for the /a/b/c
>> expression to exclude the previous <d> and include the new <d>. This
>> will put a harder restriction on the implementor, but will enabled
>> flexible forms. To implement such a behavior the implementation might
>> have to performed the topological sorting for every recalculation 
(since
>> it is a O(n) algorithm I believe it would be feasible).
>> 
>
> Hmmm. I'm not sure I want more complexity in the MDG. A use case would 
be nice.
>
> 
The complexity for the algorithms can be just the same as it is today. 
Simply the implementor would have to rerun rebuild in the recalculation 
step and everything would be the same. With a small amount of extra 
complexity the reanalyzing step and sorting can be optimized.

A use case would be something with looks like
<xforms:model>
  <xforms:instance>
    <data xmlns=""><country xmlns="">Name of country base on the 
code</country></data>
  </xforms:instance>
  <xforms:bind nodeset="country" calculate="instance('countries')[. = 
current()/@code]"/>
</xforms:model>
<xforms:select1 ref="country/@code">
  <xforms:label>Select country:</xforms:label>
  ... select countries
</xforms:select1>

in another place in the form you can alter the names of the countries
<xforms:repeat nodeset="instance('countries')">
  <xforms:input ref=".">
    <xforms:label>Name:</xforms:label>
  </xforms:input>
</xforms:repeat>

Now if you change the select1 country code to DK then calculated value 
will be 'Dapnmark' (spelling error on purpose). Offended by the spelling 
the user goes to 'the change country name' section of the form and 
corrects the spelling. However since the @code was not 'DK' in the first 
rebuild the calcuate have no dependency to the country element 
containing Dapnmark and hence the form will not be correct before after 
a rebuild. An author could make a explicit xforms:rebuild when a country 
changes in the repeat, to update the form. However I would like to 
remove that requirement from the author and instead require that XForms 
can figure such details out.

I have seen forms with a lot of rebuilds in them and I guess that it is 
a rebuild for every time the author could not get something to work and 
thought maybe this requires a rebuild !?!? Every xforms:rebuild element 
in a form makes XForms less declarative.

Best regards,
David

-- 
--------------------------------------------
David Landwehr (david.landwehr@solidapp.com)
Chief Executive Officer, SolidApp
Web: http://www.solidapp.com
Office: +45 48268212
Mobile: +45 24275518
--------------------------------------------





======================================================================
Confidentiality Notice: The information contained in and transmitted with this communication is strictly confidential, is intended only for the use of the intended recipient, and is the property of Countrywide Financial Corporation or its affiliates and subsidiaries.  If you are not the intended recipient, you are hereby notified that any use of the information contained in or transmitted with the communication or dissemination, distribution, or copying of this communication is strictly prohibited by law.  If you have received this communication in error, please immediately return this communication to the sender and delete the original message and any copy of it in your possession.
======================================================================

Received on Wednesday, 22 March 2006 17:26:59 UTC