Re: [jats-list] Data URLs in JATS

Subject: Re: [jats-list] Data URLs in JATS
From: "Wendell Piez wapiez@xxxxxxxxxxxxxxx" <jats-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Wed, 23 Mar 2016 21:03:35 -0000
Hi again,

If what is wanted is to embed "actual" HTML in a form that it can be
parsed and processed, this suggestion doesn't seem unreasonable.

(I mean actually embedding the code rather than simply linking to it
which ought to be equally thinkable and has better SOC even.)

Another thing to consider is that <code> has an @executable attribute on it.

In the context of HTML this might be taken to warrant (to a receiving
system) "you can actually parse this and do your HTML thing with it",
much like the data: URL hack.

Of course I haven't looked to see whether 'code' offers whatever else
might be needed to support this. But there are plenty of other
attributes including @language-version, @code-type and @code-version
(I am looking at BITS 2.0) that could be drafted into service.

And really the proof would be in trying it out -- since it really
comes down to what the receiving system is prepared to do with what
data, in any case -- that's inescapable.

If you have no receiving system or none in mind, you are betting on
ponies so do what seems right. (I am not one who likes to codify Best
Practice before we have any at all.)

Cheers, Wendell


On Wed, Mar 9, 2016 at 6:02 PM, Gareth Oakes goakes@xxxxxxx
<jats-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> 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
>
>
>



--
Wendell Piez | http://www.wendellpiez.com
XML | XSLT | electronic publishing
Eat Your Vegetables
_____oo_________o_o___ooooo____ooooooo_^

Current Thread