On Fri, Jan 28, 2005 at 09:11:17PM +0100, Vincent Lefevre wrote: > On 2005-01-28 12:31:33 -0500, Daniel Veillard wrote: > > Since libxslt generate-id() is based on node pointer values. More > > over each document reference the DocBook DTD which is far from being > > small. So it's not surprizing at all to me if memory grows very > > fast. The only doubt I have is that the DTD from those documents can > > probably be removed once parsed since all entities values should > > have been replaced at that point but that's not 100% sure it's a > > safe thing to do. > > Couldn't the DTD structure be shared, since it is read-only?
Not read-only. The presence of an internal subset can override definitions done in the external subset. Detecting a-priori that there no internal subset may be a bit tricky. > And the advantage would be that the DTD wouldn't have to be > reparsed. It would also be useful for batch transformations > of XML files using the same DTD. There is that problem for XInclude too, it's a trick, a deviation from the pure XML parsing process though, for example getting the included file on a file server may modify the DTD as a side effect. > > Using a DTD which uses 2.5 MByte of memory for each blog items > > which should be around a kilobyte each sounds a very heavy design to > > me. You're paying the cost of that design I would say. > > I don't think the design is really bad. IMHO, xsltproc/libxslt is > sub-optimal. I take patches and I will apply them if correct :-) Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ _______________________________________________ xslt mailing list, project page http://xmlsoft.org/XSLT/ [email protected] http://mail.gnome.org/mailman/listinfo/xslt
