[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re[2]: [cgmo-webcgm] QUESTION: where are Text Nodes in the WebCGM DOM tree?
Hi Lofton, The idea is that the WebCGM specification is a standalone spec (no need read the DOM2 spec). I agree that we should add wording to explain what and where are TEXT_NODE in the WebCGM DOM. We only have: TEXT_NODE; the node contains character data. -- Benoit mailto:benoit@itedo.com Wednesday, July 6, 2005, 10:03:56 AM, Lofton wrote: LH> 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). LH> parentNode -- defined on the WebCGMNode interface. LH> ownerNode -- defined on the WebCGMAttr interface (which derives from LH> WebCGMNode). LH> Since Text Node does not have a derived interfaceto which to attach LH> 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? LH> 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> LH> Aha, I had been thinking that application-specific elements could only go LH> one deep, i.e., no have children. But we don't say that anywhere. (Nor do LH> we say that the app-specific content model can go arbitrarily deep.) LH> I have no problem with app-specific elements having children. I just LH> wasn't considering those cases (which indeed could lead to siblings of Text LH> Nodes, both other T.N. siblings and siblings that are other elements). As LH> in... LH> <grobject ...> LH> <model:part-longdesc> LH> Here is a verbose description LH> <model:anotherNode>Some text</model:anotherNode> LH> of the part whose part number is ..blah.. LH> </model:part-longdesc> LH> </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... LH> "we diverged" -- this is what I could not determine ... not from minutes, LH> not from the spec, not from anywhere. What *are* the rules? You're saying LH> that the content of an Attr is not a Text Node. Do we actually document LH> 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..."). LH> I read the WebCGM wording and it does not say *anything* about what are LH> Text Nodes. (Did I miss something?) So I turned to DOM2, from which LH> WebCGM DOM is derived, where it says they *are* Text Nodes. LH> -Lofton.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]