W3C home > Mailing lists > Public > www-dom@w3.org > October to December 1998

Re: Attribute have Multi-values?

From: Ray Whitmer <ray@imall.com>
Date: Fri, 06 Nov 1998 07:55:15 -0700
Message-ID: <36430DD3.F767D07@imall.com>
To: www-dom@w3.org
Mike Olson wrote:

> This is how I understand it...
> The following tag:
> <INPUT TYPE='TEXT' VALUE='something &lt 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 &lt
>     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 &lt something else' or should it return
> 'something < something else' ?

If &lt; 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 &lt; 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 &lt; 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
Received on Friday, 6 November 1998 09:56:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:05 UTC