Semantically correct XHTML output project

[Nicolas RAINARD <nicolas_rainard@yahoo.fr>]

To whom may be concerned/interested by getting simple and semantically correct XHTML output from the DocBook XSLT project.

A long time ago (in a galaxy far, far away), Rene Hache wrote:

PROPOSED GUIDING PRINCIPLES FOR SIMPLER, ACCESSIBLE AND
SEMANTICALLY CORRECT XHTML OUTPUT
* Version 1.1 1.2 :) *

1. The XHTML output will comply with the W3C XHTML 1.0 Transitional
Strict recommendation, as well as current W3C Accessibility
Guidelines.

[COMMENT FROM R.H. REMOVED]

[COMMENT FROM N.R.] Somebody (I don't remember who and when) said:
"Be flexible in what you accept as input, be strict in what you
output" (or something the like). Strict 1.0 (or maybe even 1.1) XHTML
is much easier and simpler to implement than the Transitional one.

2. Included in the output will be a default CSS file with a basic
layout for screen, print and handheld devices. The CSS file should be
fully functional in current browsers: Opera 7+, Mozilla/Gecko 1.0+
based browsers and IE 6+.

[COMMENT FROM N.R.] This CSS file shouldn't be necessary, since XHTML
aims to be fully accessible and readable without any presentation.
But it would be nice to (optionally) have it, if only to give an
example on how to use the CSS hooks (see section 6).

3. Outputted XHTML code will aim to be as simple (meaning fewer tags)
as possible to facilitate CSS layout, and be completely table-less
expect for tabular data.

4. XHTML output will have four main DIVs for layout purposes: header,
navbar (for basic navigation on all pages as well as next/previous),
content and footer.

5. Unless specified via the role attribute (or some other mechanism),
The only DIV to be generated inside the main content div will be
admonitions, sidebars and highlights.

[COMMENT FROM R.H. REMOVED]

6. [ADDED BY N.R.] CSS hooks will be provided by using XML/XHTML
attributes like id="" class="" xml:id="" and so on (instead of using
too many divs), to preserve as far as possible the original
semantical meanings of the DocBook markup and to give rich CSS
layout possibilities.

7. All graphics that will be used for navigation purposes or
admonitions will be handled by the CSS stylesheet. This will ensure
maximum functionality across various mediums and facilitate meeting
accessibility standards.


Thanks for everyone who has participated in this discussion so far.
Certainly a good example of the vibrant nature of the DocBook
community.

Later,
Rene

Thu, 28 Apr 2005

NB: overstroke and replaced (green) content by me (Nicolas R.)
You can see the original post at
http://www.cygwin.com/ml/docbook-apps/2005-q2/msg00343.html
and the whole thread at
http://www.cygwin.com/ml/docbook-apps/2005-q2/threads.html#00230



Here is my add-on to these guidelines: a road-map to attain these goals.

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

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. 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.

Of course, everybody is invited to participate to the debate, improve and criticize the guidelines and roadmap.
My next contribution will be a set of these desired XHTML outputs, with detailed explanations about what and why (focused on semantics in DocBook and XHTML, since, should I recall it, this is the first and main purpose of projects like DocBook).


Nicolas R.