It's not quite so simple. You basically need to write your own XInclude processor to "fetch the referenced documents", resolve XPointers, fallbacks, etc... if you were going to go that route.
Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrgla...@ca.ibm.com E-mail: mrgla...@apache.org kesh...@us.ibm.com wrote on 09/16/2009 12:40:24 PM: > Parse without XInclude processing, walk the tree to find the > XIncludes, fetch the referenced documents and attach them to the > include element? > > ______________________________________ > "... Three things see no end: A loop with exit code done wrong, > A semaphore untested, And the change that comes along. ..." > -- "Threes" Rev 1.1 - Duane Elms / Leslie Fish (http://www.ovff. > org/pegasus/songs/threes-rev-11.html) > > Mark Brucks <bru...@charter.net> wrote on 09/16/2009 12:22:41 PM: > > > Mark Brucks <bru...@charter.net> > > 09/16/2009 12:22 PM > > > > Please respond to > > j-users@xerces.apache.org > > > > To > > > > j-users@xerces.apache.org > > > > cc > > > > Subject > > > > xml include > > > > I would like to know which elements in a document exist as a result of > > XInclude processing and I need to retrieve the original <include> > > element so that I have access to the entire set of attributes. > > > > My only solution, which I don't like, involves parsing the document > > twice. The first parse sets the xinclude feature of the DOMParser > > (actually, of the underlying XIncludeAwareParserConfiguration), the > > second parse has that feature turned off. The second parse creates a > > DOM node for the <include> element. The two DOM instances can be > > compared to find the nodes in the first parse that correspond to > > <include> elements in the second parse. > > > > Is there a better way? > > > > Thanks - Mark > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org > > For additional commands, e-mail: j-users-h...@xerces.apache.org
