Re: [jats-list] eLife lens, XML and JSON

Subject: Re: [jats-list] eLife lens, XML and JSON
From: ian mulvany <i.mulvany@xxxxxxxxxxxxxxxxx>
Date: Fri, 14 Jun 2013 18:19:20 +0100
On 14 Jun 2013, at 14:27, Wendell Piez <wapiez@xxxxxxxxxxxxxxx> wrote:

> Ian,
>
> Thanks for posting this interesting report.
>
> I am curious about a few details you leave out:
>
> 1. How are you getting from your XML to your JSON?

Heroku app written in node.js, using a javascript implementation of an XML
parser.

>
> 2. How is the JSON modeled, constrained and validated? ("In the
> application" is a perfectly good answer; I understand a system like
> this can work without any formal external specification, at least up
> to a certain point.)
>

It's not. The development cycle between the person writing the parser, and the
application developer, was very tight, with modifications based on user
testing happening on an almost daily basis. We started out with the idea,
created a rough sketch in code, tested, and iterated until we were happy that
the implementation supported our users against the use case we wanted to code
against.

> 3. Do you have plans to (re)serialize the JSON in other forms for
> consumers other than web browsers, or will you go back to the JATS XML
> for that? In particular, do you have ways to capture back any
> information added (such as annotations) in the JSON layer? Or is that
> all for the future?
>

The short answer is no.

For the future. In particular we are interested in porting this view into the
peer review system, at which point we will need to capture annotations. We are
looking at (by which I mean currently talking about, but not yet implementing)
either a custom solution based on the substance server (substance.io) or on
one of the tools being built on top of the open annotation standard. We don't
anticipate that these annotations will be captured and reserialised into the
XML. I was unaware that JATS could provide support for that. In any case, this
is for the future. We are interested in feedback on the tool in it's current
implementation, and in integrating more tightly with our core journal site.

> Kind regards,
> Wendell
>

Thank you for the questions

>
> On Wed, Jun 12, 2013 at 8:24 AM, Ian Mulvany
> <i.mulvany@xxxxxxxxxxxxxxxxx> wrote:
>> Hi All,
>>
>> Last week we launched a new way to layout articles online -
>> lens.elifesciences.org.
>>
>> We discussed XSLT transforms from base XML, vs going with a
>> converstion to JSON. In the end we opted with doing an XML to JSON
>> conversion, and then feeding that JSON to a single page web app.
>>
>> The converted JSON files are hosted on an s3 bucket, and served
statically.
>>
>> In this message I wanted to cover a couple of the reasons why we
>> followed this route. This is not a claim that our route is better than
>> another route, it's purely as an FYI for the people on this list. It
>> relates loosely to JATS, as JATS is the source format, and this
>> application should be seen as an application built on top of that
>> really great platform.
>>
>> - We had a good set of tooling to hand based on JSON, as we were
>> working with the developer behind substanc.io
>>
>> - We wanted to be able to serve the files statically, and allthough
>> you can do this with XSLT transforms in the browser, we judged that
>> working directly with JSON was going to be easier for us, it turned
>> out to be pretty good.
>>
>> - We liked making relationships of interest to us in the document
>> explicit through a set of annotations, rather than leaving them as
>> implicit relationships encided in xref nodes.
>>
>> Once we picked this route hving those explicit relationships in the
>> JSON allowed us to iterate on the front end very quickly. The tool we
>> launched went through a large number of front end iterations.
>>
>> - Ian
>>
>
>
>
> --
> Wendell Piez | http://www.wendellpiez.com
> XML | XSLT | electronic publishing
> Eat Your Vegetables
> _____oo_________o_o___ooooo____ooooooo_^

Current Thread