After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 322928 - XPath expression "/." evaluated as "/*", not "/self::node()"
XPath expression "/." evaluated as "/*", not "/self::node()"
Status: RESOLVED FIXED
Product: libxml2
Classification: Platform
Component: general
2.6.22
Other All
: Normal minor
: ---
Assigned To: Daniel Veillard
libxml QA maintainers
Depends on:
Blocks:
 
 
Reported: 2005-12-01 13:45 UTC by Erich Schubert
Modified: 2006-01-10 09:40 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12



Description Erich Schubert 2005-12-01 13:45:24 UTC
Please describe the problem:
From the XPath specs:
"/ selects the document root (which is always the parent of the document
element)" and ". selects the context node"
Therefore I think that "/." should return the document itself, not the document
root element.

Steps to reproduce:
In python:
import libxml2
doc = libxml2.parseFile("foo1.xml")
ctxt = doc.xpathNewContext()
print ctxt.xpathEval("/")
[<xmlDoc (foo1.xml) object at 0x40ae1fec>]
print ctxt.xpathEval("/self::node()")
[<xmlDoc (foo1.xml) object at 0x40a8302c>]
print ctxt.xpathEval("/.")
[<xmlNode (a) object at 0x40ae872c>] <--- should be xmlDoc?
print ctxt.xpathEval("/*")
[<xmlNode (a) object at 0x40ae826c>]


Actual results:
I think the result should be the xmlDoc object

Expected results:
The root element is returned instead

Does this happen every time?
yes

Other information:
Might need an xpath expert to decide which behaviour is correct.
I tried xpathtester, a java app, and it selects the document, as expected.
Comment 1 kbuchcik 2005-12-07 14:38:47 UTC
I'm not an expert, but: the default axis 'child::' does not apply here, since
"." has its own axis, namely 'self::'. So I think this is a bug.
Comment 2 kbuchcik 2006-01-10 09:40:21 UTC
Fixed in CVS (and in Libxml2 2.6.23):
The bug was in pattern.c, which is used for a tiny subset of xpath
expression which can be evaluated in an optimized way.
The doc-node was never considered when evaluating "//" expressions.
Additionally, we fixed resolution to nodes of any type in pattern.c;
i.e. a "//." didn't work yet, as it did select only element-nodes.
Due to this issue the pushing of nodes in xpath.c needed to be
adjusted as well.
Fixed expressions like "foo//." as well.

Thanks for the report.