Re: [cgmo-webcgm] QUESTION: where are Text Nodes in the WebCGM DOM tree?

[Lofton Henderson <lofton@rockynet.com>]

At 09:46 AM 7/6/2005 -0400, Benoit Bezaire wrote:
>Tuesday, July 5, 2005, 9:17:50 PM, Lofton wrote:
>[...]
>LH> And model:part-longdesc would be the parentNode of that Text
>LH> Node?
>Well, Attr nodes have a ownerNode, not a parentNode... but yes (same
>concept).

parentNode -- defined on the WebCGMNode interface.
ownerNode -- defined on the WebCGMAttr interface (which derives from 
WebCGMNode).

Since Text Node does not have a derived interfaceto which to attach 
something like ownerNode, it would have to use parentNode, right?


>LH>  (Text Node has no children, and since we can't have
>LH> additional markup within application-specific metadata elements,
>LH> there will be no siblings,
>why do you say that?

Misunderstanding, see below...


>LH> as there might be if part-longdesc could have child elements that
>LH> split the text node into sibling-level pieces.)
>
>LH> Correct?
>No. Our implementation supports...
><grobject ...>
>   <model:part-longdesc>Here is a verbose description
>     <model:anotherNode>Some text</model:anotherNode>
>   </model:part-longdesc>
></grobject>

Aha, I had been thinking that application-specific elements could only go 
one deep, i.e., no have children.  But we don't say that anywhere.  (Nor do 
we say that the app-specific content model can go arbitrarily deep.)

I have no problem with app-specific elements having children.  I just 
wasn't considering those cases (which indeed could lead to siblings of Text 
Nodes, both other T.N. siblings and siblings that are other elements).  As 
in...

<grobject ...>
   <model:part-longdesc>
       Here is a verbose description
      <model:anotherNode>Some text</model:anotherNode>
      of the part whose part number is ..blah..
    </model:part-longdesc>
</grobject>


>LH> Is there anywhere else in the WebCGM DOM model that Text
>LH> Nodes appear?
>No, not in WebCGM.
>
>LH> DOM2 suggests they might represent the content of Attr nodes:
>I guess we diverged from that in an attempt to simplify things...

"we diverged" -- this is what I could not determine ... not from minutes, 
not from the spec, not from anywhere.  What *are* the rules?  You're saying 
that the content of an Attr is not a Text Node.  Do we actually document 
that anywhere?


>LH> [InterfaceText, p.60]
>LH> The Text interface inherits from CharacterData[p.47] and represents
>LH> the textual content (termed character data in XML) of an Element[p.52]
>LH> or Attr[p.51] . If there is no markup inside an element's content,
>LH> the text is contained in a single object implementing the Text
>LH> interface that is the only child of the element. If there is
>LH> markup, it is parsed into the information items [p.98] (elements,
>LH> comments, etc.) and Text nodes that form the list of children of the 
>element.
>LH>  Interface Attr [p.51] The Attr interface represents an attribute
>LH> in an Element[p.52] object. Typically the allowable values for the
>LH> attribute are defined in a document type definition.
>LH> Attr objects inherit the Node[p.34] interface, but since they are
>LH> not actually child nodes of the element they describe, the DOM
>LH> does not consider them part of the document tree. Thus, the Node
>LH> attributes parentNode, previousSibling, and nextSibling have a
>LH> null value for Attr objects. The DOM takesthe 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.
>LH> [...]
>LH> In XML, where the value of an attribute can contain entity
>LH> references, the child nodes of the Attr node may be either
>LH> Text[p.60] or EntityReference[p.65] nodes (when these are in use;
>LH> see the description of EntityReference for discussion). Because
>LH> the DOM Core is not aware of attribute types, it treats all
>LH> attribute values as simple strings, even if the DTD or schema
>LH> declares them as having tokenized [p.99] types.
>
>LH> Consider the following example,
>LH> ...
>LH> <grobject apsid="someId" screentip="this object has
>LH> as creentip" name="someName" model:part-number="AJX-20054321-B">
>LH>     <model:part-longdesc>Here is a verbose description of the
>LH>         AJX-20054321-B part, complete with source and replacement
>LH>         instructions. Blah...blah...
>LH>     </model:part-longdesc>
>LH> </grobject>
>
>LH> One reasonable interpretation of the DOM2 text suggests that
>LH> there would be several more text nodes in the example now, the
>LH> strings: "this object has a screentip",
>LH> "someName","AJX-20054321-B", "Here is a verbose description...".
>
>LH> So the final question is:  are these considered to be Text Nodes
>LH> in the WebCGM DOM model?
>I don't see how someone, reading the current WebCGM wording could
>conclude that these are Text nodes. No they are not (except "Here is a
>verbose description...").

I read the WebCGM wording and it does not say *anything* about what are 
Text Nodes.  (Did I miss something?)  So I turned to DOM2, from which 
WebCGM DOM is derived, where it says they *are* Text Nodes.

-Lofton.