Fwd: OASIS DocBook Publishers Specification v1.1 (Working Draft v0.3) for review

[Scott Hudson <scott.hudson@schneider-electric.com>]

FYI.

Thanks and best regards,

--Scott
Scott Hudson   |   PELCO  by Schneider Electric   |   United States  |   Standards Lead 
Phone: +1 970 282 1952  |  Fax: +1 970 282 1950 | Email: scott.hudson@schneider-electric.com |   Site: pdn.pelco.com

Begin forwarded message:

From: Nathalie Sequeira <n@n-faktor.net>

Subject: Re: OASIS DocBook Publishers Specification v1.1 (Working Draft v0.3) for review

Date: March 12, 2013 2:19:53 AM MDT

To: Scott Hudson <scott.hudson@schneider-electric.com>

Reply-To: n@n-faktor.net

Hello Scott,

I think we all must have missed something? The actual row header values didn't change, right, you are suggesting the wording/ of the documentation is what needs to be changed, correct?

No no, all should be well!!
For reorientation, here a quick look back what we've been doing:

In the DocBook5.1b8, the rowheader attribute values were modified to include "headers" and to be applicable to the colspec in addition to the table element.

As you saw rightly, the model wasn't quite clear or bound to be as useful as it should.
Thus the suggestion to use "firstcol" as value on table@rowheader ONLY,
and "headers" as a value on colspec@rowheader only.

Since forcing either/or usage on table/colspec or exclusive use of the single attributes via schematron rules presents difficulties when transferred to the DTD version, we need clearly formulated indications as to the attributes' usage in the documentation.

So yes, I was just talking about the wording in the documentation, to give the new values clear roles for usage :)

Originally you had suggested "yes" | "no" values, which would have impacted the content model. I think we came to agreement not to change the values.

yes indeed, the values remain the same as last proposed, firstcol|headers|norowheader.

Are you also saying that the db.rowheader.attribute has not been added to colspec, but should be?

No, it HAS been added, and all is working well technically speaking, but we need to clarify the documentation.

I in turn was not sure whether the docBook Committee has approved these suggested changes to the documentation's wording, as the old, confusing, wording is still in place in the online documentation, and had also cropped back up in the last version of the publishers spec you sent me.

I am attaching my Usage guide that also contains the suggested changes to documentation wording as well as notes re XSLT change to-do's and would be thankful if you could pass this on to the docBook Committee too.
I hope that, in this way, we all can find ourselves on the same page again!

Venice was quite a bit cooler than I had expected, but we thoroughly enjoyed it! We also made it over to Padova and to Verona, so those were also very rewarding excursions!

Ahh sounds like a getaway well made use of! Good for you!

I'm proposing a concall for Thursday. Will you be able to attend?

Yes I'll gladly attend, just in case there are any open questions!

Thanking you and wishing you a fine week until then,
Nathalie

Thanks and best regards,

--Scott
Scott Hudson   |   PELCO  by Schneider Electric   |   United States  |   Standards Lead 
Phone: +1 970 282 1952  |  Fax: +1 970 282 1950 | Email: scott.hudson@schneider-electric.com |   Site: pdn.pelco.com

On Mar 6, 2013, at 11:56 PM, Nathalie Sequeira <n@n-faktor.net> wrote:

Hello Scott,

thanks for sharing the latest version!

I went through it quickly & detected a problem with the content model for rowheader, as it contains the old attributes description that references only the table@rowheader case.

My suggestion for rewording was:

-------------
db.rowheader.attribute =
 
  ## Indicates whether or not the entries in columns should be considered row headers
  attribute rowheader {
   
    ## Indicates that entries in the first column of the table are functionally row headers (analogous to the way that a thead provides column headers).
    "firstcol"
    |
      ## Indicates that entries of a column described via colspec are functionally row headers (for cases with more than one column of row headers).
      "headers"
    |
      ## Indicates that entries in columns have no special significance with respect to column headers.
      "norowheader"
  }  
  -------------
        

