Re: "Intelligent" element and attribute creation

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