Re: [xslt] libxslt: xsl:include/import cache?
- From: Elizabeth Mattijsen <liz dijkmat nl>
- To: xslt gnome org
- Subject: Re: [xslt] libxslt: xsl:include/import cache?
- Date: Tue, 04 Dec 2001 10:56:21 +0100
At 04:38 AM 12/4/01 -0500, Daniel Veillard wrote:
> > Or are there other issues that would prevent this from working?
> Won't work. I need to have the parent to implement correctly the import
>cascading semantic. And if the trees are shared this gets really complex.
Ok, I feared something like that would be the case... which is why I asked
before departing on that journey... ;-)
>... Sounds to me you have a design problem on the way you build your
>If you have instances of the same stylesheet all over the import tree,
>then you're forcing by design a lot of redundancy.
I think it is a common problem if you use XSLT to create web-sites from
huge XML databases on the fly _and_ do _not_ want to use extension
functions (because you want to remain portable). A lot of design elements
are stored in included stylesheets. But more importantly, large aspects of
the database (particularly index and category listings) are in XML and
included as entities, hidden in included stylesheets.
>... I'm not compelled to risk introducing very difficult to debug import
>order problems because you designed your import tree to be arbitrarilly
I'm not asking for that, merely exploring an idea...
>... The space used by the stylesheet xmlDoc are shared at the XML
>level I think, but the XSLT structure on top of it are not.
Hmmm... maybe I should approach this as an entity loading problem: there
wouldn't be any problems there with sharing, would there be? Apart from
the fact that the entities URL might deliver different data when invoked,
so that you would need some MD5 or similar checks in there. And that could
be done with a callback function, or not?
] [Thread Prev