[
Lists Home |
Date Index |
Thread Index
]
At 11:11 AM +0100 3/4/02, Eric van der Vlist wrote:
>But this is also the case with external parsed entities since a non
>validating parser may not parse them. And beside this case, I
>strongly feel that any reference to any document introduces
>unpredictability, especially when it's over the internet and
>especially when there is no fallback mechanism.
You cannot a use a parser that does not resolve external entity
references for XPath and XPath based applications. Given that all
XPath sufficient parsers do resolve external entity references,
canonicalization either succeeds completely or fail completely. There
is no middle ground. XInclude has a middle ground, quite a lot of
them in fact. That's what makes it unpredictable.
>Why not? If I parse a XML 1.0 document with a non validating parser
>which doesn't parse external entities and if the result is still
>conform to namespace in XML I don't see why a XPath data model
>couldn't be built. It might not be significant but it would still be
>a XPath data model...
>
The result won't be conformant to XPath except in the uninteresting
case where the document doesn't contain any external entity
references. The XPath data model does not include any representation
of unexpanded entity references (or any other kind for that matter).
>It happens that XPath specifies that those external entities need to
>be expanded and you are (of course) right, but I do think that this
>is historical too.
No, it's not. It was a deliberate decision by the XSL Working Group
and the XML Linking Working Group. XPath followed XML by almost two
years, and the groups had full knowledge of what they were doing.
They chose to make XPath require resolution of external entity
references.
>OTH, what's the use of XInclude if it cannot become core and
>transparent for the applications. We already have XLink to indicate
>"soft inclusions" and I don't see any use for XInclude if it doesn't
>become a hard (or core) inclusion like external parsed entities.
>
But XLink *doesn't* indicate soft inclusions. It did at one point in
time, but that was ruled out of scope and moved into XInclude a
couple of years ago. There is no standard way in XLink to indicate
that resource should be merged into the result document's infoset.
You can indicate that a document can be graphically embedded (like an
IMG link in HTML) but that's a very different thing. It does not
affect the result document's infoset. XInclude does.
The fact is XInclude is not what you want it to be and does not do
what you want it to do. What you want would probably require breaking
the definition of XML 1.0. You want to redefine what an element means
and how it is treated by all processes, provided that the element's
name is xinclude:include. That doesn't seem likely to happen.
--
+-----------------------+------------------------+-------------------+
| 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/ |
+----------------------------------+---------------------------------+
|
