# dejats

This library converts from JATS files to HTML in the dumbest way possible. That is to say
that it does almost nothing beyond producing a lot of `div`s, `span`s, and a few other such
elements,`p`s. It does a pretty strict minimum in terms of interpreting JATS as HTML.

While this may seem counterintuitive, the value in this approach is that the programming model with
which one transforms to better, richer HTML is then simply by manipulating the HTML DOM. If a
feature of the transformation is not supported, you don't need to learn a new API: you just need to
write some JS to modify an HTML DOM. You can use whichever way of doing that you like, be it the raw
DOM, jQuery, or whatever else you might enjoy. By applying several small additional modules that
enhance the pretty brutal (to say the least) HTML that comes out of this module, you can get really
rich and useful HTML in a very flexible and modular manner.

One thing that this module *does* do for you is that it tries to expose *all* the information that
a JATS file contains. This means that the HTML that comes out directly of it is pretty much unusable
as is. You *will* need to carry out at least some post-processing. But you have all the information
you need to do that, and (one hopes, soon) a small ecosystem of libraries to handle various subsets
of the cleanup.

## Installation

    npm install dejats

## API

The `dejats` API is exceeding simple. Only one function is exported (the default export). It takes
a string of JATS and a callback. The callback receives an error if there was one, and an HTML DOM
Document. It looks like this:

```js
dejats(someStringOfJATS, (err, doc) => {
  // do whatever you want with the HTML doc here
});
```

## The HTML

The HTML being produced is largely a collection of `span` and `div` representing the content. When
there is a `class`, it contains the name of the original element that generated it. JATS attributes
are all mapped. Those that map sufficiently directly to HTML are as they are in HTML, all of the
others are prefixed with `data-` (and have `-` instead of `:` if they were namespaced).

When it is straightforward, links are generated (in which case the matching `data-xlink-href` is
removed) but that is not always the case. A little amount of specificity is built into `graphics`,
`media`, and friends handling in order to produce `img`, `video`, `audio`, or `iframe` but it
remains superficial.

Note that even when for instance `img` are generated, they may not point to an actual resource
depending on who produced the JATS to start with. To give an example, it is relatively typical for
OAPMC markup to lead to `<img src="pone.0012255.g004">` but to provide no `pone.0012255.g004` in
the tarball: instead there are `pone.0012255.g004.gif` and `pone.0012255.g004.jpg`. Resolving
media based on such lovely details is the responsibility of the calling application.