W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2002

Re: Comments and questions on text node interface

From: Ray Whitmer <rayw@netscape.com>
Date: Thu, 14 Mar 2002 06:20:52 -0500
Message-ID: <3C908794.6000604@netscape.com>
To: www-dom@w3.org
Jonas Sicking wrote:

>Ray Whitmer wrote:
>
>>Stefan Wachter wrote:
>>
>>>2. replaceWholeText method
>>>
>>>This method has a lot of tree-processing logic that should not be
>>>executed by a child node on its parent node. I would prefer the parent
>>>node to have control over the process. Therefore I propose a method on
>>>the node interface:
>>>
>>>/**
>>>* Replaces the logically-adjactent text nodes always by a NEW text node.
>>>*/
>>>public Text replaceWholeText(int anIndex); // alternatively:
>>>replaceWholeText(Text aTextNode);
>>>
>>See the above objections to using an index and the more-complex signature.
>>
>
>I have to ask what is the intended use for replaceWholeText? I can defenetly
>see the use getting WholeText since it fits better with XPath. But chainging
>it feels very awkward since it could morph big parts of tree. I think a
>better way of editing a tree using an "XPath/infoset model" would be to have
>users normalize the tree first and then use the normal interfaces.
>
>/ Jonas Sicking
>
Implementations which do not support entity / entity reference 
constructs could clearly normalize such that there is no need for 
wholeText / replaceWholeText, but entities and entity references have 
not been deprecated.  Are you asking to deprecate EntityReference nodes 
(those with an expanded hierarchy beneath them -- unexpanded entities 
must still be supported for infoset compliance, not to mention correct 
display of XHTML which requires special display of unexpanded entity 
references)?  Or would you declare that XPath just doesn't work on DOM 
implementations which use them?  That might not be a fair treatment 
without officially deprecating them.  It would seem like harsh treatment 
after the fact to say to implementations that chose to support them that 
XPath functionality depends upon them not supporting them -- without at 
least an official deprecation.

Also, should users really be required to normalize before using the 
XPath, or is it reasonable to use XPath on an unnormalized tree? 
 Normalization may not be a trivial requirement if XPath is being used 
repeatedly as part of a process of mutating a document.  Most built-in 
functions of DOM do not requires the user to normalize before calling. 
 On the other hand, document normalization is becoming more and more 
significant with Level 2 and 3 features such as namespace and schema 
support so the result of an XPath query might be affected by lack of 
normalization anyway.

Ray Whitmer
rayw@netscape.com
Received on Thursday, 14 March 2002 09:21:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:55 GMT