whereby today I would even be more explicit yet as to when which attribute is relevant (since even I, who should be well acquainted with the matter! almost overread the "subtle" wording hints "table" and "colspec" of my original suggestion).

Could something like this be done in the content model? This would probably be the clearest:

-------------
db.rowheader.attribute =
 
  ## Indicates whether or not the entries in columns should be considered row headers
  attribute rowheader {
   
    ## Indicates that entries in the first column of the table are functionally row headers (analogous to the way that a thead provides column headers). Applies when rowheader is used as a table attribute.
    "firstcol"
    |
      ## Indicates that entries of a column described via colspec are functionally row headers (for cases with more than one column of row headers). Applies when rowheader is used as a colspec attribute.
      "headers"
    |
      ## Indicates that entries in columns have no special significance with respect to column headers.
      "norowheader"
  }      
-------------


...Or has the docBook committe not approved our suggestions, including mine for changes to the documentation?

As to the XSL, I haven't gotten round to that yet but will let you know as soon as I do!
Thanks again,

Nathalie

P.S. hope your Venice excursion met all your expectations!     
           

Am 06.03.2013 20:47, schrieb Scott Hudson:

Folks,

I've incorporated Dick's comments. Please review the attached draft.

I'll schedule a meeting to discuss this draft and a few RFEs that have come up.

Please let me know your availability for the week of March 4 or March 11.

Thanks and best regards,

--Scott
Scott Hudson   |   PELCO  by Schneider Electric   |   United States  |   Standards Lead 
Phone: +1 970 282 1952  |  Fax: +1 970 282 1950 | Email: scott.hudson@schneider-electric.com |   Site: pdn.pelco.com

-- 
Nathalie Sequeira
************************
webseiten mit *n-faktor
robust*benutzbar*barrierefrei
www.n-faktor.net

Türingstr. 6
6020 Innsbruck
Mobil: 0650 224 3336
n@n-faktor.net

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
______________________________________________________________________

-- 
Nathalie Sequeira
************************
webseiten mit *n-faktor
robust*benutzbar*barrierefrei
www.n-faktor.net

Türingstr. 6
6020 Innsbruck
Mobil: 0650 224 3336
n@n-faktor.net

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
______________________________________________________________________

<?xml version="1.0" encoding="UTF-8"?>
<?oxygen RNGSchema="http://docbook.org/xml/5.1b8/rng/docbook.rng"; type="xml"?>
<?xml-stylesheet type="text/css" href="docbook5.1.css"?>

