On 13.02.22 21:16, Andres Freund wrote:
The reason for the two xmlns= are different. The
xmlns="http://www.w3.org/1999/xhtml"; is afaict caused by confusion on our
part.
Some of our stylesheets use
xmlns="http://www.w3.org/TR/xhtml1/transitional";
others use
xmlns="http://www.w3.org/1999/xhtml";
It's noteworthy that the docbook xsl stylesheets end up with
<html xmlns="http://www.w3.org/1999/xhtml";>
so it's a bit pointless to reference http://www.w3.org/TR/xhtml1/transitional
afaict.
Adding xmlns="http://www.w3.org/1999/xhtml"; to stylesheet-html-common.xsl gets
rid of xmlns="http://www.w3.org/TR/xhtml1/transitional"; in bookindex specific
content.
Changing stylesheet.xsl from transitional to http://www.w3.org/1999/xhtml gets
rid of xmlns="http://www.w3.org/TR/xhtml1/transitional"; in navigation/footer.
Of course we should likely change all http://www.w3.org/TR/xhtml1/transitional
references, rather than just the one necessary to get rid of the xmlns= spam.
Yeah, that is currently clearly wrong. It appears I originally copied
the wrong namespace declarations from examples that show how to
customize the DocBook stylesheets, but those examples were apparently
wrong or outdated in this respect. It seems we also lack some namespace
declarations altogether, as shown by your need to add it to
stylesheet-html-common.xsl. This appears to need some careful cleanup.
The reason that we end up with so many more xmlns:xlink is just that without
our customization there ends up being a single
<div xmlns:xlink="http://www.w3.org/1999/xlink"; class="index">
and then everything below that doesn't need the xmlns:xlink anymore. But
because stylesheet-html-common.xsl emits the div, the xmlns:xlink is emitted
for each element that autoidx.xsl has "control" over.
Waiting for docbook to fix this seems a bit futile, I eventually found a
bugreport about this, from 2016: https://sourceforge.net/p/docbook/bugs/1384/
But we can easily reduce the "impact" of the issue, by just adding a single
xmlns:xlink to <div class="index">, which is sufficient to convince xsltproc
to not repeat it.
I haven't fully wrapped my head around this. I tried adding xlink to
our own exclude-result-prefixes, but that didn't seem to have the right
effect.
