Re: [xslt] libxslt: xsl:include/import cache?

[Elizabeth Mattijsen <liz dijkmat nl>]

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

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?


Elizabeth Mattijsen