> -----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
