xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott_B...@lotus.com
Subject Re: JDOM in Apache (was Re: xml.apache.org charter proposal)
Date Wed, 04 Apr 2001 15:44:20 GMT

Andy, thanks for your comments.

Andy Clark <andyc@apache.org> wrote:
> From looking at the API for DTM, I see it's just a DOM-like API
> using integer handles instead of objects.

Yes, since I'm translating 50 zillion lines of Xalan code that traverses
the DOM, that may have influenced me.  But, given a tree model instead of
an event model, and the infoset/XQuery/XPath data model, I'm not sure what
the alternatives are.  Tree traversal is tree traversal, and can only be
done so many ways.

> However, the tree API is based largely on the needs of XSLT
> processing.

True enough.  However, I believe that the things that Xalan needs are a
very good indicator of what is needed in a general API.

> My first opinion is that I would rather not bloat a generic
> (though optimized) tree model with API based on a specific
> application's needs. And the current design seems heavily
> influenced by the needs of Xalan (to myself: duh!).

As I said, I believe those APIs are a very good indicator of what is
needed.  Transformation is a general purpose need, so I feel strongly that
"bloating" is the wrong word.  The type of operations the DTM is performing
can be best optimized close to the parser.  For instance, traversal of the
"following" or "descendant" axes can be pretty complex with getFirstChild,
getNextSibling, and getParent.  But it can be done very quickly if the
storage method is an array.

We need to look at the XML pipeline to see how to optimize it.  XSLT is an
important part of that pipeline, and the tree API should fullfill it's
needs to optimal effect.  If we can't do this, we're stuck with a Xalan
proprietary DTM, instead of a general object that can be passed through the
pipeline.  We might be able to layer this more, but then we may end up
complicating it more, and I'm not sure the layering will really be useful.

> Also it
> is influenced by an underlying character buffering model.
> Can this be avoided? Otherwise we diverge from general
> usefulness into proprietary architecture.

I'm not sure what you mean.  The bottom line is that we need some character
model, and arrays of characters are the best bet.  I don't see how this can
be avoided.  Do you have ideas on this front?

> Quick point: I noticed that setFeature overlaps with the SAX2
> name on XMLReader but does not declare that it throws any kind
> of exception. Is this an oversight? or do you consider it
> enough that the application can ask what is supported? (Note
> that there is a difference between not supporting a value
> before and during parsing.)

Possibly an oversight.  In general the exception model is supposed to be
runtime exceptions, so I think I just removed the checked exception decl.
We can work on this.


In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

View raw message