KHTML: Namespace handling

[Dirk Mueller]

On Mit, 25 Jun 2003, Peter Kelly wrote:

> Essentially the problem was that we were treating nodeName and 
> prefix:qualifiedName as the same thing, but according to the spec they are 
> not.

No we didn't. 

> According to the spec, methods like getAttribute() are only supposed 
> to look at the nodeName of each element, whereas getAttributeNS() looks at 
> the namespace URI and local name.

correct. In XML with namespaces, the "URI+local name" is an universial 
identifier. There is the extra step of "prefix" -> URI mapping, which is 
done during parsing depending on rather complex inheritance rules. There is 
no unique mapping required, that means multiple different prefixes can 
resolve into the same URL, and they will be the same element in XML (with 
other words, its not the prefix string that makes the difference, its the 
url it is associated with). 

> If for example you have elements in two different namespaces but the same 
> local name, getAttribute() should match both of them. With the old code, 
> because the id mapping was based on namespace URI + local name 
> combination, and getAttribute() did a search based on id comparison, it 
> would only match one of these. 

Nope, thats wrong. While there was certainly a few bugs in the 
implementation, searching by ID is enough. the non-NS variants of the 
methods were masking out the namespace part, so that they would match ids 
with same local name but different namespaces. Thats what the IdMask code 
was for btw. In case we have to do the matching in the non-NS variants based 
on the nodeName (i.e. the literal prefix:localname string), that would have 
been easily fixable with the old code as well, however I seem to remember 
that this wasn't the case with Mozilla by the time I did the old 
implementation. Maybe it has changed now. 

Of course this is only a small part of the truth. A big part of the headache 
is produced by the different case sensitivity / uppercase requiremnts of 
HTML, XHtml and XML, and this is where the new implementation still lags 
behind. 

> > It looks to me like the new code isn't as fast as the one in the branch...
> > So before I spend more time on the new code I'd like to be 100% sure it's 
> > going to stay... :}

I don't see a reason for it to stay. I started reverting the rewrite and 
fixing the regression test but I ran out of time a few months ago. I still 
have it around, so unless there is the big piece in the picture I didn't see 
yet that made the old code so fundamentally flawed I'd very much prefer to 
readd the old implementation when it passes the regression test Peter added 
to khtmltests. 


-- 
Dirk