Re: Comments and questions on text node interface

> >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.

Sorry, for a moment there i thought that normalize would expand entity
references. So i guess that my answer is that we need a normalize-like
method that expands entity references as well as merging textnodes.

> 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)?

Not at all, all I'm asking for is some way to expand them, both the ones
containg textnodes and the ones containg other node-types. (Well.. I do
think that it would be nice if entityreferences were depecated, but that's
an entierly different discussion.)

But this brings up an interesting question: what happens with wholeText and
XPath when there are unexpanded entityreferences in a tree? Should they
consider text on either side as separate "text-sections", or should the
entity be ignored and the text "merged"?

> 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.

XPath never changes the tree so it has no need for a replaceWholeText
method. Similary I'm not objecting to the wholeText property since that is
needed for clients using XPath.

The reason that I don't like replaceWholeText is that it basically changes
underlying data through a view. Adding views to "abstrahize" data into a
more convinient form is fine, however using that view to change the
underlying data often leads to complex implementations and non-obvious or
un-expected behaviour.

/ Jonas Sicking

Received on Thursday, 14 March 2002 10:39:42 UTC