Bug 22265 - Inconsistent handling of empty versus nil NSStrings for namespaceURI
Summary: Inconsistent handling of empty versus nil NSStrings for namespaceURI
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit API (show other bugs)
Version: 528+ (Nightly build)
Hardware: Macintosh OS X 10.5
: P2 Normal
Assignee: Nobody
Keywords: InRadar
Depends on:
Reported: 2008-11-14 08:46 PST by Kai Brüning
Modified: 2009-04-10 23:17 PDT (History)
4 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Kai Brüning 2008-11-14 08:46:35 PST
-[DOMNode namespaceURI] returns an empty NSString (@"") for "no namespace".
But -[DOMNameNodeMap getNamedItemNS:localName:] does find an attribute without namespace only if nil is passed for the namespaceURI.

The DOM3-Core specification states: "In programming languages where empty strings can be differentiated from null, empty strings, when given as a namespace URI, are converted to null. This is true even though the DOM does no lexical checking of URIs." (1.3.3 XML Namespaces, page 27 in the pdf version).
Therefore it would probably be correct, if -[DOMNameNodeMap getNamedItemNS:localName:] converts an empty namespaceURI string to nil before performing the lookup.

Further, the same spec states about the namespaceURI property of interface Node: "The namespace URI [p.207] of this node, or null if it is unspecified (see XML  Namespaces [p.26] ). " (page 61 of the pdf version).
Therefore -[DOMNode namespaceURI] should probably return nil instead of @"" for "no namespace".

Note: the C++ node actually has a NULL value for the namespaceURI string in this case. The conversion to @"" happens deep in the conversion code from WebCore string to NSString.
Comment 1 Mark Rowe (bdash) 2008-11-14 15:58:53 PST