Re: DOCBOOK-APPS: XInclude doesn't validate with xmllint

[Bob Stayton <bobs at caldera dot com>]

On Fri, Oct 04, 2002 at 12:28:29PM +0200, Yann Dirson wrote:
> On Fri, Oct 04, 2002 at 05:52:05AM -0400, Daniel Veillard wrote:
> > On Wed, Oct 02, 2002 at 09:49:09PM -0700, Bob Stayton wrote:
> > > I started to extend the DocBook DTD to permit xi:include,
> > > but I think it is kind of impossible (except for maybe
> > > Norm 8^).  The xi:include element can replace *any*
> > > element or group of elements, so the content models of
> > > every element would get hopelessly complex.
> > 
> >   The more I think about it, the more I'm convinced that
> > in general, validation should occur after XInclude processing.
> 
> IIRC that would not meet the definition of "validity" for an XML
> document, or am I wrong ?
> 
> 
> >   But allowing an extra attribute everywhere is quite simpler
> > than allowing an extra element everywhere :-)
> 
> "everywhere" is probably too strong, i bet noone wants to use this for
> inline elements.
> 
> Maybe what's needed would be some sort of "allow element X whereever
> this element is allowed" clause in the DTD/schema.
> In a schema we could just have on element definitions a NMTOKENS or
> IDREFS attribute with these semantics.

I don't think this can be done with a DTD.
The hard cases are where an xinclude is replacing some
arbitrary structure of elements within a parent element.
The parent's content model has to be able to handle
the structure as well as a single empty replacement xinclude.
It creates some complicated "or" structures.

Try modelling these examples in a chapter element
declaration:

<chapter>
 <xi:include href="AllChapterContent"/>
</chapter>

<chapter>
 <title>My title</title>
 <xi:include href="AllExceptTitle"/>
</chapter>

<chapter>
 <xi:include href="ChapterInfo"/>
 <title>My title</title>
 <xi:include href="ExceptTitleAndInfo"/>
</chapter>

<chapter>
 <title>My title</title>
 <sect1>
    ...
 </sect1>
 <xi:include href="ThisSect1">
 <sect1>
   ...
 <sect1>
</chapter>

It might be possible to model these combinations, but
reading it would give me a headache.  8^)

And what does validation mean if the xincludes are not
first resolved?  It certainly doesn't mean your document
conforms to the Docbook DTD, because any one of those
includes could introduce invalid content.  And there is the
issue of hidden IDs.  If an IDREF is referring to an ID
that resides in an xinclude, the validator won't find it
unless it resolves the xincludes.

I believe validation should include resolving xincludes
first, the way entity references are.  Only then will you
know if you have a valid document.  I believe validation
tools (including validating editors) must be updated
to resolve xincludes.  That probably won't happen until
the XInclude spec reaches final Recommendation status,
though.


Bob Stayton                                 400 Encinal Street
Publications Architect                      Santa Cruz, CA  95060
Technical Publications                      voice: (831) 427-7796
Caldera International, Inc.                 fax:   (831) 429-1887
                                            email: bobs@caldera.com