[jdom-interest] Code submision: JDOM2 the dual tree implementation...

Jason Hunter jhunter at acm.org
Sun Nov 26 16:42:09 PST 2000


(Thinking out loud about the 2-level JDOM.)

As I'm thinking about the 2-level JDOM I'm wondering if it can solve
other pressing problems we have.  For example, one other performance
issue with JDOM is that some want JDOM to validate all names and content
on construction to ensure only well-formed documents are created.  This
causes a runtime performance penalty that others would like to avoid.

One approach to solving this (following the model of the 2-level split)
is to have a base class set that doesn't do the checking and a subclass
set that does (or vice versa).  The same arguments employed right now to
split JDOM classes for parentage would seem to apply to well-formedness
checking.

But the 2-level solution doesn't scale well to 3-levels.  I don't want a
"simple" baseclass and an "everything" subclass.  There will be people
who want parentage but not well-formedness, and there will be people who
want well-formedness but not parentage, and there will be people who
want both.  After debate we could end up with a simple baseclass, a
formedness subclass, a parentage subclass, and a formedness+parentage
subclass.

Let's look then at user data.  Some want it, some don't.  Some who need
getParent() -- because they want to modify attribs in place for example
-- don't want user data, and perhaps vice versa.  Do we want to see a
base JDOM, a parentage JDOM subclass set, and a user data JDOM subclass
set?  What about people who want user data but not parentage?  What
about well-formedness?

I'm starting to think that for each contentious issue people who want
the less popular model are going to see a baseclass/subclass split as
desirable, but unfortunately it's a model that doesn't scale well.

(Again, just thinking out loud.)

-jh-



More information about the jdom-interest mailing list