Re: "Intelligent" element and attribute creation

On Mon, 06 Oct 2003 17:07:32 +0200, Robin Berjon
<robin.berjon@expway.fr> wrote:

>That's an extreme take that doesn't represent my point of view.

Of course. Merely hyperbole to make my point. :)

>If you step back and look at all the things that one can do with a DOM,
>it becomes obvious that a *lot* can be added. But that would lead to an
>API bloated beyond all recognition.

The converse argument is that if there isn't enough power in the
off-the-shelf DOM, every implementor will have to include non-standard
(and generally incompatible) extensions. In my own work, I have to use
three different DOM implementations in different circumstances. A very
significant amount of time is spent fiddling with code so that it works
with all three.

>Hmmm, there's no 1.1.12 in the June WD of DOM 3 did you mean 1.3.3 and/or 1.3.5 
>and/or 1.3.6?

Yes, sorry, I meant 1.3.5. I was looking at an older PDF that had the
same text under 1.1.12.

>Do you want to "force" users to use your proposed extensions?

No, of course not. No more than they are forced to use the
namespace-aware methods even when dealing with namespace-aware XML
files. In fact, a generic DOM implementation would simply ignore the
element context and pass control to the appropriate createAttribute or
createAttributeNS method.

>Either way, what I said holds for setAttribute(). Using this approach, when 
>setAttribute{NS} (and its variants) is called, you have full context.

Assuming you leave it up to the element to instantiate the proper
attribute. However, the DOM has an alternative point of view as well:

 myElement.setAttributeNode(Document.createAttribute(...));
 myElement.setAttributeNodeNS(Document.createAttributeNS(...));

Here, there is no implicit element context, and it is under this
scenario that my proposal would be applicable.

Steve Schafer
Fenestra Technologies Corp
http://www.fenestra.com/

Received on Monday, 6 October 2003 12:49:18 UTC