-
Notifications
You must be signed in to change notification settings - Fork 32
Limitations
There are definite limits in JATSKit's functionality due to its targeting the "easy 80%" -- precisely since systems distinguish themselves on the more difficult 20%, it seems likely to offer only diminishing returns for a toolkit (more or less useful to everyone) to try to address very specific functional requirements (peculiar only to some).
However, a "plain vanilla" format can serve as a "floor" for further development, and XSLTs, CSS, XProc and Schematron code is provided in JATSKit with that in mind.
Not only are there limits due to what can usefully be done while remaining generic (a "greatest common factor" set of utilities); additionally there will be limitations that come with (necessary) dependencies on external applications. A couple of these are described in more detail below. Contributors and supporters might well help to remediate any or all of these known issues.
JATSKit attempts to generate EPUB3 not EPUB2 or other ebook formats. Its emitted HTML may not always be formally valid XHTML either, depending on exigencies (however it will always be reasonably clean).
Current XSL-FO has been tested and runs successfully only with AntennaHouse Formatter, a commercial XSL-FO engine, which must be acquired separately from oXygen (which can then be configured to use it).
It would be nice, however (really nice), if PDF generation were possible using the FOP processor delivered with oXygen. Even if there are limits to what can practically be done, almost anything would be more useful than the current error message.
For PDF generation, "proof format" (PDF suitable for checking XML content) and "dump format" (suitable for indexing in e.g. Google Scholar but making no efforts at legibility) are probably more important goals than developing a proof of concept for high-touch production values.
Additionally, other pathways to PDF might be explored.
JATSKit include JATS DTDs using MathML3, not MathML2. The incidence of actual data that is known to be valid to MathML2, but not validable to MathML3, is expected to be low. As described in DTD Versions, JATSKit may also be useful with other DTDs including MathML2 DTDs. Currently nothing special is done with MathML; it is simply passed through into receiving formats.
Given a realistic sample data set we could patch this hole. At a minimum some sort of handling could be tried and tested in HTML pathways.
As noted above, while scaffolding is in place for most important or common things, there is much still missing in JATSKit.
For example, some elements new in BITS have not been given much attention or scrutiny. (Nothing is done with tables of contents or indexes for example.) As always, real data would be helpful to test against.
Additionally, some capabilities provided are frankly demonstrations of what is possible and even easy to do on a wider basis.
XML content recognized by JATSKit (as distributed) will be validated in the toolkit to current "standard" JATS/BITS models, namely NISO JATS 1.1, NLM BITS 2.0.
As described in the DTD Versions page, JATSKit can be extended to include other DTDs as well, as long as you have a working DTD and a catalog. For JATSKit's own catalog, see file lib/jatskit-catalog.xml. Note that while using JATSKit on arbitrary document types may sometimes require some work "under the hood" to address gaps in functionality, that may be true in any case.
In general, graphic files are expected to be one of JPEG (named *.jpg or *.jpeg) or PNG (named *.png) or SVG (named *.svg). When generating EPUBs and mock ebooks, image files are consolidated into one subdirectory, and name clashes are not managed. To avoid problems, image files should all have unique names (not only addresses).
Support for other kinds of external media, or for any attached or associated files in other formats, is also expected to be an area for local extension.
JATSKit is provided without warranty, but it is also easily extensible and customizable. See Contributing.