[jdom-interest] what is JDOM?

[Dave Churchville]

> In my view, JDOM should be designed to faithfully represent the XML
> document (both as an end in itself, and as an intermediate
> representation between XML documents and Java data), but JDOM should not
> go out of its way to support arbitrary data binding itself.

Agreed, data-binding is about converting "generic" XML data into
specific, typed Java classes.  JDOM is clearly about loading generic XML
data into a generic Java representation (Element, etc.)

> 
> To fully support data binding, I believe, JDOM would need a complete set
> of interfaces for alternate implementations, carefully crafted template
> classes for custom extensions, and factories.

Well, it would be something other than JDOM, I think, not a set of
extensions.

> 
> When people ask about how to override methods in Element or how to
> create their own SAXBuilder, I wonder if they're working with the wrong
> tool.
> 

At least for my needs, the ability to override methods, use custom (or
enhanced) SAXBuilders, etc., is to enhance the *generic* data model
capabilities for an app-specific purpose.  For example, when writing a
tool or utility that will process XML in some way, there is often a need
for "housekeeping" or "tag-along" data that you wish to hang on the
generic element.

Simple case: after parsing a document, I want to process all elements,
and mark them with a flag "visited" to I know I processed them.  I
*could* do this by creating another set of data structures that *point*
to the element, but it would be easier, less memory intensive, and
downright convenient if I could simply create a subclass of Element that
has the extra flag.

My application could then use "standard" JDOM things to save or modify
the generic data model, since I only needed the extra information for
in-memory processing.

--Dave