[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cgmo-webcgm] QUESTION: where are Text Nodes in the WebCGM DOM tree?
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]