|Thanks, Nancy, Dave, and Jang for your comments.|
I completely agree that the CALS markup probably isn't what I would've designed, and if the consensus on the TC has changed since we discussed this as a Phase 2 proposal last July, then we should re-address these issues. What's in the current Phase 3 proposal represents what was approved in Phase 2, and I think with good reason.
Currently, the DITA table model is a proper subset of CALS; a DITA table is a CALS table with a few optional things missing, and a few added attributes, like @class, that make the markup DITA without affecting table functionality. As such, the consensus back in July was that there is greater value in remaining compatible with CALS than in attempting to address the shortcomings of the CALS implementation of these features. Tool vendors that have developed rotation support in CALS will be able to support these new features in DITA at little or no cost. In Arbortext Editor, for example, if you add @rotate to an <entry> element in a DITA document, it just works (in published output). Existing CALS-to-HTML or CALS-to-FO stylesheets that implement these features will likewise be able to support these features in DITA without any changes. Diverging from CALS would require tool and stylesheet developers to write DITA-specific table processing for reasons that are largely (though not entirely) aesthetic.
The minutes for the Phase 2 discussion are here: https://www.oasis-open.org/committees/download.php/46444/minutes20120703.txt
On Jan 7, 2013, at 5:34 AM, Jang F.M. Graat <firstname.lastname@example.org
here's my 2 cents:
Although following the CALS model is a good idea in itself in view of interoperability, that model is a little flawed and could use some slight revision, which could/should already be incorporated in DITA. The flaw is in the limitation of rotation to either no rotation or 90 degrees counterclockwise. In various situations, also having the option of 90 degrees clockwise rotation might be better. I would not limit the use cases to one rotation direction, for either attribute. How to define these options could be made clearer by allowing a text string: empty string is no rotation. "left" is 90 degrees counterclockwise and "right" is 90 degrees clockwise. It is simply how you rotate your head to be able to read the text, isn't it ?
Also, I would have opted for a "rotate" attribute for both the table and the single entry inside a table. That would be so much easier to explain and it does follow minimalist principles of keeping the number of entities down to a minimum.
Technical Documentation Specialist
Amsterdam - Netherlands
Tel. +31 20 755 8466
Cell +31 6 5478 1632
On 7 jan. 2013, at 03:44, Nancy wrote:
[note; I originally sent this to the TC list via my regular email account a few hours ago, but it didn't show up, so I'm sending it through the OASIS web site; if it ends up showing up twice, my apologies.]
After looking at #13078, I have the following comments
table[@orient] - Like David, I also wonder if 'port' and 'land' are the right names for these attribute values. I noticed David suggested using the full words portrait/landscape, but there's also the fact that if a document is itself in landscape mode, either of those variants would be confusing. Maybe 'standard' or 'normal' and 'rotate'? That would connect this with the entry/@rotate attribute as well.
Other than that, I like David's suggestion of adding the text from the original proposal back into the spec language.
entry[@rotate] - I agree with David; rather than '1' and '0', I'd prefer to use 'yes' and 'no'. Most users are neither mathematicians nor engineers.
Thanks, Chris, for getting the implementation out.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Oberon Technologies, Inc.
2640 Wildwood Trail
Saline, MI 48176