Here is my response: Here's what I used for a test doc in OxygenXML Editor: <?xml version= 1.0 encoding= UTF-8 ?> <?xml-model href=
http://docbook.org/xml/5.1b8/rng/docbook.rng >http://docbook.org/xml/5.1b8/rng/docbook.rng schematypens=
http://relaxng.org/ns/structure/1.0 ?> <book xmlns =
http://docbook.org/ns/docbook xmlns:xlink =
http://www.w3.org/1999/xlink version = 5.0 > <chapter> <title> Chapter Title </title> <table frame = 'all' rowheader = 'firstcol' > <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> Name </entry> <entry> Age </entry> <entry> Birthday </entry> </row> </thead> <tbody> <row> <entry morerows = 1 xml:id = Natural > Daughters by birth </entry> <entry xml:id = Jackie > Jackie </entry> <entry> 5 </entry> <entry> April 5 </entry> </row> <row> <entry xml:id = Beth > Beth </entry> <entry> 8 </entry> <entry> January 14 </entry> </row> <row> <entry xml:id = Step > Daughters by marriage </entry> <entry xml:id = Jenny > Jenny </entry> <entry> 12 </entry> <entry> Feb 12 </entry> </row> </tbody> </tgroup> </table> </chapter> </book> Regarding the rowheader attribute, because it is already defined in DocBook, I think it will be difficult to adjust the context only for the colspec to have different values. I think we could interpret the existing values and output them properly in HTML if need be. For example, <colspec rowheader= headers > could be interpreted as yes , while norowheader could be interpreted as no . Do you think this would work? I think it's possible to do the content models in RelaxNG, but I think it will cause issues if we try to create a DTD version with the different values. I know it's a bit of semantic abuse to overload the meaning of headers and norowheader, but if we can make it work, I think it would be easier overall. Unfortunately, I think it will also be difficult to do the either/or scenario regarding the patterns (because of DTD considerations). I think we just have to document the appropriate best practices without being too constraining in the content model. Thanks and best regards, --Scott On Feb 21, 2013, at 4:34 PM, Scott Hudson <
scott.hudson@schneider-electric.com > wrote: FYI, here is some feedback on table accessibility changes. I'll forward my response to the list as well. --Scott Begin forwarded message: From: Nathalie Sequeira <
n@n-faktor.net > Subject: Re: DocBook v5.1b8, DocBook Publishers spec and table accessibility Date: February 21, 2013 4:55:05 AM MST To: Scott Hudson <
scott.hudson@schneider-electric.com > Reply-To:
n@n-faktor.net 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? 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 Feb 20, 2013, at 10:31 AM, Scott Hudson <
scott.hudson@schneider-electric.com > wrote: 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. 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 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? 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: Norman Walsh <
ndw@nwalsh.com > Subject: [docbook-tc] Quite publication of 5.1b8 and TDG 5.1 for b8 Date: December 29, 2012 2:00:44 PM MST To:
docbook-tc@lists.oasis-open.org 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 ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. ______________________________________________________________________