Scott, it sounds as if you need to do
some work on the stage 2 proposal before it comes before the TC
for consideration. Let me know if you also need this back on the
agenda for "Pre-stage 2 proposal" discussion."
Kristen James Eberlein
Principal consultant, Eberlein Consulting
Co-chair, OASIS DITA Technical Committee
Charter member, OASIS DITA Adoption Committee
+1 919 682-2290; kriseberlein (skype)
On 6/24/2013 6:40 PM, Scott Hudson wrote:
Hi Robert, et al,
I've embedded my comments below [SH].
and best regards,
Schneider Electric | United States | Standards
970 282 1952 | Mobile: +1 720 369 2433 | Email: email@example.com
When reading the proposal it seems hard to distinguish
between what is
possible today and what is new. Can you fill out the
section of the template with an overview of the actual
changes to DITA?
[SH] I'll update the Proposed Changes section.
More generally, I think people unfamiliar with DITA
tables would read this
proposal and get the impression that tables cannot be
today. I'd like to note that using the DITA-OT today,
almost all of the
tables in your examples would generate HTML with all
associations. The only exception is table 3, which
uses multiple header
rows, because DITA doesn't yet provide a way to
identify that. I think it
would be good if the "use case" section was updated to
provide samples of
what cannot be done today.
[SH] I can update the examples as well, but wanted to provide
examples of how to use the proposed markup changes?
Apart from those issues, I have several more specific
comments / questions:
1. Minor item - though I like to focus on the DITA-OT
processing impacts should really be more general, as
the toolkit is just
one of many DITA tools out there
[SH] agree. It was in the template, so thought it was required
to be specific. I recommend updating the template. I will
generalize the sections in the proposal.
2. I'm not sure I understand why we would create
"summary" as an attribute
- in DITA 1.1, we deprecated all attributes with
translatable text and
created elements instead. So, I would expect that the
table summary should
follow that pattern. This shouldn't be an issue for
HTML, as any DITA
content rendered as HTML already has to undergo some
[SH] I thought about this as well, but was wary of adding a
new element. I agree with the move to use elements for
translation purposes, so will update the proposal to use a new
element. Question: should we follow the HTML5 approach and put
it in caption/detail/summary?
3. Are you suggesting that we add the @xml:id
attribute in addition to the
existing @id attribute? If so, is there a reason that
@id does not work?
[SH] xml:id would be more appropriate IMO, but I don't see
that using id would be a problem.
4. It looks like the code samples use DocBook rather
[SH] apologies. Copy/paste error since I'm asking for this in
both standards... will update.
5. In the "processing impact" section, I think it
would be good to point
out that tools which already automate the id/headers
association will need
to be updated to change that automation - presumably
author's manual selection instead of the automated
[SH] Good point. I'll add this clarification.
Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit (http://dita-ot.sourceforge.net/)
From: Scott Hudson <firstname.lastname@example.org>
Date: 06/24/2013 13:53
Subject: [dita] Groups - Proposal 62, Table
Accessibility (DITA Source)
Sent by: <email@example.com>
-- Mr. Scott Hudson
|Document Name: Proposal 62, Table Accessibility |
|(DITA Source) |
|Add attributes and elements to the table model |
|to enhance accessibility for |
|screen readers. |
|Download Latest Revision |
|Public Download Link |
|Submitter: Mr. Scott Hudson |
|Group: OASIS Darwin Information Typing |
|Architecture (DITA) TC |
|Folder: Drafts |
|Date submitted: 2013-06-24 10:52:16 |
|Revision: 0 |
This email has been scanned by the Symantec Email