Bugs in CALS Table processing ?

Having trouble installing Oxygen? Got a bug to report? Post it all here.
Pascale
Posts: 40
Joined: Wed Jan 29, 2014 4:30 pm

Bugs in CALS Table processing ?

Post by Pascale »

Hi

I think I discovered a few bugs in the CALS Table processing (in DITA or custom DTD).
My concern is about preserving the table geometry (a table should be a rectangular grid) and the usage of column names.
In CALS tables, this is related to the colspec elements, the @colname attribute on colspec, and the @colname, @namest or @nameend attributes on entry elements (the cells).

When a column is inserted or deleted, the Oxygen Author correctly inserts or delete the corresponding colspec, and the corresponding cells. If it is an insertion, the new colspec element gets a value like newColX for the @colname attribute and the new entry elements have no @colname attribute, which is fair enough because it is optional and inherited from the corresponding colspec. So far, so good.

However, if I rename the @colname of a colspec, that change is not propagated to the corresponding cells: in other words, if the entry elements in that column have their @colname explicitely set, that attribute value is not updated. Even worst, if I have a horizontal span (merged cells) that starts or ends in the modified column, the corresponding @namest or @nameend attribute is not updated and the span is then displayed as a single cell with some greyed area on the left or right side to show "missing cells". In addition, this mismatch in column names is not detected by the validation.

Second problem: if I paste a row from 1 table to another table, both tables having the same number of columns but different column names, the paste action is successful and, again, validation does not report the column names mismatch.

Third problem: why is there a "insert a cell" action ? There is no "delete a cell" and simply adding a cell (without adding the column and colspec) will compromise the table geometry (the table is not a rectangle anymore).

Thanks for any feedback,
Pascale
alex_jitianu
Posts: 1007
Joined: Wed Nov 16, 2005 11:11 am

Re: Bugs in CALS Table processing ?

Post by alex_jitianu »

Hello,

As far as the validation goes, we already have a recorded issue to catch these type of error using Schematron. Until we resolve the issue though, there is an Open Source project done by Delta XML about CALS Table validity. You can get the Schematron files from there, create a validation scenario that applies them on the document, and check it they catch these validity problems.

First problem: Renaming a @colname is not handled any different than any other attribute. I'll add an issue to try and handle this case. Meanwhile, you can handle this situation yourself by adding an AuthorListener, listening on attributeChanged(AttributeChangedEvent e) and renaming in the whole table when a @colname changes on the colspec. There's a sample on how to add an AuthorListener available here.

Second problem: I'll add an issue to see what we can do in these situations. Right now, if you copy a column we always drop these attributes. We'll check and see what we can do when copying a row. Either drop these attributes if you paste in a different table or ideally, remap them.

Third problem: I guess you'll need this action if you dynamically restructure a table. For example you have a cell that spans on multiple columns or rows and you change it not to span anymore. The next step would be to insert some cells to compensate for the previous action. Fortunately, these actions are configurable from the Document Type so, if you don't want to present them to users, you can just remove them from menus or toobars.

Best regards,
Alex
Pascale
Posts: 40
Joined: Wed Jan 29, 2014 4:30 pm

Re: Bugs in CALS Table processing ?

Post by Pascale »

Hi Alex,

thanks for the feedback.
We are looking forward for an improved table processing in Oxygen; do you have an idea of the timeline ?
In the meantime, I will have a look at CALS Table validity ...

Best regards,
Pascale
alex_jitianu
Posts: 1007
Joined: Wed Nov 16, 2005 11:11 am

Re: Bugs in CALS Table processing ?

Post by alex_jitianu »

Hi Pascale,

I've registered the issues for version 16. Unfortunately there isn't much time left before v16 release so I can't guarantee they will make into it (other issues might be considered more critical). I've added your email address on the issue so you will be notified when it gets implemented.

Hopefully the Schematron validation will prove helpful.

Best regards,
Alex
Pascale
Posts: 40
Joined: Wed Jan 29, 2014 4:30 pm

Re: Bugs in CALS Table processing ?

Post by Pascale »

Hi Alex,

1. I upgraded to Oxygen v15.2 and indeed the expression defined in the "test" attribute of the assert/report rules do not appear anymore in the error message window. Great!

2. yes, the open-sourced Schematron is really useful!
I added the table validation cals.sch as non-automatic in my validation scenario, and it runs well when activating the Validate menu (Ctrl-Shift-V).

