There are a couple cases in which DOM trees may be modified, and mappings of elements or attributes in the tree to nodes in another tree (or to application objects) must be maintained through those modifications. Two examples: (1) the current XBL syntax lets us describe mappings from one element to another element as its basis for implementation. For example, an html <object data="foo"> should be implemented as <iframe src="foo">, and the way we would do that in XBL is by saying <binding id="html:object"> <html:iframe inherits="src=html:data"/> </binding> or something like that. When the value of the src attribute is changed in the DOM, the implementation (the iframe here) should know to update its data attribute. (2) If dynamic XSLT were to be implemented (that is, XSLT in which the result tree changes to keep up-to-date with changes in the source DOM), it would need a good way of maintaining the three-way mapping between the source node, transformation rule, and result node. Other potential examples (I'm just making these up) could include dynamic XUL, where changes to the XUL DOM reflect in the GUI, dynamic XLink (which could get real interesting), and so forth... Having a good way to maintain mappings across DOM mutations (or perhaps more general, like templatizing mappings and mutation listeners) would be good, and deserves some thought.
I should clarify about XBL... The mapping specified by the xbl:inherits attribute on the iframe actually /is/ maintained (as hyatt explained to me) using some sort of mutation listener interface which serves a similar purpose to DOM2 mutation events. This approach works, but the trouble comes when we want to do trickier things than one-to-one mappings between attribute nodes. It'll take some thought to decide how powerful or obscenely-XSLT-like we want to make XBL (I'm all for language cleanliness), but we could make good, unrestricted decisions if we had a generic implementation of dynamic mappings...
Status: NEW → ASSIGNED
Been looking around during the tree closures, and I found some interesting stuff relating to this. I was trying to figure out how I would go about programming a map like this in C++, and snooped around the STL for relevant things such as multimap. Then I figured that RDF must do something like this, but I needed to know RDF first to understand, so I checked out the RDF spec. I realized that both only operate on binary relations, and that you have to jump through some (minor) hoops to represent relations of higher arity. Like, in the case of XSLT, the relationship between source context node, template rule, and result tree fragment. This brought me to some other stuff, though, surrounding the "semantic web" and knowledge representation: http://www.w3.org/2000/01/sw. I know nothing about this stuff, but it seems enlightened, if nothing else. I have a lot to learn...
I think I'm talking out of my ass.
I think I'm full of shit... observer/listeners *are* those mappings. Code could be written to automate insertion/removal of mappings based on rules, and that process could be further automated by writing those rules in some metalanguage. That would be cool, but that's just layering on top of what we have. I guess the proper resolution is worksforme, especially if bug 18722 claims dependency...
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.