OASIS Darwin Information Typing Architecture (DITA) TC

Hi everyone,

I got some questions from Jarno about edge cases with simpletable elements, which led to some suggestions for the spec. I've got two simple ones and one that may need a bit more discussion.

First – it is possible to have a mismatch between the number of columns, and the number of columns specified in the relcolwidth attribute. For example, a three column table can specify relcolwidth="1* 2*". Can we update the spec to state that recovery for this case is implementation dependent?

Second – can we state that applications can treat it as an error if a simpletable has a different number of columns in some rows? In my experience, many tools already report this as an error, and in the <simpletable> element itself I think it's likely to always be an error. In DITA 1.x I've encountered specialized tables that allow for this by implying the use of a row-spanning cell, but with 2.x we can actually specify that now. While there may still be edge cases where <simpletable> content represents arbitrary data, where it is not rendered as a table, it seems like we could recognize that applications might treat mis-matched column numbers as an error.

Third – we really should clean up the language around keycol. We currently define / describe it three different ways:

Usage information: The @keycol attribute indicates the key column. A key column contains content that represents the key to the tabular structure.

Rendering information: When a key column is specified for a simple table, it is treated as a vertical header.

Attribute definition: Specifies the column that contains the content that represents the key to the tabular structure. If @keycol is present and assigned a numerical value, the specified column is treated as a vertical header.

I believe part of the problem is that the attribute definition is not directly on the page; there is a link to common attributes (because this and relcolwidth are used on many simpletable specializations). But this means we have three different descriptions, and really two different definitions (in Usage and Attributes).

Additionally, we have some issues with these definitions:

• The actual definition states "If @keycol [is] assigned a numerical value", implying that keycol="a" or keycol="foo" are valid. I don't think these have ever been valid (and if used, we actually don't define what it means).
• We also don't cover what happens for edge cases like keycol="8" on a four column table

I'd like to suggest cleaning it up as follows:

1. Move the keycol/relcolwidth definitions into the topic (and other specialized simpletable topics). This leads to more repetition, but I think it's worth it for the clarity.
2. Change the attribute definition to: "Specifies an integer between one and the number of columns in the table. The column that corresponds to that number is treated as a vertical header."
3. For usage, do not redefine the attribute, simply state that the attribute can be used to specify a vertical header
4. For rendering, just tweak the language to use the same terms added for the usage section

Thanks,

Robert