Support for tables about jatskit HOT 13 CLOSED

JATS provides for either OASIS/CALS or HTML tables (actually a subset), much like Docbook. I imagine a great deal of the oXygen/Docbook code for tables would simply port across. However, it remains to be determined what proportion of JATS users/projects actually use the CALS/OASIS -- one guesses most use HTML, but I have no numbers.

from jatskit.

There's some indication of the use of CALS in this survey by Bruce Rosenblum from JATS-Con, 2010: Implementations of the NLM DTD within Inera’s eXtyles products for markup of full text content in journals, books, and newsletters

from jatskit.

Wendell's idea about differentiating CALS and HTML tables:

In JATS, OASIS/CALS tables are assigned a namespace (with a hard-wired
prefix in the DTD), whereas HTML tables are in no namespace as are the
JATS elements.

from jatskit.

It appears that in BITS 1.0 at least (as distributed with JATS 1.1d3), both OASIS tables (namespaced) and HTML tables (no namespace) may co-exist in a valid document. (Try DTD BITS-book-oasis1.dtd).

Given this, I think the choice is reasonably clear: either the framework supports only HTML tables (OASIS table users can extend for themselves), or it supports both together, with no fancy toggling. (Perhaps a paranoid Schematron could detect the OASIS tables and warn against them, at any rate if HTML tables also appear.)

If we put relevant tooling on separate toolbars, users can hide the toolbar for tables they don't want. (If only they would do that.)

Given that we already have the hard part done for OASIS tables (there is better XSLT now in place, plus oXygen code in other frameworks), I'd think supporting both kinds of tables would be worthwhile, albeit not the highest priority.

from jatskit.

What we do for Docbook which also supports both:

The "Insert Table" dialog allows you to choose the table model to insert.
All other table-related actions operate on existing tables so they can detect what kind of table it is and act accordingly.
So there would be no need for two table toolbars.

from jatskit.

If the code is all written for Docbook, fantastic. Less to adapt!

Given the potential complexity here -- depending on the DTD used, a document could permit either both tables, or only one or the other ... perhaps we should simply permit the user to insert either type of table with the Action -- even when they can't insert the wrong table via "Insert Elements" (which consults the schema). Then if an invalid table is used, there will be an error in validation.

This is probably better and simpler than trying to prevent invalid input in all cases -- assuming there is still no way an Action can consult a schema.

from jatskit.

Oops!

from jatskit.

An operation can also consult the schema. So if the schema allows only one of those table models at the same time we could show the Insert Table dialog without allowing any choice of table models, inserting the proper content. But that would need some Java customization, indeed copying the Java code which currently exists for Docbook would be a start.

from jatskit.

@wendellpiez My colleague Bogdan added a pull request for table support in Jats, along with overall changes to the CSSs. Maybe you can look over it when you have the time:
#44
The support is only for HTML-style tables but it's better than what we have now, it covers table insertion, operations to insert rows and columns, splits and joins.

from jatskit.

@wendellpiez have you had time to look over the pull request?

from jatskit.

@raducoravu please remind me again in a day or two I am presenting a paper at Balisage today!

from jatskit.

@wendellpiez ping :)
By the way are the Balisage session recordings available somewhere?

from jatskit.

We now have actions to insert HTML tables and to manipulate them by adding/removing rows/columns, splitting and joining cells. There is no CALS table support yet, we'll maybe do that on another issue if somebody asks for this.

from jatskit.