[XML-SIG] Future plans
Mike Olson
Mike.Olson@Fourthought.com
Thu, 30 Dec 1999 11:30:39 -0700
--------------2DB133F0D6BB61CB4A4E242F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Greg Stein wrote:
> On Wed, 29 Dec 1999, Paul Prescod wrote:
> > Dieter Maurer wrote:
> >...
> > > As for the explicite memory management necessary for 4DOM:
> > > It is very easy to introduce cycles in Python's data structures.
> > > I would expect that many non-trivial Python programs
> > > contain such cycles and leak memory -- without dramatic
> > > effect. I can live with explicite memory management for DOM trees,
> > > even though they tend to be rather large structures.
> >
> > I would like to suggest again the idea that for simple uses we could use
> > a proxy and that sophisticated users could "ask for" a fast version and
> > get back an unproxied version that they must release.
> >
> > My concern is for newbies. They are thinking "XML documents" not
> > "cycles." The default should be safe but a little slow.
>
> I solve the problem in qp_xml by avoiding it altogether :-) The output
> elements of qp_xml does not contain a parent reference. I've found that
> the application always knows the parent anyhow since it had to traverse
> down thru the parent in the first place. And if you're passing around
> subtrees of an XML document, then they are treated context-free (i.e. it
> doesn't matter what the parent is).
>
This works great for simple XML processing, but will never work for XPath
processing. the simplest XPath expression, "../", or "/ROOT", would not be
possible, as nodes are not context free in XPath, but need to know there
absolute location in the tree.
You could wrap the DOM elements in XPath, and force the XPath processor to
handle destruction of parent/child relationships, but then you are
sacrificing XPath/XSLT/XLink/XQL performance in exchange for getting around a
minor inconvience (in my opinion)
I think the best solution is documentation. Yes, it is unpythonic for a user
to have to deal with memory mangement. However, if it is documented well,
both in references and demos, I think even the newest of newbies will notice
and comply. After all, they have to look in the docs/demos anyways for any
new package they try.
Most newbies will be writting small scripts to process XML which will run and
quit anyways. If they are writting a long running server, then they will
need to be aware of circular reference anyways, and adding a line of code to
free up a DOM tree will be the least of thier worries.
$.03 more in the pot
Mike
>
> Just my 3 cents (inflation in the new millenia :-)
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
> _______________________________________________
> XML-SIG maillist - XML-SIG@python.org
> http://www.python.org/mailman/listinfo/xml-sig
--
Mike Olson
Consultant Member FourThought LLC
http://www.fourthought.com http://www.opentechnology.com
720-304-0152
--------------2DB133F0D6BB61CB4A4E242F
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Greg Stein wrote:
<blockquote TYPE=CITE>On Wed, 29 Dec 1999, Paul Prescod wrote:
<br>> Dieter Maurer wrote:
<br>>...
<br>> > As for the explicite memory management necessary for 4DOM:
<br>> > It is very easy to introduce cycles in Python's data
structures.
<br>> > I would expect that many non-trivial Python programs
<br>> > contain such cycles and leak memory -- without dramatic
<br>> > effect. I can live with explicite memory management
for DOM trees,
<br>> > even though they tend to be rather large structures.
<br>>
<br>> I would like to suggest again the idea that for simple uses we could
use
<br>> a proxy and that sophisticated users could "ask for" a fast version
and
<br>> get back an unproxied version that they must release.
<br>>
<br>> My concern is for newbies. They are thinking "XML documents" not
<br>> "cycles." The default should be safe but a little slow.
<p>I solve the problem in qp_xml by avoiding it altogether :-) The
output
<br>elements of qp_xml does not contain a parent reference. I've found
that
<br>the application always knows the parent anyhow since it had to traverse
<br>down thru the parent in the first place. And if you're passing around
<br>subtrees of an XML document, then they are treated context-free (i.e.
it
<br>doesn't matter what the parent is).
<br> </blockquote>
This works great for simple XML processing, but will never work for XPath
processing. the simplest XPath expression, "../", or "/ROOT",
would not be possible, as nodes are not context free in XPath, but need
to know there absolute location in the tree.
<p>You could wrap the DOM elements in XPath, and force the XPath processor
to handle destruction of parent/child relationships, but then you are sacrificing
XPath/XSLT/XLink/XQL performance in exchange for getting around a minor
inconvience (in my opinion)
<p>I think the best solution is documentation. Yes, it is unpythonic
for a user to have to deal with memory mangement. However, if it
is documented well, both in references and demos, I think even the newest
of newbies will notice and comply. After all, they have to look in
the docs/demos anyways for any new package they try.
<p>Most newbies will be writting small scripts to process XML which will
run and quit anyways. If they are writting a long running server,
then they will need to be aware of circular reference anyways, and adding
a line of code to free up a DOM tree will be the least of thier worries.
<p>$.03 more in the pot
<p>Mike
<br>
<blockquote TYPE=CITE>
<br>Just my 3 cents (inflation in the new millenia :-)
<p>Cheers,
<br>-g
<p>--
<br>Greg Stein, <a href="http://www.lyra.org/">http://www.lyra.org/</a>
<p>_______________________________________________
<br>XML-SIG maillist - XML-SIG@python.org
<br><a href="http://www.python.org/mailman/listinfo/xml-sig">http://www.python.org/mailman/listinfo/xml-sig</a></blockquote>
<pre>--
Mike Olson
Consultant Member FourThought LLC
<A HREF="http://www.fourthought.com">http://www.fourthought.com</A> <A HREF="http://www.opentechnology.com">http://www.opentechnology.com</A>
720-304-0152</pre>
</html>
--------------2DB133F0D6BB61CB4A4E242F--