OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] Effective DOM (was RE: [xml-dev] Effective XML)

[ Lists Home | Date Index | Thread Index ]

>   Nice, but let's change "Java" to "native", where native is defined
> by the language being used.  ;-)  

Oh, ok if you must :)

>   Yes!  This in particular is a sore point for me.  I'm able to do it
> in Python, but I have to know which DOM implementation I'm using so I
> can do the right magic for the implementation.  

Well my helper routine just makes it *appear* as if the element is being 
renamed. In fact a new element is created, and the children of the 
original element moved over. Probably not very efficient, but it was 
good enough at the time.

> A helper routine does help, but doesn't give a "good feeling".  The reason for not allowing
> tagName to be changed has been explained to me (that an implementation
> may use different classes to implement different elements), but
> doesn't seem sufficient (allowing tagName to be mutable or throw some
> exception may be tolerable, and being able to ask the DOM
> implementation if it allows general element renaming would be useful.

I wasn't aware of that. Interesting. Presumably this is to allow custom 
DOM implementations (e.g. for SVG) to substitute their own implementations?
Is this feature used in practice?

Seems like there are various ways this functionality could be retained, but 
still allow renaming to take place. Worse case scenario is that a rename ends up 
creating a new kind of object, but this could still be transparently handled by 
the DOM impl I think.

Thinking about it, if this feature *is* to allow different classes for differently named 
elements, then presumably this is to allow these classes to have additional 
behaviour. You're going to need a cast or similar to get an alternate reference, 
so this could be handled just as well by delegation I think. Or have I gone all 
Java-centric again :)




News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS