RE: [xml] Best way to add XInclude to existing DTD?

Thank you for your interest in XInclude, I think it has a lot of obvious

I haven't cross-posted to docbook-apps or xml-doc yet (I tossed a coin to
decide where to start). Anyway, I only know (have only tried) two XInclude
implementations: the libxml one, and the 4Suite one, so I betted on XInclude
knowledge being better represented here.

The trouble with using external parsed entities is that they cannot easily
be edited without further fuss because they are not by themselves valid
instances. I know how to get around this with emacs+psgml, but I'd like to
have a solution that also worked with other editors. Besides, if you keep
xpointer or a decent subset of xpointer in the XInclude recommandation,
there are some nifty applications that involve cherry-picking nodes in the
target instance.

The proper way to specialize or extend the DocBook DTD would of course be to
write a driver DTD and give it a FPI. But I wanted to present a
self-contained example -- and besides, it's a bit easier to tweak things
using the internal subset while investigating an idea.

I like using SGML Open catalogs (in fact the reason that I first began using
xsltproc). I havn't tried the XML Catalogs yet; will do. I still have to
maintain SGML Open catalogs, 'cause that what most editors and applications
use today. I can't remember why I put in the system id with a path; maybe
because I'm also now experimenting with displaying XML documents as is (with
a CSS) in IE5.5 or IE6, and thus have to provide a system URI that actually
resolves into something. Yes, I'm spending most of my time on a Win2K box,
but using cygwin, I can pretty much ignore that.

I'll post a bug. There's also a small issue with a missing (time_t) type
cast in one of the libxslt files that shows up when compiling on cygwin;
I'll have to dig for that one. 

Kind regards,
Peter Ring

-----Original Message-----
From: Daniel Veillard
To: Peter Ring
Cc: 'xml gnome org'
Sent: 9/21/01 11:34 PM
Subject: Re: [xml] Best way to add XInclude to existing DTD?

On Thu, Sep 20, 2001 at 02:31:07PM +0200, Peter Ring wrote:
  I'm a bit late replying, I'm busy with other stuff and this raises
a few interestng but complex questions !

I'm investigating XInclude as a way to compile a number of separately
maintained DocBook XML documents into one document for publication.


  Well people usually use external parsed entities for this, that's the
canonical way to do this. In general your question would also be
suitable for the docbook-apps mailing list at OASIS.

I wonder what might be the most kosher way to add the necessary
<include > href="..."> element to DocBook?

  I'm always a bit reluctant about extending the DTD from the internal
subset. It is correct but makes the document different, this should work
in this case but is IMHO looking for troubles on the long term.
<pedantic>using a local file path for the SystemID is not fantastic, I would
suggest you investigate XML Catalogs (see my previous posts on this
subject) and keep the canonical URI for docbookx.dtd</pedantic>

    <title>A section</title> 
    <para>Some introductory remarks</para>
    <xi:include href="included.xml#xpointer(/section)"/>

  XInclude is not yet a Recommendation. One of the most controversial
points of the current draft is the reuse of XPointer. I like to see this
used but in all fairness I have to note that this is subject to
reexamination by the XML Core Working Group. I think we will keep this but

I've added the XInclude namespace declaration as a #FIXED attribute to
<section>, and added <xi:include> to the content model of
which was as close as I could easily get to <section>. 

  Yes this in theory should work. But as you noted this may be pushing
the limits of libxml namespaces+DTD compatibility a bit too far.

This works well with editors and with libxml/libxslt (2.4.5/1.0.4)
that it does not validate with xmllint (using libxml version 20405).
validation, xmllint wants "include" rather than "xi:include":

  This really sounds like a bug, I'm really sorry I didn't had time
to look at it yet. Will do, if you register it on
you will be sure I won't forget :-)


  A bug very probably.
I very much like the spirit of your attempt, it is an interesting
Another way in the libxml framework to make sure the included entities
are valid is to use the
  xmllint --dtdvalid /usr/share/sgml/docbook/xml-dtd-4.1.2/docbookx.dtd
"a posteriori" validation. It's more tied in some sense to libxml but 
do not rely on XInclude and XPointer.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]