NodeSets versus NodeLists

[Jo...@lotus.com]

I've got an architectural imponderable I've been wrestling with, and I'd
like to throw it open for input...

In older (STree-based) versions of Xalan-J, the Xalan Node Set class also
implemented the DOM NodeList API. I don't believe this was ever documented
as a feature -- it was something we did for our own convenience. When we
moved to DTM, we implemented a similar NodeSet, but since the DTM Node
Handle and DOM Node reference types are incommensurate we had to drop
NodeList support from this class. (Specifically: the item(int) call would
have to return an object reference to support NodeList, but DTM wants to
return an integer NodeHandle from the same call.)

That shouldn't have been a problem. But apparently some folks assumed that
NodeList was part of this object's published API. The dbxml project in
particular assumed that a NodeSet could be cast directly to NodeList... and
has not updated its code to deal with the fact that this is no longer true.
GUMP shouts at us about that on a regular basis.

There are two possible solutions.

One is to try to preserve the backward compatability by making NodeSet
implement NodeList, and changing its "native" DTM API to avoid the
conflicts. If we're going to do that, we should do so SOON, since it'll be
a lot harder to justify altering DTM after the next non-developer release.

The other is to preserve DTM architecture by saying that this cast was
never officially supported in the first place, and require that dbxml --
like the extensions -- be updated to track Xalan. We could provide them
with a NodeSet.itemAsNode() convenience function, and/or
NodeSet.getNodeList(), either of which would create proxy objects (again,
as we do for extensions)... but dbxml would have to bite the bullet and cut
over.

My own preference leans strongly toward the latter (I don't think a NodeSet
should ever have been an instance of NodeList in the first place, since
NodeList in the DOM had "liveness" implications that we didn't really deal
with)... but there are other folks leaning equally strongly the other way.
I'm not 110% certain my own answer is the right one, so I'd like to solicit
comments from the community.

Re: NodeSets versus NodeLists

[Tom Bradford <br...@dbxmlgroup.com>]

Joseph_Kesselman@lotus.com wrote:
> One is to try to preserve the backward compatability by making NodeSet
> implement NodeList, and changing its "native" DTM API to avoid the
> conflicts. If we're going to do that, we should do so SOON, since it'll be
> a lot harder to justify altering DTM after the next non-developer release.
> 
> The other is to preserve DTM architecture by saying that this cast was
> never officially supported in the first place, and require that dbxml --
> like the extensions -- be updated to track Xalan. We could provide them
> with a NodeSet.itemAsNode() convenience function, and/or
> NodeSet.getNodeList(), either of which would create proxy objects (again,
> as we do for extensions)... but dbxml would have to bite the bullet and cut
> over.

Hi Joe,

There's only one spot in the dbXML source code that uses the NodeLists
returned by Xalan, and that's in the XPathQueryResolver.  It will be
fairly easy to get this code in sync with the latest version of Xalan.  

I think the problem that we're facing in general is that we link against
an older (non-DTM) version of Xalan.  This in itself isn't a bad thing,
but the GUMP mentality is to make sure that the latest and greatest of
any project builds against the latest and greatest of everything else.

I think the decision that's made should be made to accommodate developer
flexibility, but not at the cost of performance.  We don't need a
mutable nodelist to be returned, but I can't speak for other developers.

--Tom