> -----Original Message----- > From: Daniel Veillard [mailto:[EMAIL PROTECTED]] > Sent: Donnerstag, 26. September 2002 11:23 > To: Arno Sosna > Cc: Jirka Kosek; Bob Stayton; '[EMAIL PROTECTED]' > Subject: Re: DOCBOOK-APPS: modular docbook documents using xpointer > > > On Thu, Sep 26, 2002 at 11:08:06AM +0200, Arno Sosna wrote: > > > Because they select the top-level-included-items and what gets > > > produced in the result tree are all the subtrees under > tose selected > > > nodes. No change in semantic at the XPointer level, just a > > > misunderstanding > > > of the XInclude specification. Please read it :-) > > > http://www.w3.org/TR/xinclude/#dt-top-level-included-items > > > > so basically it means, that the error is in the syntax, not > the tool, am i > > right? > > Well in this case this doesn't seems a bug in the implementation :-) > > > which leads me back to the problem of not knowing how to do it :-) > > well, i guess back to xpath/xpointer... > > It may actually be difficult to do "filtering out" operations with > XInclude + XPointer. Seems such an operation is more easily > done further > in the processing chain for example by skipping the elements > at the XSLT > level.
well, my 'workaround' in the book-file looks like this (i think i've posted it before): <chapter> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="chapter.xml#xpointer(/chapter/*[not(descendant-or-self::chapterinfo)]) "> <xi:fallback> <para> <emphasis>chapter.xml missing.</emphasis> </para> </xi:fallback> </xi:include> </chapter> "under" the toplevel it is much easier to do filtering. it might be a not very elegant solution, but for now it suits my needs. well, thanks for your help, arno sosna