Re: DOM - odd absent interface method?

If I had to do this, I would write a utility subroutine that calls known 
proprietary functions if they are available and otherwise manually 
reconstructs the node as has been described.

The alternative for a standard would have to be a very optional feature, 
identified by feature string and not implementable by probably any 
browsers and a number of other implementations with similar derived DOM 
interfaces, presentations, or processing, which may rely on the name and 
namespaceURI for instantiation of the appropriate class.  In that case, 
I think you still need a utility subroutine that manually reconstructs 
the node if the feature is not implemented.

More problematic still is the mutation events that applications may rely 
on, that face completely new unexpected behaviors if the type of the 
element can change.  If you still deliver the events they expect, then 
the work is about the same as if you had removed and reinserted the 
node.  If you do not, then this type of monitoring application would not 
want to permit this type of thing to occur in its hierarchy.

How could an application prevent this from occuring when it breaks its 
processing model, if the standard allowed it?

There are other new cases it introduces, like now an attribute node may 
be a duplicate, now an entity reference may reference a different 
entity, now an element may have different default attributes, etc.

I much prefer having them immutable for a vast majority of use cases I 
have seen, and do not like the impact on these use cases if it were 
permitted by the standard to be mutable.  To me, changing the tag name 
is like changing the type of an object in an OO language.  It seems more 
natural to construct a replacement.

Ray Whitmer
rayw@netscape.com

Fred L. Drake, Jr. wrote:

> Joseph Kesselman writes:
>  > The nodeName (together with the namespace URI) indicates the semantic role
>  > this node is playing in the document, and different names even of the same
>  > node type may reflect different subclassing of the node. Look at the HTML
>  > DOM for plenty of examples; some Element nodes carry methods that others
>  > may not. Other DOMs may implement similar role-specific extensions. Since
>  > you can't change an object's class once it has been created (in most
>  > languages), we really can't promise that you can change the semantic role
>  > after the object has been created -- and hence both nodeName and
>  > namespaceURI are immutable.
> 
>   I understand the intention here, but being able to change either the
> tagName or the namespaceURI (or both) can be incredibly useful for all
> kinds of data conversions.  This is especially useful if some of the
> operations needed just don't make sense in XSLT, so you're working
> from a programming language anyway.
>   My primary example for this is a document conversion project in
> which I'm converting LaTeX documents in XML -- the paragraph marking
> is done very differently in LaTeX (no tags), and while XSLT *may* be
> able to do the right thing, I'm firmly convinced it would take me a
> year to figure it out (since I'm not an XSLT guru).  So for the
> tagName changes I need to make, it's by far easiest to just change the
> name.  I can use implementation-specific extensions to do so, but I've
> already had to change implementations once (and make changes all over
> my code to support the new way of changing tagName).  I'd love to see
> a standard way to do it, and could accept that some DOMs will have to
> raise an exception (NO_MODIFICATION_ALLOWED would suffice).
> 
>  > >If you're passing a node to a subroutine to have it filled
>  > 
>  > If you need to set the node's name/type: Don't. Instead, pass the Document
>  > node into the subroutine, and have the subroutine use the Document's
>  > factory methods create and return a new Node object of the appropriate type
>  > and with the appropriate name.
> 
>   This only works in the case of creating new nodes; it can be very
> expensive to create a new node, migrate children & attribute nodes of
> the original, and the replace the original with the new node.  It also
> makes the code more difficult to read and maintain.
> 
> 
>   -Fred
>

Received on Monday, 21 May 2001 17:04:25 UTC