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:

We've played this game before.  You still don't have a case.  Briefly, this 

>  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].

This says nothing that proscribes processing of the tree between parsing and 
XPath processing.  It doesn't even mention parsing.

> 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.

I am not interested in your exegeses.  You claim you are providing normative 
posts in specs that prove that pre-XPath processing is illegal.  Your 
additions are therefore moot.  (That's moot in the US Law sense, as defined by 
SOED, if Mike Kay is listening ;-) )

>  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.

Again, nothing about post-parse processing, as long as the result meets this 
data model.

[SNIP exegesis]

> 5.2 Element Nodes
> There is an element node for every element in the document.

Again, nothing about post-parse processing.  The "document" is not defined as 
the serialization.  It could be any XML form, including an internal processor 
representation, as long as it matches, or is converted to the XPath data model 
for XPath processing.

> 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].

Again, any non-serialized representation can have a tag.  DOM, for that 
matter, has a tag, which can be changed between loading and handing off to an 
XPath processor.

> Aha! It's not OK to change all the element names to Ethel.

I'll really hate myself for being drawn into this reduction, but I see no 
reason why not:

1) Use DOM load/save to read document
2) Run DOM ops that change all element names to whatever you like
3) pass DOM tree to XPath processor

I will say no more on this "Ethel" business.

> 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

Nope.  As I said, the tags are not identified as purely the tags from any 
particular serialized XML document.  A document that has been run through an 
XInclude process sometimes has a different set of tags, and there is nothing 
to proscribe this from beign the document that gets submitted to the XPath 

Uche Ogbuji                                    Fourthought, Inc.
http://uche.ogbuji.net    http://4Suite.org    http://fourthought.com
Python&XML column: 2. Introducing PyXML - http://www.xml.com/pub/a/2002/09/25/p
The Past, Present and Future of Web Services 1 - http://www.webservices.org/ind
The Past, Present and Future of Web Services 2 - 'http://www.webservices.org/in
Serenity through markup - http://adtmag.com/article.asp?id=6807
Tip: Using generators for XML processing - http://www-106.ibm.com/developerwork


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

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