[jdom-interest] XOM

[Elliotte Rusty Harold]

At 3:14 PM -0700 9/24/02, Dennis Sosnoski wrote:
>When do you expect to have a reasonably firm API defined for XOM, 
>Elliotte? I downloaded 1.0d2 a few days ago and used it to prepare 
>some code samples for a talk I'm giving this weekend, only to find 
>that the API has already changed considerably in 1.0d3 (only a few 
>changes, but they effected about half the lines in my code samples). 
>And by the way, what does the "d" mean in the versioning?

"d" stands for development. It means the API is still open to change. 
Eventually I'll release 1.0 alpha 1 which is API freeze. Beta 1 is 
all known bugs fixed. 1.0 is all known and reported bugs fixed and no 
new bugs reported for some reasonable period of time.

>It'll be interesting to try XOM out more once the API is stable. 
>Personally I see it as closer to DOM than JDOM in usage, with 
>abstract base classes used in place of DOM's interfaces. The 
>comotose lists are a nice simplification, but with the downside that 
>a new list has to be constructed for every access call (or at least 
>the first one after any change).

Keep in mind that the primary navigation is meant to take place 
through the element itself. i.e. XOM deliberately eschews the JDOM 
style of asking the Element to give you a list of children which you 
then iterate through. Instead the primary XOM style is asking the 
element itself for its first child node, second child node, etc. If 
this is how you're accessing the data, there should be no need to 
create a new list after each mutation.

Furthermore, if you do extract a list of child elements, then the 
elements in that list are still live even if they're moved or deleted 
from the original parent. The list, in essence, is a snapshot. The 
snapshot doesn't go away just because the document changes. If you 
want to know the current state of an element, use the element itself.

>  The LGPL license also bothers me, since it's considerably more 
>restrictive than the Apache-style licensing used by JDOM and dom4j. 
>Do you care to comment on why you chose LGPL?

Because the LGPL better protects your freedom and mine. I see no use 
cases that matter to me where anyone should be significantly hindered 
by the LGPL. (Selling a proprietary, closed source product base don 
my work without paying me for it is not a use case that matters to 
me, funnily enough.) If somebody does present such a use case, I can 
always dual license or donate the code under a different license.
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo at metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|          XML in a  Nutshell, 2nd Edition (O'Reilly, 2002)          |
|              http://www.cafeconleche.org/books/xian2/              |
|  http://www.amazon.com/exec/obidos/ISBN%3D0596002920/cafeaulaitA/  |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |
+----------------------------------+---------------------------------+