[XML-SIG] Re: [4suite] ReleaseNode interface in 4XSLT

[Mike Olson]

"Fred L. Drake, Jr." wrote:
> 
> Mike Olson writes:
>  > This is why I vote for either the implementation has the releaseNode
>  > function, or the node itself.
> 
>   I am a little concerned about the method, however, because I see two
> different possibilities.  One is the "I don't need you anymore; don't
> bother me" option (equivalent to DECREF), and the other is "Break all
> your internal links and die", equivalent to the minidom .unlink()
> method.  From the discussion so far, I'm getting the sense that the
> latter is what is being discussed, and this is not always
> appropriate.  To build DOM trees to use with the XPath/XSLT engines,
> would I need to provide an empty .releaseNode(), since the DOM trees
> are persistent and have lifetimes far beyond the individual use for
> them with a specific transformation?

It depends on the interface into the XSLT/XPath engine.  They way
4XSLT/4XPath is set up, if you pass us a DOM node to process, we won't
touch it.  It is your DOM node, you job to release it.  However, if you
call appendStylesheetUri (as an example) we create a DOM node, and we
will release it when processing is done.  Currently, you can call
"setDocumentReader" on the 4XSLT processor to use anything that conforms
to the Reader interface when fromUri, fromString, fromStream are
called.  We then call the coresponding releaseNode on the documetn
reader to free the DOM tree when we are done with it.

So, I guess I still see plenty of cases where "unlink" makes sense. 
When would you want to use the DECREF equiv.?

Mike


> 
>   -Fred
> 
> --
> Fred L. Drake, Jr.  <fdrake at acm.org>
> PythonLabs at Digital Creations

-- 
Mike Olson				 Principal Consultant
mike.olson@fourthought.com               (303)583-9900 x 102
Fourthought, Inc.                         http://Fourthought.com 
Software-engineering, knowledge-management, XML, CORBA, Linux, Python