- From: Steve Schafer <steve@fenestra.com>
- Date: Fri, 03 Oct 2003 11:12:06 -0400
- To: www-dom@w3.org
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: Document.createAttributeForElement( in DOMString attrName, in DOMString elementName) Document.createAttributeForElementNS( in DOMString attrName, in DOMString elementNamespaceURI, in DOMString elementName) Document.createAttributeNSForElement( in DOMString attrNamespaceURI, in DOMString attrName, in DOMString elementName) Document.createAttributeNSForElementNS( 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 approach. [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 missing?] Steve Schafer Fenestra Technologies Corp http://www.fenestra.com/
Received on Friday, 3 October 2003 11:12:18 UTC