Bob Stayton <[EMAIL PROTECTED]> 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

Reply via email to