Re: [jats-list] Data URLs in JATS

Subject: Re: [jats-list] Data URLs in JATS
From: "Gareth Oakes goakes@xxxxxxx" <jats-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Wed, 9 Mar 2016 23:02:29 -0000
Hi Chris,



>>(2) Ibve seen XML processors in the past
>> that have fixed limits on the length of attribute values. Obviously such
XML
>> processors should be fixed, but in production scenarios it is sometimes
>> difficult to effect such changes. Just something to be aware of.
>
>Either fixed, or the team should pick a new processor. I'd be very surprised
to
>find any tool that couldn't handle long attribute values -- within reason of
>course (under 1M, say).

Arbortext Editor (nee Epic nee ADEPT) is an example where Ibm sure we ran
into attribute value length problems in the past. That tool is an example of
where it is not simple or easy to bdrop and replaceb with a new XML
processor.

Either way this is certainly not a showstopper issue. It seems reasonable and
sensible to recommend an upper limit for data URI lengths based on a quick
evaluation of commonly used processing tools in the JATS community.

>
>I'd be interested to hear others' thoughts on this idea -- so I'm sending
this
>with a new heading. Its use wouldn't be covered by the JATS standard, so its
>really a "recommended practices" question, and maybe people have some
>practical concerns I haven't thought of.

I like the idea of having a way to battachb related or alternative content
and identify itbs intent. The MIME type gives a physical intent and the use
of elements <textual-form> <code> <inline-graphic> etc. give a semantic hint.
I guess @specific-use would be used to cover any edge cases where concrete
semantics are required?

// Gareth Oakes
// Chief Architect, GPSL
// www.gpsl.co

Current Thread