Altova Mailing List Archives

Re: [xml-dev] canonicalization

From: Elliotte Rusty Harold <elharo@-------.---.--->
To: Eric van der Vlist <vdv@--------.--->
Date: 3/4/2002 12:22:00 AM
>Elliotte Rusty Harold wrote:

>But isn't this difference more historical than technical?

No, it's completely technical, not at all historical. Entities don't 
have a fallback mechanism. XInclude does. It's irrelevant which one 
was defined first. The fallback mechanism makes canonicalization an 
unpredictable operation on the post-include infoset, which is exactly 
what canonicalization is trying to avoid.

>If you build an application on XInclude, you will want this inclusion
>to be as transparent as possible and the document before XInclude 
>may be meaningless, as meaningless as a XML document without its 
>external parsed entities. In both case, you can generate *a* XPath 
>data model and this data model is not appropriate in either case and 
>is not *the* XPath data model of the merged document.

That's not true.  You most certainly can build an XPath data model 
for an unmerged document that  has some xinclude:include elements. 
You cannot build such a data model for a document in which the 
external entities are not resolved. The XPath data model only applies 
to documents in which all external entities are resolved. So the two 
cases are *not* the same. Furthermore, both unmerged documents do 
have meaning. Theya re not meaningless. For instance, imagine a book 
in which the individual chapters are referenced by either XInclude or 
external entities. Even without resolving those entities this 
document may contain useful information, such as the table of 

>I wonder if we do not see external parsed entities as "more core" 
>than XInclude just because we are used to them.

It has nothing to do with them being more core (though they are) or 
how familiar we are with them. The simple fact is that the XPath data 
model on which canonicalization is based explicitly requires (section 
5.2) that external entities be resolved and implicitly requires that 
XInclude elements not be resolved.

The latter point is easiest to see in the context of XSLT. Consider 
this template rule:

<xsl:template match="xinclude:include">
   <p><xsl:value-of select="@href"/></p>

This template rule is completely unambiguous. XSLT defines exactly 
what is supposed to happen when this template matches an 
xinclude:include element. If you give me a document containing some 
xinclude:include elements, then I know how the processor is going to 
treat them. If a processor decides to do something else with the 
xinclude:include elements, then it is not conformant to XSLT. Of 
course you may also choose to give me a doucment which does not 
contain xinclude:include elements, in which case how XSLT/XPath 
handles it is equally unambiguous. Perhaps this document was 
generated from a document that did have XIncludes, perhaps it wasn't. 
Either way it is *not* the same document as one that does contain 

A lot of the confusion comes from wanting to treat xinclude:include 
elements as some magical thing that does not satisfy all the usual 
rules of XML processing, but that isn't true. An xinclude:include 
element is just like any other XML element which some processes may 
choose to impart certain semantics to. Most likely, these semantics 
will result in the production of a new and different document, but 
they don't have to; and in some cases they won't.


| Elliotte Rusty Harold | elharo@m... | Writer/Programmer |
|          The XML Bible, 2nd Edition (Hungry Minds, 2001)           |
|                 |
|   |
|  Read Cafe au Lait for Java News:      |
|  Read Cafe con Leche for XML News:    |


These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.