DocBook XSL slow to process due to l10n.xml, keys

[Mike Brown]

IIRC, the main issue is the size of l10n.xml. Parsing this takes forever.

I take it back. Actually, it's not the parsing that takes so long, it's that
the stylesheets use complex keys (thank you Jeni T.).

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.

- Mike
____________________________________________________________________________
mike j. brown | xml/xslt: http://skew.org/xml/
denver/boulder, colorado, usa | resume: http://skew.org/~mike/resume/

[Norman Walsh]

/ Mike Brown <***@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?

Be seeing you,
norm

[Mike Brown]

Post by Norman Walsh
| 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/

[Norman Walsh]

/ Mike Brown <***@skew.org> was heard to say:
| 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.

I don't recall seeing this on the spec comments list. Nor do I recall
seeing it addressed in the XSLT 2.0 draft I'm reading. I'll try to
remember to bring this up.

| some clever xsl:importing or document() calls to include wrappers for only the
| subset of l10n entities that you need.

There's no facility for dynamic imports. I suppose the l10n code could
be rewritten to load languages on demand, I'll have to think about
that.

In the meantime, if you only write in English, you can edit your copy
of l10n.xml so that it doesn't refer to any of the other languages.

Be seeing you,
norm