[jdom-interest] JDOM BOF at SD West: problem resolving

[Jason Hunter]

So we had a great JDOM BOF (Birds of a Feather) session at SD West last
night.  Attendees from this list included myself, Elliotte Rusty Harold,
Phil Nelson, and James Davidson.  Another fellow who was interesting to
meet and had a lot of good ideas was W. Scott Means, Elliotte's
co-author on "XML in a Nutshell".  That's not everyone but it's the
folks most recognizable here.

We had a couple hour brainstorming session regarding some of the
remaining TODO items and how best to solve the problems, and happily we
reached consensus on many points.  Here's a list of items we made some
progress with:

* Do we keep original list data in case of illegal add?  

YES, absolutely.

* Do we go ahead with the Entity API Elliotte and I crafted together
early into the conference (now listed toward the top of the *current*
TODO)?  

YES, the approach was generally accepted as goodness.

* Do we add setName/setNamespace and deprecate getCopy()?  

YES, Elliotte's not 100% comfortable but he didn't wince too much
either.

* Do we have DocType hold the internal DTD subset as a string or
objects?  

String.  It's a rat hole to do a standard object representation of
Entity/Notation/ElementDecl/AtttributeDecl/etc with little benefit. 
Someone who really wants to do object manipulation can do it externally
using their own classes and with JDOM juse get/set the String.

* What do we do about adding the ability to output standalone="yes"?  

Nothing for the moment.  It's not a good fit anywhere.  For the
meanwhile, people who need it can override outputter's
printDeclaration().

* What to do about version="1.0"?  

Keep it hard-coded as "1.0".  There'll be new JDOM releases before new
XML releases.

* What to do about encoding?  

Leave it on the outputter.  Perhaps have a way to escape chars outside
the given charset.  Perhaps throw an exception if an element name,
attribute name, and others has a char which can't be represented in the
charset, because in these places you can't have character entities.  The
right approach isn't yet clear.

* Singly or doubly linked list?  

Singly was unanimously agreed on, at least for now.  In the rare
circumstances where you need to iterate backward or do indexed access,
you can always get the List, copy it to your own List, and iterate
backward.  Makes the performance O(n).

* Keep getSerializedForm() methods?  

No, deprecate and remove them.  Add this to the FAQ and add a note in
toString() about how toString() is for debugging and how you can use
XMLOutputter.print...()  methods to get the XML rep.  This is because
the logic for formatting an Elt/Doc as XML is *heavily* tweakable so no
one untweakable solution works.  Using XMLOutputter you have standard
tweaks available.

* Keep NO_NAMESPACE?  

Yes, it meshes nicely with the spec.

* Make DocType immutable or give it a parent?  

Parent.  It needs to be one or the other to avoid having the same
DocType instance in two docs and having a change in one affect the
other.  Having a parent means a DocType can only be used in one doc.

* Have ns.equals() do == or URI or prefix/URI check?  

URI comparison only.

* Should we verify the Namespace URI is legal per the RFC?  

No, most anything is legit as a relative URI and we already check for
empty string.

* Should we have methods for getting attribute values with a default?  

Consensus was the ?: operator works pretty well for the time being. 
Maybe later since it's easier to add things than take things away.

* Should DocType.equals() do == or equivalency checking?

Equivalency.  But treat the internal DTD subset as a literal string and
don't try to be fancy about two DTD subsets being equivalent.

* Should we have getTextTrim() continue to do internal whitespace
collapsing?  

Yes, because otherwise you can just call getText().trim().  But while
the functionality is useful the right name should probably be
getTextCollapsed() or getCollapsedText() or something because
getTextTrim() should do only a trim.  No good name appeared, and
backwards compatability concerns make us not want to tinker with this
unless we're sure of a better approach.


Comments welcome!  Barring serious issues being raised, I'll be adding
these things to the TODO and clearing out the old issues soon, then will
get chugging on implementing them all.

-jh-