>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 
contents.

>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>
</xsl:template>

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 
XIncludes.

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)           |
|             http://www.cafeconleche.org/books/bible2/              |
|   http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |
+----------------------------------+---------------------------------+