GNOME.org
 

Re: [xml] XPath partially not working on doc built from xmlParseFile

On Fri, Feb 22, 2002 at 03:22:01PM -0700, Guy Finney wrote:

The app also reads an XHTML file from disk with xmlParseFile(). Some
XPath expressions return the expected nodeset results, but others don't.
For example, "//*" or "/descendant::*" returns a nodeset with everything
from the doc built from the file, "/*" returns <html>, and
"/child::*/child::*" returns <head> and <body>. But any element
reference fails - for example, "//input" or "/descendant::table" returns
zero nodes.


  I guess I know what it is and it's not an libxml but a misunderstanding 
of one of the dark corners of the XPath spec:
  XHTML means default namespace is defined.

If you look at the XPath spec you will see taht a node like

   <foo xmlns="bar"/>

will not match //foo because it holds a namespace and //foo will only
match non-qualified namespaces.


I'm baffled by this behavior and at a loss as to how to go about
debugging it. The only two differences I can see between the two docs
are that one is build by hand while the other comes out of
xmlParseFile(), and that the misbehaving doc is (well-formed) html (from
htmltidy).


  yes with the default namespace defined on the top node I bet
(or inherited from the DTD).
  But the nodes built from scratch don't have the default namespace
defined, right ? that explains the difference in behaviour.

  To avoid that you would have to define the XHTML namespace in your
XPath context (there is an API to do it) and query //xhtml:body .
or something as nasty as 
  //*[local-name()='body' and namespace-uri()='http://www.w3.org/i_dont_remember']

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard redhat com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]