XOM API for Processing XML with Java

[Elliotte Rusty Harold <elharo AT metalab.unc.edu>]

At 10:55 PM +0200 10/13/03, Hallvard Trætteberg wrote:


> This can also be viewed the other way around: Instead of providing the
> Builder when XIncluding, why not provide the XInclude strategy when
> Building?

I've thought about doing this, possibly by 
layering on top of Xerces's XInclude support. 
However, I don't want to limit XInclude support 
to just the building phase. It should be possible 
to resolve XIncludes on a document in memory.

>  In other words, a Builder may be configured to automatically
> XInclude upon finding an XInclude element (the Builder would pass (a
> copy of) itself to the XIncluder). In most cases (except parse="text")
> it should make sense to pass the same (or a copy) Builder. Isn't this
> three liner beautiful:
>
> Builder builder = new Builder();
> builder.setXInclude(true);
> builder.build(uri);

I was thinking of doing it as a subclass, but 
you're right. It might make more sense as just an 
option on the current Builder class.

> I think it should be possible to do this after completing an element
> (after finishElement is called) (isn't the crucial point that XInclude
> needs a base URI), it shouldn't matter that sibling elements aren't
> finished as long as the parent chain is?

In other words, use an XIncluding NodeFactory. 
It's possible. However, any streaming solution 
really end sup mucking with the XPointers. When 
XPointers are considered this implementing 
XInclude is a lot tougher on top of a streaming 
API. It's much easier if you can afford to stick 
everything in memory first.
--

  Elliotte Rusty Harold
  elharo AT metalab.unc.edu
  Processing XML with Java (Addison-Wesley, 2002)
  http://www.cafeconleche.org/books/xmljava
  http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA