Hello Scott,
I am terribly sorry for the enormous, but unfortunately unavoidable,
delay of my response!
My idea was to test the possibilities opened by the the new options,
also seeing how they then transform to HTML, but I have just not had
that kind of time.
I have now taken a quick first look, especially at the issue you
pointed out.
I'm not sure I am doing this correctly - I have simply changed my
namespace declaration in a test doc to the beta version like so:
<book xmlns=
"http://docbook.org/ns/docbook"
xmlns:xlink=
"http://www.w3.org/1999/xlink" version="5.1b8">
but it seems if I do it this way anything goes (may very well be my
error too, so if I should take a different approach to testing this
please let me know!):
I) I can add the rowheader attribute to the table element as well as
to the colspec.
This is confirmed by the declarations, eg. in the .rnc on lines:
8489 for cals.table,
8589 for cals.informaltable, and
8202 for colspec.attlist.
As you rightly saw, however, the options declared universally for
the rowheader attribute do NOT make sense in the <colspec/>
context, where "yes" or "no" would indeed do the job, making it
possible to declare the presence of rowheaders flexibly column by
column.
(Just as multiple rows within the <thead/> are already a
flexible mechanism for declaring column headers).
"firstcol | headers | norowheader" only make sense in the
<table/> context, where, while declaring a "headers" method
there may add clarity in some (?) way, it does not add functionality
- a functionality that is provided by the xml:id/ headers attributes
themselves.
In my setup, I can use headers without this declaration (and would
want to be able to, too, since I may have a complex table that
doesn't use rowheaders and still need this kind of semantic
attribution for clarity).
Also, headers can (and should be able to) be used even if
rowheaders="firstcol" is declared.
This makes the additional "headers" value seem rather redundant?
II) In my present setup, I can add the rowheader attribute to both
elements concurrently (I think we had discussed that it would be
better to have a mandatory either/or choice to reduce error
proneness?)
Since having the rowheaders attribute in the the <colspec/> is
so much more versatile while covering the old <table/>-context
alternatives, I would even go so far as to suggest deprecating
rowheader as a cals.table attribute in the midterm.
With respect to this, I think it may be a good idea to think about
what different methods are actually being enabled and how they are
allowed to be mixed.
1. "classic"
Using <thead/> and table@rowheaders="firstcol", a rudimentary
semantic relationship between table headers and data can be
established.
2. <thead/>-rows and <colspec/>-rowheaders
This method allows a simple but flexible way of establishing
semantic relationships for linear tables.
And to my view, looks like the successor to the "classic" approach
which could be phased out without any losses at all.
2a. <thead/>-rows, <colspec/>-rowheaders, and
xml:id/headers attribution
Allows for the establishment of semantic relationships in more
complex tables, especially such containing spanned entries.
2b. <thead7>-rows, <colspec/>-rowheaders, and scope
Also good for more complex tables, and simpler in implementation
than xml:id/headers
III) Lastly, (and this makes me think I really must be doing
something wrong in my testing, since I could not find anything in
the .rnc to make this valid!): I can actually use the "yes" and "no"
options in <colspec/> as well as <table/> (!) without
the document becoming invalid.
---
So much for a first feedback on the, agreed!, most pressing issue
regarding the CALS table changes.
I would very much appreciate a pointer for checking whether I am
testing correctly, and will then proceed to look at the new
possibilities more in depth!
Thanks and kind regards,
Nathalie
Am 20.02.2013 18:46, schrieb Scott
Hudson:
FYI, the only issue I see is:
db.rowheader.attribute =
## Indicates whether or not the entries in the first column 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 row headers are identified by use of the headers attribute on entries in the table.
"headers"
|
## Indicates that entries in the first column have no special significance with respect to column headers.
"norowheader"
}
In the publishers spec, we had said we would have possible
values of 'yes' or 'no'. Do you think it's a problem to use
the definition as stated above, or should I press for the
'yes' or 'no' values?
Hi Nathalie,
Have you had a chance to look at this yet? Do you
have any feedback? I have the DocBook TC meeting today
and they are waiting for feedback on the model before
they are willing to release DB 5.1.
On Jan 23, 2013, at 1:20 AM, Nathalie Sequeira
<
n@n-faktor.net>
wrote:
Hello Scott,
that is excellent! I shall look at it as soon as
possible (most probably this weekend) and then let
you know.
Thanks and a good week to you
Nathalie
Am 22.01.2013 17:13,
schrieb Scott Hudson:
Nathalie,
Norm has included the accessibility items
into DocBook 5.1b8.
It looks ok to me, but can you please take
a look as well and let me know if you find any
problems?
Begin forwarded message:
Subject:
[docbook-tc]
Quite publication of 5.1b8 and TDG
5.1 for b8
Date:
December 29, 2012
2:00:44 PM MST
Hi folks,
I just published 5.1b8 and the
accompanying documentation on
docbook.org.
Before I make any sort of public
announcement, I'd appreciate it if
someone would take a look and point out
any errors they find.
Be
seeing you,
norm
--
Norman Walsh <
ndw@nwalsh.com>
| I was born not knowing and have
http://www.oasis-open.org/docbook/
| had only a little time to change
Chair, DocBook Technical Committee |
that here and there.--Richard
|
Feynman