This is the mail archive of the docbook-apps@lists.oasis-open.org mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: XInclude doesn't validate with xmllint


Bob Stayton <bobs@caldera.com> writes:

> It isn't that we (the DocBook Technical Committee) don't
> want to add an xinclude element, or that we think it is 
> not needed.  It would be easy to add an xinclude
> element to the DTD.  But that isn't enough, because
> the xinclude element must appear
> in content models for it to be useful.

[...]

> Maybe certain common cases could be added.
> Take the relative simple case of the book element.
> It's content model could be amended to look like this:
> 
> <!ELEMENT book %ho; ((%div.title.content;)?, bookinfo?,
>  		(dedication | toc | lot
>  		| glossary | bibliography | preface
> 		| %chapter.class; | reference | part
> 		| %article.class;
>             --> | xinclude
>  		| %appendix.class;
> 		| %index.class;
> 		| colophon)*)
> 		%ubiq.inclusion;>
> 
> This addition would make
> it possible to put chapters, bibliographies, appendices,
> and such components into separate xincluded files,
> and the book document would still validate.
> But no matter what cases are added, someone will want
> to use xinclude in other cases.

Right. I don't think we should make any changes to the DTD at all to try
to support XInclude -- even to support the common XInclude use cases.

I think that XInclude support should strictly be something for tool
developers/vendors to implement. Users should reasonably expect to be
able to use XInclude regardless of what DTD or schema they use.

[...]

> Consider also that xincludes are very much like system
> entity references.  A system entity reference can replace
> just about any content in a document. And everyone seems to
> accept the fact that the document cannot be validated until
> the system entities are resolved.  Validating XML editors
> must be able to resolve system entities to be truly
> validating. Why not extend that mechanism to resolve
> xincludes?

Exactly. PSGML already supports "split documents" -- inclusions of child
documents through external entity references. It could be enhanced to
support the XInclude inclusion syntax as well.

> It seems that the hard part has already been
> done, now they just need to handle some different syntax
> for specifying the included text.

I think there is one important difference: a document included via a an
external entity reference can't contain its own internal DTD subset, but
a document included via XInclude might. So, any XInclude processor will
need to read that internal subset and deal with any entity definitions
in it -- because it's possible that the document instance might contain
entities that are defined only in its own subset.

> So lobby your tool author to get them to support xinclude
> the way they support system entities.

fwiw, I filed a PSGML enhancement request:

  http://sourceforge.net/tracker/index.php?func=detail&aid=648481&group_id=9156&atid=359156

I find myself wishing I knew enough lisp to make fixes to psgml myself.
Then I consider it more and find myself thinking that what I'd really
like to have is an open-source option for editing XML that wasn't based
on Emacs-- something as powerful as psgml but that wasn't, well, Emacs.

  --Mike


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]