[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: DOCBOOK-APPS: Re: DocBook XSL slow to process due to l10n.xml, keys
Norman Walsh wrote: > / Mike Brown <mike@skew.org> was heard to say: > | In 4XSLT, the preparation of the indices for these keys takes a very long time > | because they are computed for every source document, including those obtained > | via document(). It takes a long time to generate the indices for l10n.xml, > | even though these keys don't end up being needed for any but the main source > | tree. > > Perhaps 4XSLT should be modified to do lazy index generation? That was my suggestion when I filed the bug report on 4Suite's SourceForge project. But, in my opinion, failing to be lazy about xsl:key index preparation is not really a shortcoming in a processor. The XSLT spec is at fault for not providing a way to specify to which documents keys should apply. A stylesheet could potentially use a key on any of the source trees provided. With this being the case, one could just as easily suggest that DocBook XSL should be modified to make lazy index generation less of a requirement for the processor that's handlingit. If you only need to use one locale (or localization language or whatever) at a time, then it seems that you could use some clever xsl:importing or document() calls to include wrappers for only the subset of l10n entities that you need. - Mike ____________________________________________________________________________ mike j. brown | xml/xslt: http://skew.org/xml/ denver/boulder, colorado, usa | resume: http://skew.org/~mike/resume/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC