[
Lists Home |
Date Index |
Thread Index
]
>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@metalab.unc.edu | 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/ |
+----------------------------------+---------------------------------+
|
