Hi, > Im Auftrag von Daniel Veillard > Gesendet: Donnerstag, 6. April 2006 14:47 > > On Thu, Apr 06, 2006 at 02:33:17PM +0200, Kasimier Buchcik wrote:
[...] > > I now realize that leaving the stylesheet's node-tree untouched > > is not possible, since it would break compile-time code which uses > > extension functions. > > _xsltElemPreComp (xsltInternals.h) has the following field: > > xmlNodePtr inst; /* the instruction */ > > ... this means that code out there relies on the current form the > > the stylesheet's node-tree. > > and it's used to report errors too. Also tor reporting errors during transformation time? [...] > > If not, i.e. if the stylesheet's tree is not accessed during > > transformation time by the user, then there would be a way - and > > only then it would make sense - to compile much more stuff like > > literal result elements into smaller specialized structures. > > What do you expect to gain that way ? a tiny amount of memory, not > worth chasing IMHO, stylesheet compilation time and size are nearly > neglectible compared to transformations costs, except maybe if you > have something like DocBook stylesheet and a tiny input doc > to transform, > and even in such case I would not guess you would gain much. The gain would be that we get something more similar to an AST. Currently we have a kind of hybrid; not a clean data structure for its actual purpose. Changes to the AST by the processor implicate taking care of XML node-tree restrictions. The problems with the correct implementation of the "exclude-result-prefixes" mechanism are an example of such restrictions: just skipping a ns-decl while buidling the AST is no problem, while removing an ns-decl from the node-tree is a problem. An initial proposal: - Add fields for navigation to the common part the fields of a _xsltStylePreComp (and all specialized strucures) in order to have a way to traverse the AST without the use of the node-tree. - Compile literal result elements into just 1 struct (e.g. _xsltStylePreCompLRE) with fields referencing the actual element in the node-tree. If we can't avoid having the node-tree, then we should at least avoid restrictions of the node-tree here. If there are no fundamental arguments against such an approach, then I'll try to implement this locally on my side and will see if it breaks something; then report back. Regards, Kasimier _______________________________________________ xslt mailing list, project page http://xmlsoft.org/XSLT/ [email protected] http://mail.gnome.org/mailman/listinfo/xslt
