[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: DOCBOOK-APPS: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC