[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: DOCBOOK-APPS: XInclude doesn't validate with xmllint
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC