Oh, I spoke too soon. From [1]: "XOM supports XInclude including the XPointer element() scheme and bare name XPointers. It does not support the XPointer xpointer() scheme." Which I guess means it's in the same boat as Xerces with respect to what's supported.
Perhaps I'm going about this the wrong way. Am I actually using XInclude correctly (based on my original example, with several files each containing a <function-set> and multiple <function> children and trying to use xinclude to compose a single file / <function-set> with all <function>s in it)? Right now it looks like XSLT may have to be the way to go after all... =\ On Wed, Feb 4, 2009 at 10:54 AM, Gareth Western <gar...@garethwestern.com> wrote: > Michael: XOM looks like it might be what I'm looking for. I originally > tried to use the old XIncluder project from sourceforge[1] until I > realised I'd probably need to use XPointers (which XIncluder does not > support either). > > Joseph: I had considered that, but the situation is already complex > enough as it is so I'd rather not introduce XSLT to what we're doing > if it can be avoided (sure, XSLT isn't _that_ complicated, but it > would add yet another ingredient to the recipe ;-)) > > Thank you both for your replies! > > Gareth > > [1] http://xincluder.sourceforge.net/ > > On Tue, Feb 3, 2009 at 10:28 PM, <kesh...@us.ibm.com> wrote: >> >>> If you need support for other kinds of XPointers then you may want to >>> take a look on the net at some of the other XInclude processors that >>> are available. e.g. perhaps XOM [4] supports what you're looking for. >> >> Another quick idea: It's possible to implement an XInclude subset as an XSLT >> stylesheet. If that approach works for you, you can use Xalan to process it. > --------------------------------------------------------------------- To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
