Mutable DOM Source, foreign NodeSets, undefined IDs

[Jens von Pilgrim <j....@4flow.de>]

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