[
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
time:
> 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
processor.
--
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
y.html
The Past, Present and Future of Web Services 1 - http://www.webservices.org/ind
ex.php/article/articleview/663/1/24/
The Past, Present and Future of Web Services 2 - 'http://www.webservices.org/in
dex.php/article/articleview/679/1/24/
Serenity through markup - http://adtmag.com/article.asp?id=6807
Tip: Using generators for XML processing - http://www-106.ibm.com/developerwork
s/xml/library/x-tipgenr.html
|
