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: "Randall, Laura (NIH/NLM/NCBI) [E]" <laura.randall@xxxxxxx>
Date: Wed, 12 Jun 2013 12:10:48 +0000
>Should the <graphic> elements perhaps be wrapped in an <alternatives> element
My understanding is that's why it was added to the tag set, so I would say
yes.

Laura
________________________
Laura Randall
lrandall@xxxxxxxxxxxxxxxx
NCBI/NLM/NIH


________________________________________
From: Alf Eaton
[eaton.alf@xxxxxxxxx]
Sent: Wednesday, June 12, 2013 5:41 AM
To:
jats-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: [jats-list] Interesting thread
on eLife Lens GitHub issue, re resolving figure URLs

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
>
--~------------------------------------------------------------------
>
JATS-List info and archive:  http://www.mulberrytech.com/JATS/JATS-List/
> To
unsubscribe, go to: http://lists.mulberrytech.com/jats-list/
> or e-mail:
<mailto:jats-list-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx>
> --~--
>
--~------------------------------------------------------------------
JATS-List info and archive:  http://www.mulberrytech.com/JATS/JATS-List/
To
unsubscribe, go to: http://lists.mulberrytech.com/jats-list/
or e-mail:
<mailto:jats-list-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx>
--~--

Current Thread