Re: AW: AW: [xslt] Changes of internal structures
- From: Daniel Veillard <veillard redhat com>
- To: Kasimier Buchcik <k buchcik 4commerce de>
- Cc: The Gnome XSLT library mailing-list <xslt gnome org>
- Subject: Re: AW: AW: [xslt] Changes of internal structures
- Date: Thu, 6 Apr 2006 10:45:55 -0400
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]