Jim Dixon wrote:
On Fri, 8 Sep 2006, Ross Gardler wrote:
-------------------------------------------------------------------------
<!ENTITY % local.inline "|xi:include">
<!ENTITY % document PUBLIC
"-//APACHE//ENTITIES Documentation V2.0//EN"
"document-v20.dtd">
%document;
<!ATTLIST document
xmlns:xi CDATA #FIXED "http://www.w3.org/2001/XInclude";
<!ELEMENT xi:include EMPTY>
<!ATTLIST xi:include
parse (text|xml) "xml"
href CDATA #REQUIRED
encoding CDATA #IMPLIED
-------------------------------------------------------------------------
This works for my purposes. I enable XInclusion by using this doctype
instead of document-v20.dtd.
If this were to be done as a patch, I suppose the patch would introduce
a new doctype V2.1, with the xi:include element moved into what would now
be document-v21.mod. This would be added to catalog.xcat.
I don't think we need to create a version 2.1 for this to be honest. I
know we *should* but it is an optional element that is 100% backward
compatible.
Can we just slip it in without causing any upset? Naughty I know, but I
don't have the time to do a "proper job" on this.
The exact place(s) where the xi:include element would be permitted might
be an issue to some. I would add it to link-content.mix.
I've thought about this a bit more. One of the problems here is that
adding xi:include elements has unexpected results.
If the DTD is extended as above, then the validator will, I think, not
check beyond the xi:include element, and so a document may validate
even though what is being XIncluded is nonsense. I can write
<p><xi:include href="rubbish.xml"/></p>
and validation will succeed, because the xi:include element has the
pattern required by the DTD even though rubbish.xml isn't XML at all
Good point.
The expected behavior is that the validator recognizes that what is being
XIncluded is XML (as it is by default) and goes through to validate that
as well, silently replacing the xi:include element with whatever is
XIncluded. I think that some parsers do this - perhaps only if an
option is set - but most don't.
Does Xalan do it? This is the default parser for Forrest. A healthy
warning in the docs and output of the validate task may be sufficient
for those using a different parser.
A better approach would be to process the XIncludes before validation,
stripping off the xlmns:xi attribute from the document element and
replacing xi:includes with whatever they resolve to. This should be
cheaper than it might seem: unless the xmlns:xi is present, the
document is simply handed on to the validator untouched.
I can't see an easy way of doing this as, in many cases, the included
content is generated by Forrest. In fact, this would be a problem if the
parser were doing the includes.
Ross
