- From: Steve Schafer <steve@fenestra.com>
- Date: Mon, 06 Oct 2003 10:27:14 -0400
- To: www-dom@w3.org
- Cc: robin.berjon@expway.fr
On Sun, 05 Oct 2003 20:24:50 +0200, Robin Berjon <robin.berjon@expway.fr> wrote: >I understand your wishes but can that not be solved differently by the >implementation? Yes, as I said, it _can_ be handled behind the scenes by the implementation. That's what I'm doing now. Of course, everything in the DOM _can_ be handled by an implementation without using the DOM at all, but that, I think, is rather beside the point of this mailing list. >Also, you are skipping over the fact that the exact same problem exists >for elements. For example, when instatiating an HTMLLIElement the value >field only has meaning when the <li> is contained in a <ul>, but not in >a <ol>. I admit that there may be situations where the semantics of a given element are substantially dependent on the context of that element, but I don't think HTML's <li> is a good example of such. An attribute having useful meaning in one context and simply being ignored in another (that is, it could still have the same meaning; it's just not used) is a far cry from an attribute having completely different useful interpretations in two (or more) contexts, which is what's happening in SVG. Also note that the "value" attribute of <li> is deprecated in HTML 4.0 and absent in XHTML (except via the Legacy module); this suggests that the authors understand that there are significant problems with using such heavily overloaded element and attribute names. >I'm not saying that your problem doesn't exist, simply that it seems to >me to be impossible to solve in a generic way (which is what the DOM >ought to do). Well, if in fact the DOM is concerned only with the "generic way," then it doesn't need anything like namespace support or most of the other stuff added in Levels 2 and 3, since all of that can be handled, albeit somewhat painfully, using Level 1 features and implementation-specific extensions. But it's clear that the authors are interested in dealing with more than the bare minimum. Section 1.1.12 of the latest DOM Level 3 draft clearly shows that the authors have been thinking about the problem of dealing with elements from multiple namespaces; what I'm proposing is a simple extension of exactly the same idea to attributes. And since attributes are typically not differentiated via namespaces, the only other reasonable means of differentiation is via the element in which they are contained. >In the case of SVG, I believe all that you raise goes away when using >setAttributeNS() (that might not be true in other languages). No, that's not true. The various ...AttributeNS... methods are for dealing with attributes which themselves belong to a namespace; except for a handful, like xml:base et al., the attributes in SVG aren't associated with any namespace. In other words, in the following: <svg xmlns="http://www.w3.org/2000/svg" transform="rotate(90)"> ... </svg> the namespace URI of the "transform" attribute is empty. (See sections 5.2 and A.3 of the "Namespaces in XML" rec.) >If you get this twice, you're subscribed. I didn't get it twice, so I'm not subscribed. (But I already knew that, because I have never received *any* of the messages posted to this list.) Steve Schafer Fenestra Technologies Corp http://www.fenestra.com/
Received on Monday, 6 October 2003 10:27:42 UTC