Reply To: Validating CALS tables

[Derek Read]

I'm a bit confused by that oXygen error message. The screenshot shows that in the tgroup @cols=”2″ so there are two columns. There are also 2 elements (so that's consitent). There are two rows and each row has two entry elements (so number of entry elements matches the colspec). I do not see anything that would indicate there are more than 2 cells. Oddly, the error also says something about “row (3)” but there are only two rows shown in this table.

I could imagine a scenario where some authoring tool allowed you to create a table that has too many entry elements in a row, and perhaps that would not be caught by standard XML validation (with DTD). Is that the issue you are trying to show here? Under normal circumstances that would be extremely difficult to do while authoring in XMetaL Author. To do that I think it would be necessary to switch to Plain Text view and then either manually type in the angle brackets, the element name and other things. Is that something your users need to do? We typically don't see people working with tables that way. Editing in Tags On or Normal view is preferred because the table is rendered as a table and all the various editing features for adding/removing/moving rows and columns make editing easy.

Putting that aside, which transtype are you using that has issues with @morerows?

It sounds to me that if there is an issue with an output transtype when valid XML / DITA / CALS) is passed to it (in the case of the @morerows values) that the issue is with the transformation process itself (ie: there's a bug with the DITA OT transtype). Rather than try to detect and try to avoid issues that trigger a bug in a transtype doesn't it make more sense to log them as bugs with the DITA OT project so they can be corrected?

Reply