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: XInclude doesn't validate with xmllint

On Fri, Oct 04, 2002 at 10:16:10AM -0700, Bob Stayton wrote:
> I don't think this can be done with a DTD.
> It might be possible to model these combinations, but
> reading it would give me a headache.  8^)

Sure.  I was mostly thinking of extending the DTD syntax to allow such
things (like the thing I described for a schema syntax, except that
for DTDs I had no ideas off the top of my head)

> And what does validation mean if the xincludes are not
> first resolved?

It means that, for example, you can use standard indexing tools, that
will report the any indexed locations in the physical file and not in
the xinclude output stream.  Just something like not having to rewrite
everything just because we now use a new feature...

> It certainly doesn't mean your document conforms to the Docbook DTD,
> because any one of those includes could introduce invalid content.

That's why xinclude output also has to be validated, and that doesn't
conflict with the need to pre-validate.

> 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'll have to re-read the specs, about those ID/IDREFs issues.
Intuitively I would rather use some cross-document xpointer/whatever
instead of idrefs.

> I believe validation should include resolving xincludes
> first, the way entity references are.

The big problem with this approach is that we would be breaking the
SGML compatibility, just for "syntactic sugar".  That would look like
reinventing the wheel, once more.

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

And the "recommendation status" itself would better wait that xinclude
has seen real widespread use to eventually adjust it to the user's
needs.  Chicken, eggs...

Yann Dirson <Yann.Dirson@fr.alcove.com>                 http://www.alcove.com/
Technical support manager                Responsable de l'assistance technique
Senior Free-Software Consultant          Consultant senior en Logiciels Libres
Debian developer (dirson@debian.org)                        Développeur Debian

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

Powered by eList eXpress LLC