[jdom-interest] Element Reference from Attribute

[James Strachan]

----- Original Message -----
From: <philip.nelson at omniresources.com>
[snip]
> > As I see it, JDOM can have two objectives:
> >
> > (1) Be extrememly easy to use for simple XML processing, but
> > not provide
> > 100% of XML functionality (no XInclude, some valid (but
> > perhaps esoteric)
> > XPath values not supported, etc).
> >
> > (2) Support all XML functionality, and be easier to use than
> > DOM, but not as
> > easy as possible.

I think we can happily do both through a 2 tier system.  I see great analogy
with Java collections.

<analogy>
Consider Java 2 collections. There is not one single Collection interface
that everyone must use. There are the List, Set and SortedSet interfaces for
when people need additional semantics above and beyond Collection for when a
Collection alone is not "powerful enough" or doesn't offer the necessary
navigation behavior. The more specialised classes derive from common base
classes so polymorphism is achieved it makes the API appear much simpler and
less complex.

If all you need is a Collection you create one. If you want a Set, you
create one. If your code accepts a Set you use typesafety to achieve this.
If your code that has a Collection cannot call some code which requires a
Set then you build a new Set (if it isn't already a Set).
</analogy>

So why should there be a single XML tree implementation? I don't think there
will ever be a single JDOM tree object model that we will all agree on to
work for most use cases just as there is no single Collection interface.

However I think we can have a usable standard base tree (such as the current
Element / Attribute singly linked tree implementation) and carefully thought
through additional layers of functionality (e.g. NavElement / NavAttribute
doubley linked tree for doing XPath and XInclude).

> The use of xml for storing structured data will be my most common use by
> far.  As JDOM moves closer and closer to DOM, the reasons for walking away
> from a "standard" starts to seem questionable.

If JDOM is only ever a Java port of DOM which uses Java coding notations,
Java collections and other Java features such as hashCode(), equals() and is
more efficient and easier to use then it would still be of real value IMHO.

> There is already an open source and a number of commercial DOM tools out
> there.  Should JDOM really try to compete with that?

I'd say no. But JDOM should offer similar features in a clean, simpler Java
friendly way.

> Is it good thing for
> JDOM to try to be the java way of doing xml whereas every other language
is
> busy implementing the standard DOM?

Yes IMHO.

There will be always be other ways of doing XML too. There's already SAX and
will be a variety of 'Java Data Binding' APIs too. Just because DOM is a W3C
standard doesn't mean there isn't room for a Java optimised standard which
achieves similar things in a more Java focussed way.

> Won't JDOM always be behind the other
> tools in implementing new DOM functionality?

It could well overtake it one day real soon. Afterall JDOM has the whole of
the Java platform to reuse (Threading, Serialisation, JDBC & JMS to name a
few), DOM has to reinvent everything itself.

> Now if we could do it *and* keep it light weight...

I think we can. I think the posts over the last day or two seem to be going
in the right direction. Custom building and a tiered tree model seem the
right direction to me.

J.

James Strachan
=============
email: james at metastuff.com
web: http://www.metastuff.com




If you are not the addressee of this confidential e-mail and any
attachments, please delete it and inform the sender; unauthorised
redistribution or publication is prohibited. Views expressed are those of
the author and do not necessarily represent those of Citria Limited.