Re: Questionw: MAY versus MUST; Attr

[Benoit Bezaire <benoit@itedo.com>]

Friday, May 27, 2005, 9:42:57 AM, Lofton wrote:
LH> Benoit, all --

LH> Focusing on clarifying one particular point...

LH> At 03:11 PM 5/26/2005 -0400, Benoit Bezaire wrote:
LH> Thursday, May 26, 2005, 12:39:51PM, Lofton wrote:
LH> [...]
LH>> [Btw, editorial, in the sentence, "All nodes, exceptWebCGMPicture may have
LH>> a parent.":  s/may// , correct?]
LH> False... but it should be "All nodes, except WebCGMPicture and
LH> WebCGMAttr may have a parent."


LH> Q.1:  How can a node (other than the alleged root, Picture,
LH> or Attr according to the above) *not* have a parent? 
In DOM2 many nodes (Attr, Document, DocumentFragment, Entity, and
Notation) do not have parents. The other node types MAY have a parent
because of the createXYZ() methods (i.e., they do not have a parent
until they are inserted in the tree).

In our case, we do not have the createXYZ, so it's possible "may" does
not apply (I'd have to think about it some more).

LH> Q.2:  When you added Attr, it confused me.  I was thinking
LH> in Xpath/XSLT terms, where attributes are indeed children of the
LH> elements they belong to (and those elements are indeed the parents
LH> of their attributes).  So I looked at DOM2, which explains the
LH> different model (p.51, Interface Attr):
Attr does not have a parentNode, they instead have an ownerNode. The
reason they don't have a parentNode is because you do not access an
element's attributes via the '.firstChild' call. If attributes are not
a child, how can they have a parent?

Also, I've never looked at the XPath specification to influence the
definition of the WebCGM DOM. But note that the XPath specification
says:
"5.3 Attribute Nodes

Each element node has an associated set of attribute nodes; the
element is the parent of each of these attribute nodes; however, an
attribute node is not a child of its parent element.  

NOTE: This is different from the DOM, which does not treat the element
bearing an attribute as the parent of the attribute (see [DOM])."
    
LH> [[[The Attr interface represents an attribute in an Element
LH> [p.52]object. Typically the allowable values for the attribute are
LH> defined in a document type definition.

LH> Attr objects inherit the Node [p.34] interface, but since
LH> they are not actually child nodes of the element they describe, the
LH> DOM does not consider them part of the document tree. Thus, the
LH> Node attributes parentNode, previousSibling, and nextSibling have a
LH> null value for Attr objects. The DOM takes the view that attributes
LH> are properties of elements rather than having a separate identity
LH> from the elements they are associated with; this should make it
LH> more efficient to implement such features as default attributes
LH> associated with all elements of a given type.  Furthermore, Attr
LH> nodes may not be immediate children of a DocumentFragment [p.24] . 
LH> However, they can be associated with Element [p.52] nodes contained
LH> within a DocumentFragment. In short, users and implementors of the
LH> DOM need to be aware that Attr nodes have somethings in common
LH> with other objects inheriting the Node interface, but they also are
LH> quite distinct. ]]]

LH> I guess you have applied the same principle to WebCGMAttr?
Yes, the DOM spec has been successfully used since 1998, I don't see
why we should diverge from it.

LH> Am I the only one to whom these points were not obvious in
LH> Ch.5? (Both the structure of the document tree in terms of
LH> parents/children, and the rules on the particular WebCGMNode
LH> attributes like parentNode.)
FYI, I had to read the DOM spec more than once to understand it to an
acceptable level. I think that's typical for this type of
specification.

We could increase the Interface WebCGMAttr wording to include some of
the clarifications that you've mentioned above. That would probably
help.

LH> Regards,
LH> -Lofton.

-- 
 Benoit   mailto:benoit@itedo.com