DOM Attributes (was Re: Performance efficient alternative to AttributeList)

At 05:05 PM 6/2/98 -0400, ANOQ of the Sun wrote:

>First of all, I'm not quite sure wheter the general opinion
>is to have everything in DOM implemented as Nodes/NodeIterators
>or if attributes should be a special case, with an
>AttributeList.

We've moved away from the idea of attributes being a special case.

>
>I would like to see a special-case implementation for
>attributes, as opposed to using Nodes for attributes.

We discussed attribute handling in yesterday's DOM teleconference, and we
agreed to leave it roughly as it was INTENDED to be in the April 15 draft
(with errors corrected).  Your proposal is rather more elaborate than we'd
like to have the DOM core be at this point.  The performance efficiency of
implementations is of less concern to the WG at this point than keeping the
spec simple and re-using the basic interfaces whereever possible, so we're
going to keep Attributes specified using Nodes and NodeLists.  There are a
lot of interesting convenience methods in this proposal, however, so it
might be useful to implement them ON TOP of the DOM as an "aftermarket"
product, or if experience indicates that they are indeed very useful, they
might be specified as part of an optional package in a subsequent release
of the DOM spec.

In a nutshell, here's how attribute will be specified in the next draft of
the DOM API spec.  Please let us know what you think -- there's still time
to get suggestions considered at next week's face to face DOM WG meeting:

   [a bit of background information]
   We've removed NodeIterator from the Core (it may come back in a 
   later revision of the DOM API, probably as an optional package 
   rather than part of Core).  Everywhere we once
   used NodeIterator, we now use NodeList: To be consistent with the 
   Java 1.2 terminology,  we accept the definition of the the word 
   "Set" to mean a grouping of unique objects,
   "Collection" to mean a grouping that allows duplicates but 
   doesn't define a particular ordering, and "List" to mean an
   ordered collection.  In most uses in the DOM, the 
   sets of objects  we manipulate may contain duplicates but 
   are in a specific order, so  NodeList seems like the best label
   for the set of child nodes of an Element, the set of
   entity declarations in a DocumentType, etc.

   Attribute is derived from Node.  This SHOULD have been specified 
   in the 4/15 draft. mea culpa ...

   In the "object model", the value of an attribute is specified by 
   the Attribute's child nodes.  In the simple case, the value would 
   be a single Text node, in the more complicated
   case where the attribute value contains entity references, this 
   may be a list of  nodes or even a list of Elements and subtrees.  
   This is unchanged from the 4/15 draft.

   The Attribute interface will look just like it did in the 4/15 
   draft:

          interface Attribute : Node {
            wstring                   getName();
            wstring                   getValue();
            attribute boolean         specified;
            wstring                   toString();
          };

    Since Attribute is a Node, it has a getParent() method ... we are 
    discussing whether it should return NULL (since Attributes are not 
    "children" of elements), and have a getElementNode method on Attribute
    to get the Element that contains an Attribute.  Thoughts????

   There is no longer an AttributeList interface; instead Element has a 
   NodeList containing the  Attribute nodes to represent all the 
   attribute-value pairs defined for a given element.
   [OK, it should probably be a "NodeSet", but a) we don't want to       
   add an interface just to be "politically correct" with respect to 
   terminology, and b) the actual set of attributes
   is in SOME order defined by the implementation (if not by the XML 
   spec), and NodeList  provides the methods needed to enumerate all 
   the Attributes.]

   The "power user" MAY index into the NodeList of attributes and use 
   the Attribute  interface to get and set specific attribute values.  
   This will be useful mainly  to those using XML where attribute 
   values may have entity references.

   The typical user may use various "convenience" methods on the 
   Element interface to  get/set/remove Attribute Node's by the name 
   of the attribute, and to get/set/remove attribute VALUES 
   represented as strings.

   Thus, the Element interface will look as follows:

           interface Element : Node {
                 wstring      getTagName();

                 NodeList     getAttributeList();

                 wstring      getAttribute(in wstring name);
                 void         setAttribute(in string name, 
                                           in string value);
                 void         removeAttribute(in wstring name);

                 Attribute    getAttributeNode(in wstring name);
                 void         setAttributeNode(in Attribute newAttr);
                 void         removeAttributeNode(in Attribute
                                          
                                                   oldAttr);

                 void         getElementsByTagName(in wstring 
                                                   tagname);
               };

   
     (normalize() will -- I hope -- be removed)


Are there any other issues that have been discussed on the www-dom list
with respect to Attributes that are still murky?

Received on Thursday, 4 June 1998 15:11:29 UTC