Re: should we use dom4j in future versions of XMLC?

Jake,

  It's interesting that you brought this up. I had a discussion with 
Mark on this long ago. Moving to DOM4J would require a major redesign 
of XMLC and may be a major work. There are not official architecture 
document for XMLC but let me try to give a brief overview on XMLC's 
several major components. For those who have taken compiler classes, 
this would sound very familiar.

1. Parsing: XMLC serves as a front end to parsers for several different 
*ML documents. Swing/JTidy for HTML parsing and Xerces for XML parsing. 
Some of the patches to the Xerces in XMLC has to do with DTD handling. 
I don't have the detail on this. Mark has mentioned it several times on 
the mailing list.

2. DOM tree building: A DOM tree is built from the parsing result

3. DOM tree walking: After the tree built, it walked to apply some of 
the modification such as urlmapping or node elimination.

4. Source generation. Several sources are generated in this pass. The 
Interface/Implementation, and for the new reloading, the meta data 
files.

The other major components in XMLC are:

1. LazyDOM. It provides a copy-on-modification of the W3C DOM. This 
prevents the copying of entire DOM tree in creation of the document 
object.

2. *ML output library. This is probably least know part of XMLC. It's 
all hidden behind the toDocument() call. However, this part is fairly 
complex and dealing mostly with the HTML. A discussion thread a while 
ago on the output encoding for HTML illustrate the complexity of 
handling HTML output.

Moving to DOM4J would require a lot of changes to to these 6 major 
components of XMLC. Also, the current code base is not as modularized 
and would probably require a major refactor before we can start 
incorporating new API like DOM4J.

David


On Sunday, Nov 17, 2002, at 14:31 Asia/Shanghai, Jacob Kjome wrote:

> Have any of the XMLC developers thought about using dom4j ( 
> http://www.dom4j.org/ ) in XMLC?  I know the topic of using JDOM has 
> come up before and the conclusion was that it doesn't provide anything 
> that DOM doesn't already do and forces one into a completely separate 
> interface so why change?  Well, dom4j seems to support the existing 
> w3c DOM and multiple JAXP compliant XML parsers (including its 
> internal Alfred2 parser) while providing a more Java-centric API, 
> better performance, and support for lots of different features:
>
> http://www.dom4j.org/index.html#Features
>
> See also....
> http://www.dom4j.org/compare.html
>
> The fact that dom4j seems so puggable makes me think that XMLC might 
> benefit in both performance and flexibility from using it.  Might this 
> solve some of our issues with Xerces and such?  I don't claim to 
> understand all the issues involved here.  I just want to get the idea 
> out there and see what people like Richard Kunze, David Li, and Mark 
> Diekhans think about this ...and, of course, the rest of the XMLC 
> community.
>
> Jake
>
> _______________________________________________
> XMLC mailing list
> XMLC@xxxxxxxxxxx
> http://www.enhydra.org/mailman/listinfo.cgi/xmlc