[
Lists Home |
Date Index |
Thread Index
]
At 10:14 AM -0700 10/27/02, Uche Ogbuji wrote:
>And yet you are unable to produce evidence strong enough to knock down even
>the straw man of your own devising, never mind a more preactical issue of
>order of XInclude processing.
OK, since you asked for it, here are some of the sections of XPath
and XSLT specs which I think only make sense if you understand the
input tree to have a direct connection to the actual XML document:
From section 5:
XPath operates on an XML document as a tree. This section describes
how XPath models an XML document as a tree. This model is conceptual
only and does not mandate any particular implementation. The
relationship of this model to the XML Information Set [XML Infoset]
is described in [B XML Information Set Mapping].
Exegesis: the XPath operates on an XML document. It does not operate
on something that is not an XML document. It operates on it "as a
tree". It does not operate on a tree. It just looks at the XML
document in that fashion. The document is preeminent, not the tree.
From section 5.1
The root node is the root of the tree. A root node does not occur
except as the root of the tree. The element node for the document
element is a child of the root node. The root node also has as
children processing instruction and comment nodes for processing
instructions and comments that occur in the prolog and after the end
of the document element.
Exegesis: Whatever transformations you apply before doing what the
user asked for, the root node still needs to have child nodes for
each processing instruction and comment in the actual document. This
doesn't say they have to stay in the same order, but at least they
have to be there.
5.2 Element Nodes
There is an element node for every element in the document.
Exegesis: very important. There is an element node for every element
in the document. This doesn't say there aren't any others, but there
has to be one for each. You can't just start throwing away elements.
And then in the next sentence we find:
An element node has an expanded-name computed by expanding the QName
of the element specified in the tag in accordance with the XML
Namespaces Recommendation [XML Names].
Aha! It's not OK to change all the element names to Ethel. The names
of the element nodes have to match the names from the tags. That
means there has to be an element node for each xinclude:include
element and it has to have an expanded name with the local part
include and the namespace name http://www.w3.org/2001/XInclude
I could continue, but I think this last point is definitive. The
names of the element nodes in the data model have to match the names
of the tags in the document itself. You can't change those without
changing the document.
--
+-----------------------+------------------------+-------------------+
| 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/ |
+----------------------------------+---------------------------------+
|
