GDataXMLNode not handling default namespaces for xpath queries about gdata-objectivec-client

[GoogleCodeExporter]

Original comment by gregrobbins on 30 Jun 2009 at 1:35

• Changed state: Accepted

[GoogleCodeExporter]

Thanks for pointing out the issue and providing an alternative. You're right 
that the
library is in error in registering the empty-string prefix.

This led to some interesting discussion here about safe XPath expressions. 

While NSXML's XPath does implicitly prefix expression elements with the node's
default namespace, that is not really safe. There is no guarantee that future 
XML
will have the same default namespace, or that prefix-URI mappings will remain 
the
same.  If either of those changes, the XPath expression will give unexpected 
results.

Trying to alter the user's XPath expression is difficult to do correctly.  
Issues
like whitespace, OR operators (|'s), and other compound expressions make trying 
to
insert a prefix automatically in a reliable way quite a difficult task.

I will add to the library an XPath call which takes a dictionary explicitly 
mapping
prefixes (keys) to URIs (values), allowing for reliable XPath expressions that 
can
access nodes on the default namespace.  Using that will look like:

path = @"atom:entry/atom:link"; // four entry link nodes
dict = [NSDictionary dictionaryWithObject:kGDataNamespaceAtom
         forKey:kGDataNamespaceAtomPrefix];
nodes = [root nodesForXPath:path
                 namespaces:dict
                      error:&error];

Additionally, the plain nodesForXPath:error: method will allow _def_ns as a 
prefix
referring to the default namespace.  However, it will safer to use the XPath 
method
which takes the explicit namespace dictionary.

Original comment by gregrobbins on 2 Jul 2009 at 12:41

[GoogleCodeExporter]

Better namespace support is now in top-of-trunk GDataXMLNode.

http://code.google.com/p/gdata-objectivec-client/source/detail?r=288

Original comment by gregrobbins on 3 Jul 2009 at 1:16

• Changed state: Fixed