Items that need to be done: --- AFTER BETA 8 --- * Add methods to recursively get content and get filtered content. * Look into hasContent() and hasAttributes() methods to eliminate need to create lists during output. * Look at making CDATA and Text either the same class or in the same class hierarchy. * 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? http://lists.denveronline.net/lists/jdom-interest/2001-February/004521.html http://lists.denveronline.net/lists/jdom-interest/2001-April/005644.html http://lists.denveronline.net/lists/jdom-interest/2001-April/005649.html http://lists.denveronline.net/lists/jdom-interest/2001-April/005669.html Brad Huffman has a good proposal. (Brad's) * 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) * In web.xml we're seeing the comments from the external DTD appear in our document (bug 6317 in Xerces' Bugzilla, fixed 13 Mar) * Look at where Namespace may need to be synchronized or made no longer a flyweight. See http://lists.denveronline.net/lists/jdom-interest/2000-September/003009.html and follow-ups. * 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 be ignored. (Laurent Bihanic wrote JH a private email about this on Dec 28 2001.) * Performance optimize. See following thread for test data. http://lists.denveronline.net/lists/jdom-interest/2000-October/003418.html http://lists.denveronline.net/lists/jdom-interest/2000-October/003472.html 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 --- * 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, java.lang.String newXmlEncoding) 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. See http://lists.denveronline.net/lists/jdom-interest/2000-August/002088.html And http://lists.denveronline.net/lists/jdom-interest/2000-August/002102.html * 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 is helping with the J2EE CTS. * Make sure we have a plan for supporting obj serialization across current and future JDOM versions. See "serialVersionUID" thread especially Peter V. Gadjokov's remarks at http://lists.denveronline.net/lists/jdom-interest/2000-September/subject.html It may be OK to worry about fast short-term serialization only. * 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 Joe Bowbeer. http://www.servlets.com/archive/servlet/ReadMsg?msgId=7602 begins it * Joe summarizes his issues at http://www.servlets.com/archive/servlet/ReadMsg?msgId=7697 * Make sure that JDOMException is compatible with JDK 1.4 nested exceptions. E.g. should getNestedException find 1.4-type nested exceptions? Do both 1.4-type nested exceptions and JDOMException both try to print child stack traces, causing them to be printed twice? * 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 http://www.w3.org/TR/2000/REC-DOM-Level-2-Traversal-Range-20001113/ Joe Bowbeer has ideas at: http://lists.denveronline.net/lists/jdom-interest/2000-November/003610.html 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. * Add XPath support, most likely integrating Bob McWhirter's package. * Figure out XPath interface, current best is this: List XPath.getList(Element e, String xpath) // or Document param Comment XPath.getComment(Element e, String xpath) Element XPath.getElement(Element e, String xpath) ProcIns XPath.getProcIns(Element e, String xpath) Entity XPath.getEntity(Element e, String xpath) String XPath.getText(Element e, String xpath) * Investigate a way to do in-memory validation. First step is probably to get an in-memory representation of a DTD as per http://xmlhack.com/read.php?item=626 http://www.wutka.com/dtdparser.html http://lists.denveronline.net/lists/jdom-interest/2000-July/001431.html http://lists.denveronline.net/lists/jdom-interest/2001-February/004661.html 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 errors possible. 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. http://dcb.sun.com/practices/devnotebook/xml_msv.jsp http://www.sun.com/software/xml/developers/multischema/ * 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: http://lists.denveronline.net/lists/jdom-interest/2000-July/001586.html http://lists.denveronline.net/lists/jdom-interest/2000-July/001587.html http://lists.denveronline.net/lists/jdom-interest/2000-July/001600.html * Consider a "locator" ability for nodes to remember the line number on which they were declared, to help debug semantic errors. http://lists.denveronline.net/lists/jdom-interest/2000-October/003422.html --- 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 numeric. * 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. See http://lists.denveronline.net/lists/jdom-interest/2001-July/007362.html 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 (See http://www.saxproject.org/apidoc/org/xml/sax/ext/Attributes2.html) (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/ directory. http://metalab.unc.edu/xml/slides/xmlsig/jdom/JDOM.html * Add a search for jdom.org using Google with site:www.jdom.org, imitating http://www.zope.org/SiteIndex/searchForm * Fix it so check-in messages include diffs. (jools@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 objects regardless. * Consider having the license be clear org.jdom is a protected namespace. --- WILD IDEAS --- * 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: http://lists.denveronline.net/lists/jdom-interest/2000-December/004016.html There were many follow-on threads. * 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. http://xml.apache.org/xerces-j/features.html * Create a JDOM logo. * Create a Verifier lookup table as an int[256] 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 or not. * Use new Ant regexp task for more efficient JDK 1.1 package renaming. * 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 getAdditionalNamespaces(). * 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 http://lists.denveronline.net/lists/jdom-interest/2000-October/003303.html http://lists.denveronline.net/lists/jdom-interest/2000-October/003304.html http://lists.denveronline.net/lists/jdom-interest/2000-October/003318.html http://lists.denveronline.net/lists/jdom-interest/2000-October/003535.html * Look at event-based parsing as per the following thread: http://lists.denveronline.net/lists/jdom-interest/2000-November/003613.html and replies. 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) http://lists.denveronline.net/lists/jdom-interest/2000-December/004155.html * 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 http://lists.denveronline.net/lists/jdom-interest/2001-April/005685.html