[jdom-interest] what is JDOM?
dmc at clearlight.com
Sat Nov 4 09:58:44 PST 2000
> 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
> 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
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
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
More information about the jdom-interest