For the last few days I've been trying to work out how to kill the
entity file include magic and getting our files to validate standalone
(so, for instance you can work on individual files in XML editors or
to render individual files)...
That would be nice :)
Quickish summary of the things I've concluded;
Since we use bunch of entities for headings, text repeated multiple
times and to ease translation, we need to reference these entities
somehow (by using DTD).
So, I created a new DTD using the old DB4 method, adding dbgenent.mod
to the DocBook DTD (calling the new DTD PHookBook) and referenced our
language-defs/-snippets from there, solving the translation problem
with the use of XML catalog.
Files containing DTDs cannot be enititymagically included so I changed
them all to be XIncluded.
XIncluded files require _valid_ XML, meaning our entities.*.xml cannot
be XIncluded so they still have to be entitymagicincludes (although
the content of them is XIncludes).
That fails due to our use of XIncluded xpointer()s (for the class
reference method listing), since those IDs aren't loaded at that
point.
Fixing that requires making the children of books
entitymagicincludes again.
The book itself (extension reference) is valid by its own (except for
missing IDREFs, which is "fine"), but parsing all the entities over
and over and over and over again during the XIncludes of the books
takes ridiculous amount of time, we are talking minutes here, not
seconds.
So, we _can_ make the individual extension references valid standalone
and render them standalone and make them work OK within XML editors..
but at the cost of quite massive overhead when doing full builds.
Anyone thinks it is worth it?
By increasing build time by minutes, are you talking about per book or
per full build?
I don't think it's worth implementing yet but would love to see a wiki
entry detailing all of this so that the work is not lost. And if we do
decide to move translations towards gettext (po files) it would likely
be a good time to revisit this topic.
Regards,
Philip
