Re: AW: AW: [xslt] Changes of internal structures



On Thu, Apr 06, 2006 at 04:26:08PM +0200, Kasimier Buchcik wrote:
> >   and it's used to report errors too.
> 
> Also tor reporting errors during transformation time?

  yes I think so

> > > 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.

  that's a fairly specific problem, but not simple I agree...

> 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.

  I'm not opposed to doing research :-) that can certainly work, the question
is will that break user's code ... hard to tell !

Daniel

-- 
Daniel Veillard      | Red Hat http://redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]