Re: Accessing the original XML DOM after browser-applied XSL transformation?

It would be far cooler, IMHO, if the XSLT processor automatically
updated the transformation output on each change to the source XML DOM,
but was designed to do so without retransforming the entire document on
every change.  If I change a given node and its children within the
source XML, the XSLT processor should be capable of understanding
exactly what elements should be affected within the output DOM.  The
declarative structure of XSLT and the use of XPath seems to almost beg
for this treatment.  It seems within the realm of reasonable design,
and would really unleash the power of XML+XSLT in the browser.

Imagine, for a simple example, that I can send an XML document which
contains:
[...]
<somelist>
  <anitem abc='fark'>foo</anitem>
  <anitem abc='bar'>xxx</anitem>
</somelist>
[...]

Along with a static "<?xml-stylesheet ...>" reference at the top of the
document to a static XSL transform for the entire page to generate
complex XHTML[+CSS] in the browser.

And then, with javascript code (which was generated from the XSL file -
that can be confusing), I can access the source dom and inject or
remove <anitem>'s from the list and the XHTML page rendering stays
updated.

Of course there's the obvious downside of possibly infinite loops if
javascript makes a source DOM change which triggers a fragment
re-transform that causes the execution of javascript which makes a
source DOM change, etc, but the smart programmer would easily avoid
those scenarios.

But the results, I feel, are huge.  You would no longer have to
manipulate HTML display code and style attributes from javascript.  You
can simply manipulate the real XML representation of your actual data,
and let XSLT worry about *all* of the presentation details.  This
greatly simplifies the javascript code.

I only wish I knew enough about Gecko to implement it myself :)  For
some web-apps, the amount of saved work is almost enough to justify
writing the support code in Gecko.