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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [jats-list] Interesting thread , Alf Eaton | Thread | Re: [jats-list] Interesting thread , Beck, Jeff (NIH/NLM/ |
Re: [jats-list] Interesting thread , Alf Eaton | Date | [jats-list] eLife lens, XML and JSO, Ian Mulvany |
Month |