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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [jats-list] Data URLs in JATS, Gareth Oakes goakes@ | Thread | [jats-list] JATS-Con Preliminary Pr, Beck, Jeff (NIH/NLM/ |
Re: [jats-list] html fragments and , Wendell Piez wapiez@ | Date | [jats-list] JATS-Con Preliminary Pr, Beck, Jeff (NIH/NLM/ |
Month |