Add-on to the Semantically correct XHTML output project roadmap

PROPOSED ROADMAP TO IMPLEMENT R.H.' GUIDELINES
FOR SIMPLER AND SEMANTICALLY CORRECT XHTML OUTPUT
* Version 1.0 1.1 * 

1. Produce a set of desired XHTML outputs corresponding to all
possible DocBook structures, according to Rene Hache's guidelines.

[COMMENT BY N.R.] This is probably the hardest part to achieve,
since each DocBook user on Earth will have its own vision of the
desired output. But I'm convinced we can get to a consensus.

2. Test whether these expected outputs are conforming to W3C
Strict XHTML and Accessibility recommendations and guidelines.
Correct them until they succeed.

3. Define XSLT processing options to suit most of the DocBook
users needs for their wanted outputs.

[COMMENT BY N.R.] These needs have to be defined in the project
guidelines.

3. Completely rewrite the XHTML XSL from scratch, since the current
one is based on the HTML one (even in the XSLT2 snapshot, this is
still the case - correct me if I am wrong). Strict XHTML is
definitively not Transitional HTML(the first is XML, the second
is SGML, but this is not the only difference).

[COMMENT BY N.R.] Yes, I know, "The people who developed and
maintain the style sheets deserve both some slack and our
appreciation", as Eric Johnson and a few others pointed it out.
I totally agree with this and I am the first to give all my
gratitude to them. But, I don't see why we should stick to
obsolete and inadequate stuff, on the pretext that we should have
Grand Respect to the Code and its Maintainers. Due to their
license terms (X11-style), the DocBook XSLs are conforming to the
free software philosophy. Thus, everybody is invited to constantly
improve, add features, correct the code, and maybe rewrite it if
necessary. This is what I want to bait with this post, hopping
that I won't hurt anybody by doing so.

[COMMENT BY N.R.] "Why wouldn't we write a simple customization
layer?" There are many reasons for this. The first is to ease the
code maintenance. Changes in the underlying code could break the
upper layer, and it adds too much complexity. The second reason
is processing time: a customization layer would certainly not
improve it. On the other hand, stripping all unwanted and
obsolete processing instructions would improve it, since
semantically correct XHTML is much simpler than HTML.

4. Try to get these new XSLs integrated into the main DocBook
project, instead of proposing them separately.