However, I was hoping that the error window would allow me to group the messages by the phase defined in the Schematron, but this is not the case: the 2 groups that appear by default are validation by the DTD and validation by the scenario (where I have several Schematrons, in addition to the cals.sch).
Apparently, the "Group By Resource" and "Group By System ID" are related to the file that is validated, not to the validation file; and the "Group By Operation description" makes only the distinction between the DTD and the scenario.
Should I define a scenario for each shematron file instead of grouping them all in the same scenario ?

Pascale
alex_jitianu
Posts: 1007
Joined: Wed Nov 16, 2005 11:11 am

Re: Bugs in CALS Table processing ?

Post by alex_jitianu »

Hi Pascale,

2. So you would like to group together the messages from each Schematron file? Currently, like you've noticed, the "Group By Operation description" actually refers to the type of schema from which the errors were received: DTD, XSD, Schematron.

If you put each Schematron file in its own validation scenario then the error messages should be presented like you want.

Best regards,
Alex
mihaela
Posts: 489
Joined: Wed May 20, 2009 2:40 pm

Re: Bugs in CALS Table processing ?

Post by mihaela »

Hi,

Just to update this thread: starting with Oxygen version 18, some table layout problems are automatically reported for DITA and Docbook documents on validation.

For example, here are some types of errors reported for CALS tables:
- A row has fewer cells than the number of columns detected from the table cols attribute.
- A row has more cells than the number of columns detected from the table cols attribute.
- A cell has a vertical span greater than the available rows count.
- The number of colspecs is different than the number of columns detected from the table cols attribute.
- The number of columns detected from the table cols attribute is different than the number of columns detected in the table structure.
- The value of the cols, rowsep, or colsep attributes are not numeric.
- The namest, nameend, or colname attributes point to an incorrect column name.

Best Regards,
Mihaela
Mihaela Calotescu
http://www.oxygenxml.com
fsteimke
Posts: 80
Joined: Tue Jan 01, 2013 3:19 pm

Re: Bugs in CALS Table processing ?

Post by fsteimke »

Hi,

i think there is an issue with the validation of CALS tables. I get errors for tables which are correct.

I have a CALS Table in my DocBook 5.0 file like this:

Code: Select all


<table version="5.0" xmlns="http://docbook.org/ns/docbook" >
<info>
<title>Aufgaben und Zuständigkeiten der Betreiber</title>
</info>
<tgroup cols="4">
<colspec colnum="1" colname="nr" colwidth="1*"/>
<colspec colnum="2" colname="aufgabe" colwidth="7*"/>
<colspec colnum="3" colname="itnrw" colwidth="1*" align="center"/>
<colspec colnum="4" colname="kosit" colwidth="1*" align="center"/>
<spanspec spanname="s12" namest="nr" nameend="aufgabe"/>
<spanspec spanname="s14" namest="nr" nameend="kosit" align="center"/>
<thead>
<row>
<entry spanname="s12">Aufgabe</entry>
<entry>IT.NRW</entry>
<entry>KoSIT</entry>
</row>
</thead>
Validation gives me the Error A row has fewer cells than the number of columns detected from the table cols attribute for the row in thead. Well, there are only three entries for four columns, but since there is a @spanname Attribute for the first entry, the row covers all four cells.

Validation does not consider the spans which are declared by spanspec?

Sincerely,
Frank Steimke
Radu
Posts: 8991
Joined: Fri Jul 09, 2004 5:18 pm

Re: Bugs in CALS Table processing ?

Post by Radu »

Hi Frank,

I tested your sample and it seems that it is already fixed in the last Oxygen 18.1 kit available for download on our web site:

https://www.oxygenxml.com/build_history.html
DocBook: The DocBook CALS table validation now properly takes into account the span information from tables that use the "spanspec" element.
Regards,
Radu
Radu Coravu
<oXygen/> XML Editor
http://www.oxygenxml.com
fsteimke
Posts: 80
Joined: Tue Jan 01, 2013 3:19 pm

Re: Bugs in CALS Table processing ?

Post by fsteimke »

Yes, everthing is fine with the latest release 18.1.

Thank you,
Frank
Radu
Posts: 8991
Joined: Fri Jul 09, 2004 5:18 pm

Re: Bugs in CALS Table processing ?

Post by Radu »

Hi,

About the first post in this thread, in Oxygen 19.1 changing the name of a table column in the Author visual editing mode will also update all references to that column name across the table.

Regards,
Radu
Radu Coravu
<oXygen/> XML Editor
http://www.oxygenxml.com
Post Reply