[jdom-interest] Why not have an open source common pool of XML-Java objects?

adam flinton aflinton at armature.com
Tue Jun 5 02:26:59 PDT 2001

Dear All,

I have been looking at doing a GUI front end for XML-DBMS & some things have
struck me.

The first is that if people are happy with Java / Objects / Code reuse why
is there no common pool of classes & beans? 

I came to Java from an OpenDoc background & like the idea of assemble from
parts / components. This also makes a lot of sense wrt to OpenSource (i.e.
the code is designed to be shared), Java (it's OO & "pluggable" nature) &
last but not least XML (std'ized data/metadata text format). Put the 3
together & surely (ego's aside) you simply **must** have common components.

It strikes me that Sun are helping with part of this with JAXP however there
are a lot of fairly fundamental bits which are being duplicated / rebuilt by
just about every Open Source group who're dealing with Java & XML which is

 As a good example in XML-DBMS (XD) we have parsers abstracted to
"ParserUtils" whereas in JDOM there are "DOMAdaptors" which are almost
exactly identical (except that the JDOM interface has fewer methods) right
down to which parsers are supported. In fact just about the only design diff
is that JDOM uses an intermediate abstract class as a buffer between
interface & implementation which having seen I might implement in XD.

Now to be honest stuff like that isn't directly in the "the domain" of XD as
it's real job is shuttling data XML <> SQL. & this is more of an "XML
Software Support service". So at the moment you have at least 2 code bases
doing the exactly same thing, both of which need maintaining etc. Other
examples are namespace support etc (i.e the "behind the scenes" /support

What I am looking at at the moment is "template handling". By this I mean
anything which defines what a Doc can / cannot be, is / is not valid e.g.
DTD'es, Schema's, Schematron, Relax etc.

The fact that there is such a list suggests strongly to me that like
ParserUtils/DomAdaptor that this should be an Interface. However while XD
has a DTD parser which can be used for DTD'es  what is the point in having
it hidden inside the XD code? Who else can use it? Who even knows it's
there? As another example we also have a set of JMS classes which simply
"drop in" to provide JMS support. Again who else can use it/ knows it's

Equally every man & his dog will have to support schema's eventually & which
is better 3/4/5 etc. groups each doing their own or a common set of code
improved on by all 3/4/5 etc?

So firstly what does anyone think about say "org.oss.xml.java" or similar?
Possibly put it through Apache? The way I see it there is a fairly large
area of what I would call "XML Support" such as parser handling, Template
(Schema,DTD etc) handling etc which is simply the underlying infrastructure
to **any** Java<>XML code.

Re Template handling.

Has anyone got any ideas re the interface?

AFAICS for a given node you have:

	 {"Who Am I" (i.e. what node am I), <-Siblings->, Order
(Cardinality) ,
	 Metadata (Attribs,+*? etc & with Schema's typing/length other
validation restrictions etc.)}
{Children (inc Order}
Has anyone else any ideas re what should be in a common templating

I should not have to care what is providing the validation rules
(Schema/DTD/Relax etc) but simply that I can create a valid document.
Equally given the diversity of templating concepts & ideas the design should
be "pluggable" i.e. build a doc off a DTD & the DTD handler loads, build one
off a schema & the schema handler loads etc (i.e.
classforname(template_handler_class_name_string)) then others can come along
& do a Relax handler or whatever. 

It strikes me that with schema's coming along anyway & with people all
having to write stuff to deal with them (not to mention Schematron etc) then
this stuff would be a good candidate for a "common pool approach".

So basically 3 questions:

1) Common Interface for templating / building "valid" documents - any ideas
what it should comprise?
2) The whole idea of a common pool of objects / class'es for the non domain
specific Java<>XML stuff.
3) Other than templating & parser handling has anyone got any feelings on
what else is basically common infrastructure?


Adam Flinton

More information about the jdom-interest mailing list