Re: [jats-list] Interesting thread on eLife Lens GitHub issue, re resolving figure URLs

Subject: Re: [jats-list] Interesting thread on eLife Lens GitHub issue, re resolving figure URLs
From: Alf Eaton <eaton.alf@xxxxxxxxx>
Date: Wed, 12 Jun 2013 10:41:08 +0100
The main outcome of this discussion was that the JATS DTD needs to
support the xml:base attribute, so that relative URIs in xlink:href
attributes can be resolved relative to URLs other than those from
which the XML document was served.

For example:
<https://peerj.com/articles/36.xml> contains URIs in xlink:href
attributes which are relative to <https://peerj.com/articles/36/>, but
there's no way to tell a consumer this.

=====================

The other point raised was that there are often multiple formats and
sizes of an image available, and it's not clear how to represent those
versions in JATS XML.

For example:
<https://peerj.com/articles/36.xml> contains a figure with
<object-id pub-id-type="doi">10.7717/peerj.36/fig-1</object-id> and
<graphic mimetype="image" mime-subtype="png" xlink:href="fig-1.png"/>,
but there are multiple sizes and formats of the image available:
<https://peerj.com/articles/36/fig-1.png>,
<https://peerj.com/articles/36/fig-1-full.png>,
<https://peerj.com/articles/36/fig-1-1x.jpg>,
<https://peerj.com/articles/36/fig-1-2x.jpg>,
<https://peerj.com/articles/36/fig-1-small.jpg>, etc.

This is something that HTML5's srcset attribute
<http://dev.w3.org/html5/srcset/> is trying to solve, but is there a
recommended practice for JATS XML? Should the <graphic> elements
perhaps be wrapped in an <alternatives> element, or should clients
just use the DOI of the object and let content negotiation handle
retrieval of the desired format?

Alf

On 11 June 2013 05:23, Maloney, Christopher (NIH/NLM/NCBI) [C]
<maloneyc@xxxxxxxxxxxxxxxx> wrote:
> Here's a discussion about the problems of resolving xlink:href URLs inside JATS documents, people here might be interested in:
>
> https://github.com/elifesciences/lens/issues/6

Current Thread