W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2003

"Intelligent" element and attribute creation

From: Steve Schafer <steve@fenestra.com>
Date: Fri, 03 Oct 2003 11:12:06 -0400
To: www-dom@w3.org
Message-ID: <uv2rnvg15e32fafdjanedgtp6j3amb5ueb@4ax.com>

I don't know if this topic has ever been raised before--I can't seem to
find anything. I apologize for any duplication.

The addition of the Document.createElementNS() method in DOM2 allows us
to do "intelligent" creation of element objects based on the namespace
URI as well as the tag name. Using SVG as an example, if we do this:

 myDoc.createElementNS("http://www.w3.org/2000/svg", "rect")

our implementing code can search through a dictionary of known
namespaces, and instantiate an element object that "knows" how to be an
SVG <rect> element; that is, it would not only support the Element
interface, but also the SVGElement, SVGRectElement, etc. interfaces, in
a meaningful fashion.

It would be nice to be able to do the same thing with attribute objects,
but we're hampered in two respects:

1) Most attributes don't have associated namespaces, so we can't figure
out what an attribute whose name is "x," for example, is supposed to
mean. In other words, we don't have sufficient context in which to
create an appropriate "intelligent" attribute.

2) Even if our attribute does have an associated namespace, it turns out
that that still doesn't give us enough context. Within a single
namespace, there are cases where a single attribute name has different
interpretations depending on the element in which the attribute is
embedded. Once again using SVG as an example, the value of a "rotate"
attribute applied to the <tspan> element has different semantics, and
even different syntax, from a "rotate" attribute applied to the
<animateMotion> element.

Of course, such an intelligent attribute wouldn't support any additional
interfaces beyond Attr, but from an implementation point of view it
would be a Very Good Thing to be able to encapsulate an attribute's
semantics (and syntax) within the attribute object itself.

In order to achieve this ability to intelligently create attributes, it
seems that we would need methods something like the following:

   in DOMString attrName,
   in DOMString elementName)
   in DOMString attrName,
   in DOMString elementNamespaceURI, 
   in DOMString elementName)
   in DOMString attrNamespaceURI, 
   in DOMString attrName, 
   in DOMString elementName)
   in DOMString attrNamespaceURI, 
   in DOMString attrName, 
   in DOMString elementNamespaceURI, 
   in DOMString elementName)

(It seems unlikely that the third one would ever be used; so it could
probably be omitted.)

Has any thought been given to anything along these lines? It's certainly
possible to get around the problem even within the limitations of the
current DOM (by delaying instantiation of attribute objects until the
owning element's namespace URI and tag name are known, for example), but
I think methods like those listed above would constitute a cleaner

[ASIDE: All of my numerous attempts to subscribe to the www-dom mailing
list have failed miserably. I don't get any kind of acknowledgment;
nothing happens whatsoever. I can subscribe to the other W3C mailing
lists just fine, so I have no idea what the problem is. What am I

Steve Schafer
Fenestra Technologies Corp
Received on Friday, 3 October 2003 11:12:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:11 UTC