<article xmlns="http://docbook.org/ns/docbook";
    xmlns:xlink="http://www.w3.org/1999/xlink"; version="5.1b8"
    audience="main" 
    xml:lang="en">
    
    <info>
        <title>Accessible tables in docBook 5.1 using the expanded CALS table model</title>
        <author>
            <personname>Nathalie Sequeira</personname>
        </author>
        <date>2013-03-12</date>
        <abstract>
            <para>Usage guide to the expanded CALS table model in DocBook 5.1, with notes for
                documentation changes to enhance its usability.</para>
        </abstract>
    </info>
    <section>
        <title>Why do this?</title>
        <para>The increasingly widespread usage of texts in their digital form has hugely positive
            implications for the inclusion of people with disabilities. Access to information is
            becoming much easier, especially for blind people, since digital texts can be read
            directly by a screen reader without any extra manipulation (e.g. conversion to Braille,
            scannning textbooks so they can be read aloud by corresponding softwares, etc.).</para>
        <para>However, to guarantee that the blind user's experience is as smoothe as possible,
            certain helpers must be in place to facilitate navigation and the correct interpretation
            of a text by screen readers. Structural markup of headings, lists and tables, for
            example, are central to this. Thus, docBook innately already has much of what is needed
            in place to create texts that are universally accessible.</para>
        <para>In the specific case of tables, it is vital to attribute table headers to the table
            data. Where this is usually achieved visually by distinct header styles, someone who
            cannot see these cues will need programmatic indications of which cells contain headers,
            and how they relate to the data presented in the table. Without these semantic markers,
            screen readers will read table data linearly, that is, from left to right, row by row,
            thus making it very hard to understand the data and its interrelations.</para>
        <para>DocBook 5.1 and its official Publishers variant set out to offer this needed markup by expanding the CALS table model in
            such a way that these semantic relationships can be expressed and transferred to other
            formats the docBook is converted to, very similarly to how the HTML table model already
            can achieve this.</para>
        <para>The following walk-through shows the new possibilities of the CALS table model in use.</para>
    </section>
        <section remap="">
            <title>Walk-through by example</title>
            <para>In marking up a CALS table for screen reader accessibility, there are two steps to
            be taken, depending on the table structure's complexity:</para>
        <orderedlist>
            <listitem>
                <para>identify the table's headers</para>
            </listitem>
            <listitem>
                <para>explicitly associate table data with its headers</para>
            </listitem>
        </orderedlist>
        <section>
            <title>Identify the table's headers</title>
            <para>In very simple tables with only one row or column of headers, this mechanism alone
                is sufficient to allow screen readers to accociate data with its respective
                headers.</para>
            <section>
                <title>Identify column headers</title>
                <para>To identify column headers, the relevant rows are wrapped in the
                        <code>thead</code> element.</para>
                <table frame="all">
                    <title>example: a simple table with column headers</title>
                    <tgroup cols="3">
                        <thead>
                            <row>
                                <entry>Mark's points</entry>
                                <entry>Peter's points</entry>
                                <entry>Cindy's points</entry>
                            </row>
                        </thead>
                        <tbody>
                            <row>
                                <entry>11,123.45</entry>
                                <entry>11,012.34</entry>
                                <entry>10,987.64</entry>
                            </row>
                        </tbody>
                    </tgroup>
                </table>
<programlisting><![CDATA[
<table frame="all">
    <title>example: a simple table with column headers</title>
    <tgroup cols="3">
        <thead>
            <row>
                <entry>Mark's points</entry>
                <entry>Peter's points</entry>
                <entry>Cindy's points</entry>
            </row>
        </thead>
        <tbody>
            <row>
                <entry>11,123.45</entry>
                <entry>11,012.34</entry>
                <entry>10,987.64</entry>
            </row>
        </tbody>
    </tgroup>
</table>]]>
</programlisting>
                <para>Without any markup of the table headers, a sreen reader may just read the
                    table's contents as: <blockquote>
                        <para>Mark's points Peter's points Cindy's points 11,123.45 11,012.34
                            10,987.64.</para>
                    </blockquote> With the headers marked up, screen readers will attribute the
                    headers like this: <blockquote>
                        <para>Mark's points 11,123.45, Peter's points 11,012.34, Cindy's points
                            10,987.64.</para>
                    </blockquote> Clearly, the second variant is much more easily understood, and
                    thus well worth the little effort required to appropriately markup the table in
                    the docBook source.</para>                
            </section>
            <section>
                <title>Identify row headers</title>
                <para>DocBook now offers two alternatives to identify row headers in CALS
                    tables:</para>
                <itemizedlist>
                    <listitem>
                        <para>if only the first column contains row headers, set the
                                <code>rowheader</code> attribute to the <code>firstcol</code> value
                            in the <code>table</code> element.</para>
                        <table frame="all" rowheader="firstcol">
                            <title>example: a simple table with first row headers</title>
                            <tgroup cols="2">
                                <tbody>
                                    <row>
                                        <entry role="header">Mark's points</entry>
                                        <entry>11,123.45</entry>
                                    </row>
                                    <row>
                                        <entry role="header">Peter's points</entry>
                                        <entry>11,012.34</entry>
                                    </row>
                                    <row>
                                        <entry role="header">Cindy's points</entry>
                                        <entry>10,987.64</entry>
                                    </row>
                                </tbody>
                            </tgroup>
                            <caption><para>Captions are allowed!</para></caption>
                        </table>
                        <programlisting>
<![CDATA[
<table frame="all" rowheader="firstcol">
    <title>example: a simple table with first row headers</title>
    <tgroup cols="2">
        <tbody>
            <row>
                <entry>Mark's points</entry>
                <entry>11,123.45</entry>
            </row>
            <row>
                <entry>Peter's points</entry>
                <entry>11,012.34</entry>
            </row>
            <row>
                <entry>Cindy's points</entry>
                <entry>10,987.64</entry>
            </row>
        </tbody>
    </tgroup>
    <caption><para>Captions are allowed!</para></caption>
</table>]]>
                        </programlisting>
                    </listitem>
                    <listitem>
                        <para>if more than one column contains row headers, set the
                                <code>rowheader</code> attribute on the relevant
                                <code>colspec</code> declarations to <code>headers</code>.</para>
                        <table frame="all">
                            <title>example: a table with two columns of row headers</title>
                            <tgroup cols="3">
                                <colspec colname="c1" colwidth="1.0*" rowheader="headers"/>
                                <colspec colname="c2" colwidth="1.0*" rowheader="headers"/>
                                <colspec colname="c3" colwidth="1.0*"/>
                                <tbody>
                                    <row>
                                        <entry morerows="2" role="header">points</entry>
                                        <entry role="header">Mark</entry>
                                        <entry>11,123.45</entry>
                                    </row>
                                    <row>
                                        <entry role="header">Peter</entry>
                                        <entry>11,012.34</entry>
                                    </row>
                                    <row>
                                        <entry role="header">Cindy</entry>
                                        <entry>10,987.64</entry>
                                    </row>
                                </tbody>
                            </tgroup>
                        </table>
                        <programlisting>
<![CDATA[
<table frame="all">
    <title>example: a table with two columns of row headers</title>
    <tgroup cols="3">
        <colspec colname="c1" colwidth="1.0*" rowheader="headers"/>
        <colspec colname="c2" colwidth="1.0*" rowheader="headers"/>
        <colspec colname="c3" colwidth="1.0*"/>
        <tbody>
            <row>
                <entry morerows="2">points</entry>
                <entry>Mark</entry>
                <entry>11,123.45</entry>
            </row>
            <row>
                <entry>Peter</entry>
                <entry>11,012.34</entry>
            </row>
            <row>
                <entry>Cindy</entry>
                <entry>10,987.64</entry>
            </row>
        </tbody>
    </tgroup>
</table>]]>
                        </programlisting>
                    </listitem>
                </itemizedlist>
                <para>Note: the examples here are mere constructions to demonstrate docBook
                    functionaliy options. In the wild, the first variant would be preferred to the
                    second from an accessibility standpoint. Also, in the second example, the
                    spanned entry "points" would have to include a <code>scope="rowgroup"</code> to
                    make its attribution unmistakably clear (left out here for clarity's
                    sake).</para>
            </section>
        </section>
        <section>
            <title>Explicity associate table data with its headers</title>
            <para>This step is necessary for more complex tables, for example containing row AND
                column headers, multiple column header rows, or spanned entries.</para>
            <para>Analagously to the <abbrev>HTML</abbrev> model, DocBook <abbrev>CALS</abbrev>
                tables now offer two mechanisms to achieve this:</para>
            <itemizedlist>
                <listitem>
                    <para><code>scope</code></para>
                    <para>The scope attribute is used on table entries functioning as headers to
                        explicitly define the range of entries they apply to (a row, a column, a
                        row group, or a column group).</para>
                    <para>This method is best suited to tables of medium complextiy.</para>
                    <table frame="all" rowheader="firstcol">
                        <title>example: assuring complex table accessibility using
                                <code>scope</code>
                        </title>
                        <tgroup cols="3">
                            <colspec colname="c1" colwidth="1.0*"/>
                            <colspec colname="c2" colwidth="1.0*"/>
                            <colspec colname="c3" colwidth="1.0*"/>
                            <thead>
                                <row>
                                    <entry morerows="1"></entry>
                                    <entry namest="c2" nameend="c3" scope="colgroup">points</entry>
                                </row>
                                <row>
                                    <entry scope="col">expected</entry>
                                    <entry scope="col">actual</entry>
                                </row>
                            </thead>    
                            <tbody>
                                <row>
                                    <entry scope="row">Mark</entry>
                                    <entry>10,000</entry>
                                    <entry>11,123.45</entry>
                                </row>
                                <row>
                                    <entry scope="row">Peter</entry>
                                    <entry>9,000</entry>
                                    <entry>11,012.34</entry>
                                </row>
                                <row>
                                    <entry scope="row">Cindy</entry>
                                    <entry>10,000</entry>
                                    <entry>10,987.64</entry>
                                </row>
                            </tbody>
                        </tgroup>
                    </table>
                    <programlisting>
<![CDATA[
<table frame="all" rowheader="firstcol">
<title>
    example: assuring complex table accessibility using <code>scope</code>
</title>
<tgroup cols="3">
    <colspec colname="c1" colwidth="1.0*"/>
    <colspec colname="c2" colwidth="1.0*"/>
    <colspec colname="c3" colwidth="1.0*"/>
    <thead>
        <row>
            <entry morerows="1"></entry>
            <entry namest="c2" nameend="c3" scope="colgroup">points</entry>
        </row>
        <row>
            <entry scope="col">expected</entry>
            <entry scope="col">actual</entry>
        </row>
    </thead>    
    <tbody>
        <row>
            <entry scope="row">Mark</entry>
            <entry>10,000</entry>
            <entry>11,123.45</entry>
        </row>
        <row>
            <entry scope="row">Peter</entry>
            <entry>9,000</entry>
            <entry>11,012.34</entry>
        </row>
        <row>
            <entry scope="row">Cindy</entry>
            <entry>10,000</entry>
            <entry>10,987.64</entry>
        </row>
    </tbody>
</tgroup>
</table>]]>
                    </programlisting>
                    <para>As a bareboned table, it would be read by a screen reader like so:<blockquote>
                            <para>points expected actual. Mark 10,000 11,123.45. Peter 9,000
                                11,012.34. Cindy 10,000 10,987.64.</para>
                        </blockquote>which really does not make much sense at all. But by using the
                        markup as shown above, a screen reader will be able to see order in the
                        chaos and will read:<blockquote>
                            <para>Mark points expected 10,000 Mark points actual 11,123.45. Peter
                                points expected 9,000 Peter points actual 11,012.34. Cindy points
                                expected 10,000 Cindy points actual 10,987.64.</para>
                        </blockquote>While this leans slightly redundantly towards the verbose, it
                        is also by far more clear, allowing for quick understanding even if the
                        reader cannot see the table's spatial layout.</para>
                </listitem>
                <listitem>
                    <para><code>xml:id</code> and <code>headers</code></para>
                    <para>With this dynamic duo, a very granular association of table data to its
                        headers can be accomplished. The header entries are identified via
                            <code>xml:id</code> attributes, which are then referenced in the
                            <code>headers</code> attribute on data entries. </para>
                    <para>This method is best suited for very complex tables that cannot be
                        otherwise simplified.</para>
                    <table frame="all" rowheader="firstcol">
                        <title>example: assuring complex table accessibility using
                                <code>headers</code>
                        </title>
                        <tgroup cols="3">
                            <colspec colname="c1" colwidth="1.0*"/>
                            <colspec colname="c2" colwidth="1.0*"/>
                            <colspec colname="c3" colwidth="1.0*"/>
                            <thead>
                                <row>
                                    <entry morerows="1"></entry>
                                    <entry namest="c2" nameend="c3" xml:id="pts">points</entry>
                                </row>
                                <row>
                                    <entry xml:id="exp" headers="pts">expected</entry>
                                    <entry xml:id="act" headers="pts">actual</entry>
                                </row>
                            </thead>    
                            <tbody>
                                <row>
                                    <entry xml:id="name1" role="header">Mark</entry>
                                    <entry headers="name1 exp pts">10,000</entry>
                                    <entry headers="name1 act pts">11,123.45</entry>
                                </row>
                                <row>
                                    <entry xml:id="name2" role="header">Peter</entry>
                                    <entry headers="name2 exp pts">9,000</entry>
                                    <entry headers="name2 act pts">11,012.34</entry>
                                </row>
                                <row>
                                    <entry xml:id="name3" role="header">Cindy</entry>
                                    <entry headers="name3 exp pts">10,000</entry>
                                    <entry headers="name3 act pts">10,987.64</entry>
                                </row>
                            </tbody>
                        </tgroup>
                    </table>
<programlisting>
<![CDATA[
<table frame="all" rowheader="firstcol">
<title>
    example: assuring complex table accessibility using <code>headers</code>
</title>
<tgroup cols="3">
    <colspec colname="c1" colwidth="1.0*"/>
    <colspec colname="c2" colwidth="1.0*"/>
    <colspec colname="c3" colwidth="1.0*"/>
    <thead>
        <row>
            <entry morerows="1"></entry>
            <entry namest="c2" nameend="c3" xml:id="pts">points</entry>
        </row>
        <row>
            <entry xml:id="exp" headers="pts">expected</entry>
            <entry xml:id="act" headers="pts">actual</entry>
        </row>
    </thead>    
    <tbody>
        <row>
            <entry xml:id="name1">Mark</entry>
            <entry headers="name1 exp pts">10,000</entry>
            <entry headers="name1 act pts">11,123.45</entry>
        </row>
        <row>
            <entry xml:id="name2">Peter</entry>
            <entry headers="name2 exp pts">9,000</entry>
            <entry headers="name2 act pts">11,012.34</entry>
        </row>
        <row>
            <entry xml:id="name3">Cindy</entry>
            <entry headers="name3 exp pts">10,000</entry>
            <entry headers="name3 act pts">10,987.64</entry>
        </row>
    </tbody>
</tgroup>
</table>]]>
</programlisting>                    
                </listitem>
            </itemizedlist>
        </section>               
        </section>
    <section>
        <title>To do: Documentation</title>
        <para>To make the documentation clear concerning the different attribute values for
            rowheader depending on context, I suggest the following wording:</para>
        <section><title>docBook Schema / docBook Publishers Schema</title>
            <literallayout>
db.rowheader.attribute =
 
  ## Indicates whether or not the entries in columns should be considered row headers
  attribute rowheader {
   
    ## Indicates that entries in the first column of the table are functionally 
        row headers (analogous to the way that a thead provides column headers). 
        Applies when rowheader is used as a table attribute.
    "firstcol"
    |
      ## Indicates that entries of a column described via colspec are functionally
          row headers (for cases with more than one column of row headers). 
          Applies when rowheader is used as a colspec attribute.
      "headers"
    |
      ## Indicates that entries in columns have no special significance 
         with respect to column headers.
      "norowheader"
  }               
            </literallayout>
        </section>
        
