- From: Ray Whitmer <rayw@netscape.com>
- Date: Tue, 18 Dec 2001 14:21:47 -0800
- To: Elliotte Rusty Harold <elharo@metalab.unc.edu>
- CC: Dieter Köhler <dieter.koehler@ppp.uni-bamberg.de>, " www-dom@w3.org" <www-dom@w3.org>
Elliotte Rusty Harold wrote: > However, this still doesn't tell us what the value of the attribute is > or what DOM should return for the value of the Attr when the actual > attribute value contains an unresolved entity reference. DOM does not > define the value of the attribute in terms of the value of its child > nodes. It is clear that if you getValue, the returned string will ignore an entity reference that has no child text. If you get the hierarchy of the attribute in this case, I think that you really should have an EntityReference representing the unexpanded entity reference, but DOM does not say that explicitly. Arguably doing that in an attribute value goes beyond what even the infoset describes. > That's definitely not true. DOM does not require validation or a > validating parser. It works with merely well-formed documents that do > not have a DTD. It also works with documents that are valid and do > have DTDs, but which are processed by a non-validating parser. > > The problem is that the behavior of a couple of methods in the Node > and Attr in classes is underspecified in this case. It is clear what DOM will do. Getting back the value of the attribute as a string will not fail, and it will not include anything for any empty EntityReference, which may or may not be in the hierarchy, depending upon what the parser decided to do. That is what it always does. It is only unclear what the parser will do. Will it put the entity reference in the tree, or will it not. Will it abort or will it continue. How is attribute normalization, normally performed by the parser, affected by this event. etc. Ray Whitmer rayw@netscape.com
Received on Tuesday, 18 December 2001 17:22:22 UTC