The dependency graph is modelled on the work done by John and Mikko in the XForms Working Group. The main difference would be that the domain over which the dependencies can operate would be the entire DOM, allowing elements in an SVG user interface--for example--to be controlled by data in an XForms model.
The basic principle would be that any node (element, attribute, text, etc.) can be defined as being the result of a calculation on any other nodes. This would include nested properties such as CSS values on the style property, for example.
In addition to setting values of existing nodes, dynamic nodes can be created within the DOM. This allows the existing XForms Model Item Property (MIPs) feature-set to be recreated, but with a more generic technology.
surrounding data to be processed simplifies signature security
Our current architecture says that we have some XML data to process, and we surround that data with an instance element, and the model then operates over such instances.
A second reason I like this architecture is that it simplifies signature security. From a web application programming model perspective, the easiest way to think of an XForm is that it encodes the entire client-side processing of the web app. I don't want to digress to the topic that it can be more than that because it can, but consider using XForms just for that. The question arises, how will you secure the 'application' represented by the XForms? An XML signature that signs the XForm less the content the instance elements would be equivalent to application signing.
This very useful capability is lost if the data over which a model can operate is not contained by anything useful.
must solve the self-modifying code problem
One thing I like about the architecture of containing the scope over which a model operates is the fact that if we let the scope be the whole document, then the model could operate over itself since it is in the document.
This is one reason why it's really nicer to say that you have some XML data, then you're going to put a processing model around that data, in both the literal and the figurative senses.
Data transformers in the dependency graph
It would be nice to support the notion of data transformers in the dependency graph...so a binding expression has some state and bi-directional transformations. A UI control binding to this would do getter/setter on the bind element ID not the instance data, and would receive value-change updates also from the binder not the instance.
There are lots of examples of this in existing UI frameworks...
Dependency graph in CDF
We might also consider how the generalized dependency graph is supported in compound document applications. It may be interesting to be able to allow or disallow visibility in nested document fragments, for example in the CDR use case in a manner similar to how events and other visibility across document boundaries is controlled.