Items that need to be done:
--- API CHANGES FOR 1.0 ---
* Look at Brad's experimental tree for good ideas to integrate.
* Make sure the filter classes have hashCode() methods.
* Add DocType to the content list returned by Document so it can have a
location. Fix the outputters and builders to respect it. Keep the easy get
* Look at interfaces for the core classes, Element with ConcreteElement being
our code. Base on the factory model. Allow no access between objects
except using the public API, to avoid the import node problem. Do the big
switchover using javax.xml.jdom as interfaces and default impl, use org.jdom
for the concretes. May not need to break existing code (sick and wrong).
* Strategy pattern for XMLOutputter and others.
If need for override, make others final and leave the protected.
* Make transforming easier, with a one-line method.
* Should there be ValidityException and MalformedException subclasses of
JDOMException? Elharo has a proposal.
* Finalize the XPath class interface. Possibly take calls into Element,
* Add methods to recursively get content and get filtered content.
* Figure out how to deal with XMLOutputter writing of special characters like
. Should it char escape only chars unprintable in the current
character set? Should there be a fancy API for selecting what's escaped?
Should this be something where you can subclass?
* Look at where Namespace may need to be synchronized or made no longer a
* Look into how the factory builder model could support giving the factory
extra knowledge about the context (line number, element stack, etc), and
allow it to report errors or to return a code indicating the element should
(Laurent Bihanic wrote JH a private email about this on Dec 28 2001.)
* Figure out if there's a role for a Node interface. It sounds easy but all
attempts so far have hit obstacles. Amy Lewis talks about it here:
There were many follow-on threads.
* Consider moving JDOMFactory to org.jdom.
* Investigate serialization issue raised by Tom Preston
* Look into hasContent() and hasAttributes() methods to eliminate need to
create lists during output.
* Start shipping Xerces 2.0+
Xerces 2.0.0 bugs found when using DOMBuilder:
* In cdata.xml we're getting entity callbacks for chars inside CDATA
sections (bug 6316 in Xerces' Bugzilla, fixed Feb 2002)
* In web.xml we're seeing the comments from the external DTD appear in our
document (bug 6317 in Xerces' Bugzilla, fixed 13 Mar 2002)
* Performance optimize. See following thread for test data.
One idea: Stop using synchronized Stack in SAXHandler.
* Give attributes the "specified" flag like in DOM. This probably isn't
receivable from SAXBuilder, but it would be from DOMBuilder and other
builders. Then give XMLOutputter the ability to avoid outputting
"unspecified" attributes. Some of this may be covered by the attribute type
support recently added.
* Look into implementing an id() method now that we have attribute types.
--- FOR JDOM 1.0 COMMUNITY REVIEW ---
* Expand class-level Javadocs for inclusion into Frame using the MIF Doclet.
* Note in the docs where necessary our multithreading policy.
* Add in attribute type support to DOM to match what's in SAX.
* Think about if XMLOutputter should have a few specific output states, like
RAW, PRETTY, COMPRESSED. See the thread "XMLOutputter inserts extra empty
lines" for some discussion.
--- FOR JDOM 1.0 ---
* Write a "GNU JAXP (i.e. AElfred) DOM adapter" (elharo looking into this).
* Create "build dist" for distribution
Use fixcrlf in dist (instead of package as currently done)
Probably include source with jdom.jar built
* Consider changing XMLOutputter to have more set methods like Enhydra's
DOMFormatter. Possible good ones:
void setPreserveSpace(boolean preserve)
Set the default space-preservation flag.
void setXmlEncoding(java.lang.String newXmlEncoding)
Set the encoding using the XML encoding name.
void setXmlEncoding(java.lang.String newJavaEncoding,
Set both the XML and Java encodings.
* Consider adding methods/logic to Verifier for all XML spec. constraints
(Consider specifically a PCDATA check. Downside is Elliotte says it
causes a 20% performance penalty on building docs.)
Probably go with sanity checking input unless it adds significant time to
a SAX build.
* Consider changing the Verifier method signatures to throw the
IllegalXXXException directly instead of returning null on error,
and let the caller pass the exception through
* Populate jdom-test. Jools is leading this but Phil Nelson is currently
doing a lot of work. Hong Zhang <Hong.Zhang AT Sun.COM> is helping with the
* Ensure JDOM is appropriately tweaked for subclassing, per the threads
started by Joe Bowbeer.
http://www.servlets.com/archive/servlet/ReadMsg?msgId=7601 begins it
* Ensure JDOM is flawless regarding clone semantics, per more threads by
http://www.servlets.com/archive/servlet/ReadMsg?msgId=7602 begins it
* Joe summarizes his issues at
* Clean up Javadocs right before final release.
--- FOR JDOM 1.1 ---
* Consider visitor pattern
Use cases: count elements, count nodes, translate comments, remove PIs
Would implement with option to visit depth or breadth first
Maybe go crazy with pre-order, in-order, and post-order too :-)
Methods would exist on Document and Element
FYI, DOM's much overweight Traversal-Range spec is at
Joe Bowbeer has ideas at:
We may be able to just have doc.iterator() methods
Also see posts with the subject "How to ease traversal of JDOM tree"
* Add setIgnoringAllWhitespace(boolean) method.
* Investigate a way to do in-memory validation. First step is probably
to get an in-memory representation of a DTD as per
Maybe new DTDValidator(dtd).validate(doc);
Then later new SchemaValidator(schema).validate(doc);
Could instead do doc.validate(dtd/schema) but then we'd have to dynamically
switch between recognizing DTDs and the various schemas.
The method would probably either throw InvalidDocumentException or might
take an ErrorHandler-style interface implementation if there are non-fatal
It'd also be possible to have a programmatic verifier, that determined for
example if an orderid="100" entry was valid against a database entry.
* Consider a listener interface so you could listen to doc changes.
(Probably after 1.1 honestly; this can be done through manual subclasses
already.) Some pertinent messages on this topic:
* Consider a "locator" ability for nodes to remember the line number on which
they were declared, to help debug semantic errors.
--- UNTIED TO A JDOM VERSION ---
* Consider an XMLOutputter flag or feature to convert characters with well
known named character entities to their named char entity form instead of
* Determine if DOMBuilder and DOMOutputter should transparently support DOM1.
* Perhaps have builder flags to indicate if CDATA sections should be
included and if comment sections should be included. All seem like
reasonable customizations. The whitespace flag may respect xml:space.
It might use an XMLFilter to do the job.
* Create a builder based on Xerces' XNI, which will be more featureful and
probably faster than the one based on SAX.
Some existing SAX limitations which hurt round-tripping:
* Can't tell if attribute values are included from the DTD, because SAX
doesn't tell if attributes are standalone/implicit
(Thought: could use a bit in the type value to save memory)
* Can't get access to retain the internal dtd subset unless entity
expansion is off
* Contribute the samples from Elliotte's XML DevCon talk to the samples/
* Add a search for jdom.org using Google with site:www.jdom.org, imitating
* Fix it so check-in messages include diffs. (jools AT jools.org)
* Add ElementLocator to contrib/ directory (from Alfred Lopez)
* Write a guide for contributors. Short summary:
Follow Sun's coding guidelines, use 4-space (no tab) indents, no lines
longer than 80 characters
* Consider a builder for a read-only document. It could "intern" objects to
reduce memory consumption. In fact, interning may be good for String
* Consider having the license be clear org.jdom is a protected namespace.
--- WILD IDEAS ---
* Think about somewhat crazy idea of using more inheritance in JDOM to allow
lightweight but not XML 1.0 complete implementations. For example Element
could have a superclass "CommonXMLElement" that supported only what Common
XML requires. Builders could build such elements to be faster and lighter
than full elements -- perfect for things like reading config files. Lots
of difficulties with this design though.
* Look at Xerces parser features (http://apache.org/xml/features/dom) for
ideas on things that may be needed.
* Create a JDOM logo.
* Create a Verifier lookup table as an int growable to int[64K] where
bits in the returned value indicate that char's ability to be used for a
task. So "lookup[(int)'x'] & LETTER_MASK" tells us if it's a letter
* Consider elt.getTreeText() which would recursively get the text (in order)
for the subtree, effectively ripping out interveneing Elements. (Suggested
by Bob to help with XPath.)
* Shouldn't addNamespaceDeclaration() have a name to match
* Consider an HTMLBuilder that reads not-necessarily-well-formed HTML and
produces a JDOM Document. The approach I'd suggest is to build on top of
JTidy first. That gives a working implementation fast, at the cost of a
157K Tidy.jar in the distribution. After that, perhaps someone would lead
an effort to change the JTidy code to build a JDOM Document directly,
instead of making a DOM Document or XML stream first. That would be a lot
faster, use less memory, and make our dist smaller. See
http://www.sourceforge.net/projects/jtidy for Tidy.
* Look at a (contrib?) outputter option using SAX filters per
* Look at event-based parsing as per the following thread:
Also see posts with the subject "streamdom".
* Considering that local vars are considerably faster that instance vars, test
if using local vars can speed building.
* Consider a builder.setFeature() pass-through method that allows any
features to be set that aren't in the http://xml.org namespace. Make
those in http://xml.org not to be touched because either we have specific
requirements for them to be set one way, or we have the feature exposed
through a Java method.
* Consider Mike Jennings' proposal of two new methods on Element:
public String getAttributeValue(String name, String default)
public String getAttributeValue(String name, Namespace ns, String default)
* Consider using a List of instance data so elements only use what they really
need (saving attrib list, namespace list)
* Investigate doc.getDescription() to let people add doc descriptions. It's
an idea from IBM's parser suggested by andyk.
* Work on creating a deferred builder that parses only what's necessary to
satisfy the programmer's requests. See Ayal Spitz' post at
* Create an HTMLOutputter to handle the HTML specific aspects (closing tags,
escaped characters like é, etc).
* Add Laurent's <?javax.xml.transform.disable-output-escaping?>
and <?javax.xml.transform.enable-output-escaping?> support
* Fix the sorting problem.
Alex idea: http://www.servlets.com/archive/servlet/ReadMsg?msgId=211785
* Change the various setAttributeValue() methods in Element and
Attribute to check the attribute type and normalize the string
according to the attribute type. i.e. normalize the white space if
the attribute has any type other than CDATA or UNDECLARED.