OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: DOCBOOK-APPS: Including Fragments of other DocBook Documents


On Wed, Jun 19, 2002 at 09:59:13AM -0700, Bob Stayton wrote:
> On Wed, Jun 19, 2002 at 04:35:12PM +0100, Sagar.Shah@ubsw.com wrote:
> > >From: Paul Grosso [mailto:pgrosso@arbortext.com]
> > >This is interesting to me.  Can you please tell us what tool(s) you
> > >are using that have implemented XInclude?   (The W3C XML Core WG is
> > >still looking for XInclude implementation experience, and it was not
> > >clear to me that there was any great amount of XInclude support out
> > >there yet, so any information would be of value.)

  Seems I really have to post at this point :-)

> > I don't know how mature it is, but the Xinlcude support in
> > libxslt and libxml2 works great for me :-)
> 
> I'm also using xincludes with xsltproc with good success.
> To do so, you just add --xinclude to your xsltproc command line.

  As I posted on the XInclude comment list, I know that there are
users of the XInclude support of libxml2 within the DocBook community.
I also know that XInclude usage of XPointer constructs is relatively
simple in that context, the goal being to include either full documents
or simply a subpart of it.

> I've kept my xinclude usage simple: a master book document
> that contains just a sequence of <xi:include> elements to
> pull in the chapter files.  Many people set up their
> books using external entities this way.  The advantage of
> xincludes is that each chapter file can be a complete XML
> document with DOCTYPE declaration.  That means chapter files
> can be loaded into an XML editor and validated individually
> without doing DOCTYPE tricks.

  I reported your feedback on this point.

> With a simple book file like this, I never have to load my
> book document into my XML editor, where it would complain
> about the DTD not declaring <xi:include> elements.  I did
> try creating a DTD customization, but decided I didn't need
> it with this simple setup.  I just make sure my individual
> chapter files are valid.
> 
> xsltproc supports xincluding part of a document using the #id
> syntax to locate an element by id.  I tried some other
> XPointer syntax, but couldn't get it to work.  I also tried
> using nested xincludes, but the internal ones were not
> 'included'.

  hum those would be bugs then. The XPointer support of libxml2
is apparently one of the most advanced implementation, and though
it's not as fully debugged as other parts of the library most of it
should be implemented and work. This includes of course full XPath
expressions and range support.

> To validate my book, I use xmllint, which is included
> with xsltproc:
> 
> xmllint --xinclude --postvalid --noout book.xml
> 
> I've run into situations where I wanted to process my
> content with tools that don't support xinclude.  For those
> situations, I preprocess my book file to resolve the
> xincludes first. I use xsltproc --xinclude and a trivial
> XSL stylesheet that outputs all elements and attributes.
> Then I run the results through the other processor.

  another method could be to simply collect the result of
xmllint --xinclude book.xml and give that to the other XSLT
processor, since DTD informations will be kept attribute defaulting
and such will be handled by that processor. You shouldn't need 2
pass of XSLT :-)

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC