OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-tc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [docbook-tc] Enhancements proposed for CALS / OASIS Exchange table model for accessibility


Hi Scott,
I read through it all, and it seems the proposal is coming down to these changes:

1. Add @rowheader to the colspec element, with possible values 'yes' or 'no'. There is no default value, but absence of the attribute implies 'no'.

2. Add @ headers to entry, with allowed content being id values from within the table.

Is that right? If these additions are sufficient to meet the accessibility requirements, then they seem fine to me.

We would need to clarify how certain cases are to be handled.  I can think of two:

a. If a table has rowheader="firstcol" and the colspec for column1 in that table has an explicit rowheader="no", I presume the colspec has precedence?

b. If an entry in a given row spans multiple columns, I presume the first column in the span determines whether the entry is a rowheader?

Bob Stayton
Sagehill Enterprises
bobs@sagehill.net


----- Original Message ----- From: "Scott Hudson" <scott.hudson@schneider-electric.com>
To: "DocBook Committee" <docbook-tc@lists.oasis-open.org>
Sent: Thursday, June 21, 2012 4:49 AM
Subject: [docbook-tc] Enhancements proposed for CALS / OASIS Exchange table model for accessibility


Folks, please see the thread below regarding the discussions I've been
having with Nathalie on CALS/Exchange table enhancements.

I'd appreciate your opinions on the matter.

Thanks and best regards,

--Scott

Scott Hudson |  Pelco by Schneider Electric | United States | Standards Lead
Site: pdn.pelco.com | scott.hudson@schneider-electric.com




------ Forwarded Message
From: Nathalie Sequeira <n@n-faktor.net>
Reply-To: <n@n-faktor.net>
Date: Thu, 21 Jun 2012 11:13:17 +0200
To: Scott Hudson <scott.hudson@schneider-electric.com>
Subject: Re: [docbook-publishers] Schema, and version?

Hello Scott,
thanks for the quick update regarding the TC's support of these changes,
which is quite excellent!

As to sharing my thoughts on the docbook-tc list, please do not hesitate
to use my contributions in any way you may find useful for advancing the
matter.

------------
@rowheader
Following your thoughts regarding this, my interpretation of this
attribute as it stands now in docBook is that it fulfills the purpose of
marking a (i.e., the first) column's entrys to have the functionality of
row headers, kind of like <thead> does that for col headers in rows.

I think this functionality per se is important to maintain separately,
given that any element can sport a xml:id for the diversest of reasons -
and therefore cannot be used to unmistakably mark an entry as a header
cell.
Thus, we will always need two things:
1. a mechanism to identify which entrys have the *function of headers*
(thead for column headers and -- something similarly flexible for the
row headers)
2. a mechanism to *express the semantic relationships *between headers
and data  (= xml:id + headers)

HOW row headers are to be marked effectively IMO is definitely open to
discussion, given its shortcomings (or even non-existence in the CALS
specs!) as-is.
I VERY much like your idea of  having an attribute in the colspec that
marks each col in lieu of the table@rowheader, since colspec@rowheader
would give us a yesorno attribute that can be applied to whatever amount
of cols is necessary on a case by case basis, making it much more
flexible than at present. Also, it is a much more adequate place to
define this, given the column-specific descriptive nature of <colspec>.

So the only caveat about changing how header-function identification
occurs could be backward compatibility?

------------
@headers
thinking it over, I am becoming increasingly certain that ONLY the
xml:id's should be able to be referenced here, leaving colspec@colname
quite out of the equation.
This because a column can have multiple headers (e.g. a 2-tiered column
header structure) and just referring to the @colname could cause ambiguity.

That also means that colspec@colname would continue to have the
exclusive function of defining spans via @namest and @nameend (and
assigning entrys to columns where necessary via entry@colname).
-------

I will keep you updated on what I hear about the @scope question!
Best regards,

Nathalie


Scott Hudson schrieb:
Nathalie,

thanks again for the thorough response.

I would agree with the usefulness of @scope. I'm not convinced it is useful
either.

I'm also a bit concerned with the rowheader proposal, as it appears to be
hard-coded and thus not scalable. I thought the idea was to actually provide
the id of the col that was a header? Otherwise, there is the @cols in tgroup
that provides the number of columns? Perhaps it would be better to have some
attribute in the <colspec> that identifies it as a header?

As you state, we do not want a semantic conflict. I would rather err on the
side of explicit references to IDs.

If you don't mind, I'd like to forward this discussion to the docbook-tc
list? Please let me know if this is OK.

Thanks and best regards,

--Scott

Scott Hudson |  Pelco by Schneider Electric | United States | Standards Lead
Ph: +1-970-282-1952  | M: +1-720-663-7268 | Site: pdn.pelco.com |
scott.hudson@schneider-electric.com




On 6/20/12 9:08 AM, "Nathalie Sequeira" <n@n-faktor.net> wrote:


Hello Scott,
though it does take me to the outer edge of my knowledgeability, here is
my take on your proposal (hoping none of it is foolishly ignorant):

------------
First off and on a more general note, I was a bit confused concerning
the Exchange model :
I have been using the docBook 5.0 reference for structural information
on CALS, and it seems to base itself upon the 1995 CALS model
(http://docbook.org/tdg5/en/html/cals.table.html) - given the Exchange
model is the "newest" regarding CALS (but seems to exclude elements
included in docBook such as tfoot), there may be some harmonizing to be
done here...?

Either way, what I found irritating is that rowheader does not seem to
be included in either model - where, then, does docBook take its
inclusion from?

------------
@ scope

As I am personally not convinced of its real usefulness (and thus
whether it should even be included into the CALS model), I have now
posted a question regarding this to the Web2.0 accessibility forum on
linkedIn, in which quite some top notch accessibility experts
participate. I hope to get some feedback regarding this in the next few
days.

-----------
@rowheader

As described in the docBook 5.0 documentation, rowheader has the
shortcoming of only being able to mark the first column as containing
headers. To make this truly useful, rowheader would need to be able to
also name a second column as such (three-tiered row headers IMHO seem to
be overkill, but I HAVE seen such in the wild.. not sure whether one
should cater to these too).
Since in cases of row headers in the second column there will most
certainly also be row headers in the first (analogously this also hold
true for the 3rd), I would thus suggest an expansion of the
possibilities along the lines of

    rowheader (norowheader|firstcol|twocols|?threecols?) #IMPLIED

whereby as mentioned above I'm not sure where the docBook values
originate from in the first place.

While this would establish a header infrastructure similar to that of
<thead>, I am not 100% sure that this mechanism would satisfy real world
requirements in terms of specificity since it marks the whole column
(including rows that are in themselves also column headers) as header
information.

-----------
@ headers
I think this is excellent and, together with xml:id, will provide a
flexible infrastructure for all kinds of semantic relationships in
complex tables.
Unconditional YES here!

--------------------------
@ "Perfect world" example

well, maybe not perfect yet, but on its way, I've marked up the
"complex" example how it could look with the revisions:

            <table frame='all' rowheader='twocols'>
                <title>'Shelly's Daughters' in CALS Markup</title>
                <tgroup cols='4'>
                    <colspec colname='provenience'/>
                    <colspec colname='name'/>
                    <colspec colname='age'/>
                    <colspec colname='birthday'/>
                    <thead>
                        <row>
                            <entry> </entry>
                            <entry xml:id="name">Name</entry>
                            <entry xml:id="age">Age</entry>
                            <entry xml:id="birthday">Birthday</entry>
                        </row>
                    </thead>
                    <tbody>
                        <row>
                            <entry morerows="1"
xml:id="natural">Daughters by birth</entry>
                            <entry xml:id="Jackie" headers="natural
name">Jackie</entry>
                            <entry headers="natural Jackie age">5</entry>
                            <entry headers="natural Jackie
birthday">April 5</entry>
                        </row>
                        <row>
                            <entry xml:id="Beth" headers="natural
name">Beth</entry>
                            <entry headers="natural Beth age">8</entry>
                            <entry headers="natural Beth
birthday">January 14</entry>
                        </row>
                        <row>
                            <entry xml:id="step">Daughters by
marriage</entry>
                            <entry xml:id="Jenny" headers="step
name">Jenny</entry>
                            <entry headers="step Jenny name">12</entry>
                            <entry headers="step Jenny birthday">Feb
12</entry>
                        </row>
                    </tbody>
                </tgroup>
            </table>

What I'm not sure about here:
- should @headers ALWAYS refer to xml:id? I tend towards yes, however,
the existence of colspec@colname does open the door to thoughts of
making use of that in simpler cases...
As far as I understood, referencing the @colname from within an entry
currently positions the entry in that column (IMO enabling the creation
of malformed table structures? This makes the use of colname at all a
bit iffy to my mind... so it may be preferable not to name the columns
via colspec at all, only giving them colnums, and instead only use the
xml:id for header attribution)

- if we mark the second column as headers with a hypothetical "twocols"
value, will that not also include the header "Name", making "Name" a row
header for "Age" and "Birthday"...
That would be nonsense...but kind of already holds true for firstcol
cases. So I may be overthinking here --- if the potential semantic
conflict is no problem in the first col, it won't be one in the second
either? :)

------------

I hope this helps and wish you a very productive meeting today!
Nathalie



Scott Hudson schrieb:

Nathalie,

thank you for your quick and thorough response! Based on your feedback, here
is what I'm planning to recommend, based on the model as listed here:
https://www.oasis-open.org/specs/tr9503.html

<! ENTITY % tbl.entry.scope "scope (row|col)  #IMPLIED">
<! ENTITY % tbl.entry.headers "headers (#PCDATA)  #IMPLIED">
<! ENTITY % tbl.entry.att      "(%tbl.entry.scope; %tbl.entry.headers;)">
<!ENTITY % tbl.table.att        "
    pgwide      %yesorno;       #IMPLIED "
    rowheader   NMTOKEN         #IMPLIED ">

I think xml:id is allowed on every element, so not sure anything needs to be
changed to allow it explicitly?

Any other additions/changes you would recommend?

Can you provide a "perfect world" markup example using CALS/OASIS Exchange
(showing what the table would look like with the desired attributes added to
OASIS Exchange)?

Thanks and best regards,

--Scott

Scott Hudson |  Pelco by Schneider Electric | United States | Standards Lead
Ph: +1-970-282-1952  | M: +1-720-663-7268 | Site: pdn.pelco.com |
scott.hudson@schneider-electric.com




On 6/19/12 1:16 AM, "Nathalie Sequeira" <n@n-faktor.net> wrote:



Hello Scott,

thank you for your continued pursual of this issue!


What about namest and nameend? Please see
http://www.docbook.org/tdg5/en/html/entry.html

Do those provide enough of the semantics?



While I do see that namest and nameend could be used as attributive
markers on col-spanned entries, they can ONLY be used for those and
would reference columns only (possible row headers cannot be tied in via
these).
So I would say that no, these unfortunately do not fulfill the purpose
of enabling the expression of multidimensional relationships of headers
to the content of entry's.



 Also, I'm wondering if we even
need to have scope, since the column headers should be in thead/row/entry
and the rows can be determined in tbody/row



Personally, I feel that "scope" (in HTML) has a certain redundancy,
given that screen readers seem to understand simple table relationships
by means of appropriate header markup, and the id+headers method is far
more efficient when it comes to complex data.
So IMHO this is not something that needs revision in the CALS model,
given the existence of colspec/thead for column headers and the
rowheader-attribute for first-tier row headers. These set up a sort of
implicit relationship to the data cells and thus allow a corresponding
transformation that is sufficient for guaranteeing the accessibility of
simple, linear tabular data. (as always, I speak for HTML, not knowing
enough of PDF or other formats to presume anything there).

However, it does get tricky as soon as we have anything more complex. Of
course, it is always recommended that table structures be simplified to
increase accessibility, but when can we really do that in the real
world, given that would mean editing the original text? And sometimes
even if we could, data remains complex and its tables will unavoidably
be so too.
So:
- yes, namest and nameend could - possibly & with a bit of XSL effort -
cater to colspanned entry's
- but what about row-spanned ones? (I just can't imagine how morerows
could be used effectively... but then again, I'm no XSL guru and there
just may be some erudite way of achieving this?)
- and what about those seemingly "innocent" entry's that make up a
simple table cell, which however may be semantically related to multiple
headers?
- not lastly, what about second-tier row headers, which seem to not be
possible at all in CALS?

I have gone ahead and marked up the more complex HTML example in CALS
and have added it to my explanation:
http://n-faktor.net/featured/docBook_tables.html#cals
Perhaps my walk-through of the direct code comparison makes it more
clear what CALS simply cannot achieve.

As said, I think the crux of the issue is that CALS really seems not to
have been designed to express semantic relationships, but rather is
focussed on providing mechanisms to define visual presentation. Because
of this, (mis-)using any existing options will always be prone to
failure regarding semantics, not because they are badly designed but
simply because they were conceived with something else in mind.

Therefore, I would intuit that CALS needs a new mechanism to be able to
effectively express the semantics of tabular data.
Of course, it would be ideal to be able to melt BOTH functions -
semantic and visual -  into single bits of code capable of achieving
both, instead of just sticking something new onto the CALS model as is.
I'm guessing however that semantics would be the wiser place to start to
achieve this.

I hope this helps, otherwise please do ask back and I will do my humble
best to answer.
Best regards,
Nathalie








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

------ End of Forwarded Message


---------------------------------------------------------------------
To unsubscribe, e-mail: docbook-tc-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: docbook-tc-help@lists.oasis-open.org





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]