KHTML: Namespace handling

[Peter Kelly]

On Wed, 25 Jun 2003, David Faure wrote:

> Dirk or Peter: could someone explain to me the change in CVS HEAD relating
> to attribute and tag IDs, and namespacing?
> I see the addition of a "local name" concept in addition to prefix, namespaceURI
> (what's the difference between those 2?), and I think there's a difference in the
> way IDs are used?
> 
> This means e.g. createAttribute doesn't call createAttributeNS anymore, but
> directly calls a different AttrImpl constructor, etc.
> This is giving me a hell of time when backporting patches between the two
> branches :) - more importantly I'm not sure how to do it properly.

Essentially the problem was that we were treating nodeName and 
prefix:qualifiedName as the same thing, but according to the spec they are 
not. 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.

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. This is why we need to store the nodeName 
and uri+local name separately.

In terms of speed, we can possibly add an id -> tagName mapping for 
XML element names and local names etc. which could improve performance a 
bit.

Have a look at khtmltests/regression/tests/dom/namespaces.html with 3.1 
and HEAD to see the difference... there are a number of ways in which the 
differences manifest themselves when using various DOM methods.

> 
> In the 3.1 branch I added an XMLElementImpl( id ) constructor, to be able
> to validate the name in tagId() before creating an element. In the case of 
> the namespaceURI + qualifiedname variant I let createElementNS do the checks 
> first.
> In HEAD there's no tagId() anymore... and XMLElementImpl doesn't store
> an id at all, anymore. Hmm, then I could do the validation in createElement
> itself. But the reason I did it in tagId was to avoid doing the slow (char-per-char)
> validation on known tag names (all those already in the map). How can
> I do something similar in HEAD? It doesn't seem possible.
> 
> 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... :}
> 
> 

-- 
Peter Kelly
pmk at kde.org