OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] ANN: xpath1() scheme for XPointer

[ 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/    |


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS