Re: EntityReference

"Lauren Wood" <lauren@sqwest.bc.ca> writes:

> On 28 Jul 98, at 9:57, keshlam@us.ibm.com wrote:
> 
> > Since replacement value doesn't change after the entity has been created,
> > I think you'd wind up with many _references_ to the replacement value but
> > only need one copy. True?
> 
> as long as the user sees an Entity each time they walk through the 
> EntityReference, you can implement the actual object any way you 
> want. So yes, your interpretation matches mine.

It is very difficult to implement this any way but by making actual copies,
because each occurrance of the Entity has to have, or appear to have, the
correct parentNode and sibling links. 

On the other hand, it's very _easy_ to implement if you have a TreeIterator
or some such, because then the iterator can hide the actual structure and
descend into the Entity rather than its reference. 

That's what we're doing in our implementation.  We are essentially filtering
documents, so we have to be able to reconstruct them on the output in a form
identical to the input.  We leave the EntityReference nodes in the tree, and
our iterators do the replacement on the fly.

This brings up a weak point in both the XML and the DOM specs -- no
consideration at all is given to the possibility that one might want to
_output_ a document, in which case replacing each EntityReference with its
corresponding Entity is WRONG.  The whole assumption is that the parser is a
front-end for an application that doesn't want to know about the _real_
structure of the document.

-- 
 Stephen R. Savitzky   Chief Software Scientist, Ricoh Silicon Valley, Inc., 
<steve@rsv.ricoh.com>                            California Research Center
 voice: 650.496.5710   fax: 650.854.8740    URL: http://rsv.ricoh.com/~steve/
  home: <steve@starport.com> URL: http://www.starport.com/people/steve/

Received on Tuesday, 28 July 1998 12:46:19 UTC