<section>
    <title>The Definitive Guide</title>
    <para>Being as it is the definitive guide, it may be useful to include a usage guide along the lines of the one above. However, I could not find "the perfect spot" for this.</para>
            <para>The same changes are to be made in the appropriate spots of the DocBook Publishers
                Definitive Guide.</para>
    <section>
            <title>db.cals.table
                (<link xlink:href="">http://www.docbook.org/tdg51/en/html/cals.table.html</link>), and db.cals.informaltable (<link>http://www.docbook.org/tdg51/en/html/cals.informaltable.html</link>)</title>
            <glosslist>
                <glossentry>
                    <glossterm>rowheader</glossterm>
                    <glossdef>
                        <para>Indicates whether or not the entries in the first column should be
                            considered row headers</para>
                        <informaltable rowheader="firstcol">
                             <tgroup cols="2">
                                <thead>
                                    <row>
                                        <entry scope="col">Enumerated values</entry>
                                        <entry scope="col">Explanation</entry>
                                    </row>
                                </thead>
                                <tbody>
                                    <row>
                                        <entry scope="row">â??firstcolâ??</entry>
                                        <entry>Indicates that entries in the first column of the table are
                                            functionally row headers (analogous to the way that a thead
                                            provides column headers).</entry>
                                    </row>
                                    <row>
                                        <entry scope="row">â??headersâ??</entry>
                                        <entry>Do not use in the <code>table</code> context. (For
                                            use in the context of <code>colspec</code>
                                            only.)</entry>
                                    </row>
                                    <row>
                                        <entry scope="row">â??norowheaderâ??</entry>
                                        <entry>Indicates that entries in the first column have no special
                                            significance with respect to column headers.</entry>
                                    </row>
                                </tbody>
                            </tgroup>
                            
                        </informaltable>
                    </glossdef>
                </glossentry>
            </glosslist>
        </section>
        <section>
            <title>colspec
                (<link>http://www.docbook.org/tdg51/en/html/colspec.html</link>)</title>
            <glosslist>
                <glossentry>
                    <glossterm>rowheader</glossterm>
                    <glossdef>
                        <para>Indicates whether or not the entries in the specified column should be
                            considered row headers</para>
                        <informaltable rowheader="firstcol">
                            <tgroup cols="2">
                            <thead>
                                <row>
                                    <entry scope="col">Enumerated values</entry>
                                    <entry scope="col">Explanation</entry>
                                </row>
                            </thead>
                            <tbody>
                                <row>
                                    <entry scope="row">â??firstcolâ??</entry>
                                    <entry>Do not use in the <code>colspec</code> context. (For use
                                            in the context of <code>table</code> only.)</entry>
                                </row>
                                <row>
                                    <entry scope="row">â??headersâ??</entry>
                                    <entry>Indicates that entries in the specified column are
                                        functionally row headers (analogous to the way that a thead
                                        provides column headers).</entry>
                                </row>
                                <row>
                                    <entry scope="row">â??norowheaderâ??</entry>
                                    <entry>Indicates that entries in the column have no special
                                        significance with respect to column headers.</entry>
                                </row>
                            </tbody>
                            </tgroup>
                        </informaltable>
                    </glossdef>
                </glossentry>
            </glosslist>
        </section></section>
    </section>
    <section>
        <title>To do: XSL Transformations</title>
        <para>The following transformations are to be added:</para>
        <itemizedlist>
            <listitem>
                <para>HTML</para>
                <itemizedlist>
                    <listitem>
                        <para>if the colspec for an entry's column specifies rowheaders,
                                <code>entry</code> --> <code>th</code></para>
                    </listitem>
                    <listitem>
                        <para>assure that empty entries in row-or column-header groups are
                            transformed to empty <code>td</code>'s</para>
                    </listitem>
                    <listitem>
                        <para>transfer the <code>scope</code> and <code>headers</code> attribute
                            into the HTML as is.</para>
                    </listitem>
                </itemizedlist>
            </listitem>
            <listitem>
                <para>ePub?</para>
                <para>How must tables be marked up in ePub to be screen reader accessible?</para>
            </listitem>
            <listitem>
                <para>FO?</para>
                <para>How must tables be marked up in PDF to be screen reader accessible?</para>
                <itemizedlist>
                    <listitem>
                        <para>transform &lt;caption> elements</para>
                    </listitem>
                    <listitem>
                        <para>transform colspec-defined header columns (analagously to firstcol, as
                            already implemented?)</para>
                    </listitem>
                </itemizedlist>
            </listitem>
        </itemizedlist>
    </section>
             
 
</article>

Attachment: docbook5.1b8_tables.pdf
Description: Adobe PDF document