Items that need to be done:

--- RIGHT AWAY ---

* Revise the JavaWorld articles to match the beta5 API (Jason and Brett)

--- 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 setJavaEncoding(java.lang.String newJavaEncoding) 
                       Set the encoding using the Java encoding name.
   void setLineWidth(int width) 
                       Set the width at while long lines are split 
                       when indentation is enabled.
   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.

* Probably change DOMAdapter to take File for a filename.  (Brett's call)

* Figure out if adding an element as a child of itself (or grandchild or
  great-grandchild) should be stopped.  Probably so.  The logic to implement
  this was laid out in the thread "How to "crash" JDOM, part 1" by David 
  Smiley.  (Work being done by trebor.a.rude@lmco.com)

* Probably add an Attribute.getParent() method (to help XPath)

* Add better handling of bogus undeclared prefixes like <bogus:foo/>

* Add CrimsonDOMAdapter

* Have PartialList sanity check new object types as legal.

* Consider having element.getChild("foo") use the namespace of the invoked 
  element.  Currently is would be the default namespace.  With this new
  approach you'd pass null to use the default.  This would be more convenient,
  but the downside I see is that it would be inconsistent since 
  new Element("foo") would only create elements in the default namespace.

* Since DOMOutputter is just DOM1, consider a DOM2 outputter
  Probably support DOM2 only, in theory of tracking latest versions

* Figure out if there should be a public no-arg Document constructor to
  support building docs with more than just root elts.  Currently you have to
  use a trick of new Document(null).  Elliotte thinks we should go the 
  opposite way and disallow creating docs without roots, thus enforcing the
  rule that JDOM only creates well-formed docs and docs are well-formed from
  the beginning.  That makes severaly ugly code though.

* 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.)

* 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

* Have Jools populate jdom-test

* Implement SAXOutputter (Fred_Trimble@vertexinc.com)

* Implement inline entities:
        <?xml version='1.0' ?>
        <!DOCTYPE mydtd[
        <!ENTITY nbsp '&#160;'>
        <!ENTITY aring '&#229;'>
        <!ENTITY auml '&#228;'>
        <!ENTITY ouml '&#246;'>
        <!ENTITY Aring '&#197;'>
        <!ENTITY Auml '&#196;'>
        <!ENTITY Ouml '&#214;'>]>

        <DOCUMENT>
                God forts&auml;ttning p&aring; det nya millenniet!
        </DOCUMENT>

* Finalize how regular entities are to work

* Consider SAXBuilder.setIgnoreingWhitespace() and similar
  Should save lots of memory.

* Consider enhancing SAXBuilder to use filters per
  http://www.megginson.com/SAX/Java/filters.html
  That would let someone remove surrounding whitespace and other fancy things.

* Writing a "Getting started" guide for newbies 
  (Tom Clements <clements@eng.sun.com>)

* Add JAXP 1.1 supporting classes when it's ready.  Design them to follow the
  JAXP model so they are usable without JAXP, and can be trivially made to
  work with JAXP.

* 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.

* Make sure we have a plan for supporting obj serialization across current and
  future JDOM versions

* Look at standard parser features (http://apache.org/xml/features/dom) for
  ideas on things that may be needed.

* Perhaps have builder flags to indicate if surrounding whitespace (not just
  ignorable whitespace) should be trimmed, if entity refs should be expanded,
  if CDATA sections should be included, and if comment sections should be
  included.  All seem like reasonable customizations.

* Look at the issue that PartialList.listIterator() may return an Iterator
  that doesn't have logic to change the backing List and sanity check the
  change.  See post by "Chris Hamersley" <chris.hamersley@xmlglobal.com>
  31 Aug 2000.  Also a follow-on by "Peter V. Gadjokov" <pvg@c-c-s.com> 
  27 Sep 2000 and a test case by "Travers Waker" <traversw@innoforge.co.za>
  27 Sep 2000.

--- FOR JDOM 1.1 ---

* Add XPath support
  Much work being done by Michael Hinchey

* 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)

* Eliminate string hardcoding.  Use resource bundles to allow for
  localization.

* 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

--- UNTIED TO A JDOM VERSION ---

* Contribute the samples from Elliotte's XML DevCon talk to the samples/
  directory.  http://metalab.unc.edu/xml/slides/xmlsig/jdom/JDOM.html

* Add 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)  Use
  archive to create an accurate CHANGELOG.txt for what changed between betas.

* Add ElementLocator to contrib/ directory (from Alfred Lopez)

* Figure out if we need to support maintaining CDATA sections

* Put www.jdom.org content under CVS

* Write a guide for contributors
    Follow Sun's coding guidelines, use 4-space (no tab) indents, no lines
    longer than 80 characters

* Look at putting XML files in the jdom.jar META-INF directory for things like
  version, credits, description, etc, then access/print the info using JDOM
  classes executed by a "java -jar jdom.jar" command.  
  See http://java.sun.com/docs/books/tutorial/jar/

* Investigate including a library to convert XML data to instantiated Java
  objects, probably with an XML config file dictating how to do the mapping.
  See http://xmlhack.com/read.php?item=674 for something along these lines.

* Investigate adding Andy's library (jhunter)

* Verify JDOM is compliant with Infoset

