51420 - Need generic way to maintain mappings across DOM mutations

Status: RESOLVED WORKSFORME

(Core :: XML, enhancement, P3)

Description

[Dan Rosen]

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.

Comment 1

[Dan Rosen]

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...

Comment 2

[Dan Rosen]

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...

Comment 3

[Dan Rosen]

I think I'm talking out of my ass.

Comment 4

[Dan Rosen]

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...