- From: Ray Whitmer <ray@imall.com>
- Date: Fri, 06 Nov 1998 07:55:15 -0700
- To: www-dom@w3.org
Mike Olson wrote: > This is how I understand it... > > The following tag: > <INPUT TYPE='TEXT' VALUE='something < something else'> > > Would be the following core DOM tree. > > An Element with a nodeName of INPUT > The element would have 2 Attr nodes in its attributes NameNodeMap > The first has a name of TYPE. It has one child 'Text' Node. The value of this Attr would > be 'TYPE' > The second has a name of VALUE. It has three children. > The first child is a Text Node for 'something ' > The second child is a EntityReference for the < > The third child is a 'Text' Node for ' something else' > > However, I have a question about the second attr. > > Should its value attribute return 'something < something else' or should it return > 'something < something else' ? If < were a normal entity reference, then the tree would be exactly as you describe, and the value returned when the attribute is requested as a string either by calling Element.getAttribute("VALUE") or Element.getAttrributeNode("VALUE").getNodeValue() is 'something < something else'. However < is one of five predefined XML entities (also amp, gt, quot, apos) which the parser will generally translate strait to the character equivalent in the text as it builds the parse tree, so for these entities, you just get a single text node for the attribute children instead of three. It would be converted back to < on output automatically, even if it was set as "<" in an attribute string or text node. This is described under "Interface EntityReference" in the core specification. It is also worth pointing out that a parser may see fit to not preserve any entity references at all but expand them all and then you would get no entity reference nodes at all. Ray Whitmer ray@imall.com
Received on Friday, 6 November 1998 09:56:01 UTC