[
Lists Home |
Date Index |
Thread Index
]
Another tricky bit about using XPaths on post-included documents is
that you can get very different documents depending not only on
whether the XIncludes are resolved but how the different fallbacks
play out. The most obvious case is something like //chapter[1] which
could select different chapters depending on which includes got
resolved or not. Furthermore, they're a lot of XPath functions like
string() or number() that take a node-set as an argument, but really
only operate on the first node in that set, so which node is first
can be very important, even if you don't see an explicit positional
dependence.
I also suspect the following, sibling, following-sibling, and
preceding-sibling axes could well give significantly different
results depending on which includes got resolved and which didn't. I
don't think the ancestor, child, descendant, self, attribute,
namespace etc. axes would be affected.
We're not just dealing with the question of whether or when to
perform XIncludes. It's a question of the results of performing them.
With fallbacks, it's no longer a binary success or failure operation.
--
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| XML in a Nutshell, 2nd Edition (O'Reilly, 2002) |
| http://www.cafeconleche.org/books/xian2/ |
| http://www.amazon.com/exec/obidos/ISBN%3D0596002920/cafeaulaitA/ |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.cafeconleche.org/ |
+----------------------------------+---------------------------------+
|
