Hello,
is it possible to use mutable (or dynamic) DOM Sources in XALAN 2.x?
I've implemented a DOM adapter on top of an object model. The adapter
maps object properties to dom.Elements and dom.Attributes. The adapter
itsself is immutable, that is all setter-functions like Node.appendChild() throw an exception.
Additional, for some purposes I want to implement extensions returning NodeSets.
Now I'm running into some problems (or, perhaps, no problems?):
1) An adapted object, like an ArrayList (which items are mapped to child elements), can change while
Xalan is processing an XSLT (or, even worse, this change can be caused by the processing).
That is, given a dom.Element, the dom function getChildren() returns 5 nodes the first time and
10 nodes the second time it is called. Does this behaviour cause problems?
2) When calling an extension returning a NodeSets, the nodes of the set are not always part of the original dom source, that is a returned node getOwnerDocment != source document. Does this cause problems?
3) Some properties are mapped as IDREFS (since the origial object model is not a tree). The referenced objects have not to mapped before the refering object is mapped. That is, given an element e1 (<e1 id="_10" idrefs="_14">) references element e2 (<e2 id="_14">). But, e2 is not part of the dom tree, that is it is not reachable using XPATH. Since I also implemented the Document interface, e2 can be obtained by calling e1.getOwnerDocument().getElementByID("_14"). (In my case element e2 is inserted into the tree when the getElementByID function was called, this leads to question 1.). Does this cause problems?
I think that all questions lead to the question if Xalan caches information about the DOM source while processing, like information about the tree structure and so on. Is Xalan "prepared" for dynamic DOM sources, which can change while processing?
Of course I can simply test all my test cases. But I'm not feeling comfortable if some test cases runs and I still don't know if the concept is working...
jens
For better understanding of the problem here an example:
Source DOM source tree looks like that:
<doc>
<list />
<e1 id="_10" idrefs="_14"/>
</doc>
Now the extension function id is called
<xsl:for-each select="id(@idrefs)">
Now, the DOM source tree looks like that (if it's dumped):
<doc>
<list />
<e1 id="_10" idref="_14">
<e2 id="_14" />
</e1>
</doc>
--> Question 1) and 3)
Now, my extension function is called:
<xsl:for-each select="query:listObjects('value>20')">
...
</xsl:for-each>
returning three obj-Elements. These elements are added to the tree - by the adapter, hidden for Xalan.
Now, the DOM source tree looks like that (if it's dumped):
<doc>
<list>
<obj value="21"/>
<obj value="22"/>
<obj value="1000"/>
</list>
<e1 id="_10" idref="_14">
<e2 id="_14" />
</e1>
</doc>
--> Question 1)
Now, another extension function is called:
<xsl:for-each select="query:selectObjects('value<5')">
...
</xsl:for-each>
returning some obj-Elements. These elements are _not_ added to the source document tree, they are only viewable for Xalan using the returned NodeSet. Probably the getOwnerDocument() function doesn't return the source tree document.
In other words, these elements are only accesible inside the for-each element of the XSLT.
--> Question 1) and 2)
____________________________________________________________
Jens von Pilgrim
4flow AG
Berlin, Germany
