Re: [EXTERNAL] [jats-list] inline code vs monospace in JATS

["Lizzi, Vincent vincent.lizzi@xxxxxxxxxxxxxxxxxxxx" <jats-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

Hi Castedo, Laura, and all,

Thanks for the link to the GitHub discussion, Castedo. The Baseprint Document
Format<https://perm.pub/DPRkAz3vwSj85mBCgG49DeyndaE/> that you are working on
as a subset of JATS looks like an interesting project. Trying to get two
different systems that are outside your control, in this case PMC Article
Viewer and Pandoc, to produce consistent presentations of content can be
difficult especially in areas that some might consider to be uncommon or edge
cases.

The suggestion in the GitHub discussion to tag inline code as <named-content
content-type="code"><monospace>inline code</monospace></named-content> looks
reasonable to me. (It also mirrors the convention in HTML to tag code blocks
as <pre><code>block code</code></pre>.) However, as you noted, PMC transforms
<named-content> to <em> which displays as italic which is not desired for
computer code.

As noted in the GitHub discussion, using attribute specific-use=bcodeb is
not strictly consistent with the intended use of the specific-use attribute.
It would be better to use attribute content-type=bcodeb, however the
content-type attribute is not available on the <monospace> element. Tagging
inline code as <monospace specific-use=bcodeb>inline code</monospace> can
be a reasonable workaround if it provides you with both the display and
semantic identification that you need.

It looks like there are two potential improvements to be made to JATS based on
the issue that youbve raised. This could be worth submitting via the comment
form<https://groups.niso.org/higherlogic/ws/public/document?document_id=31409>
for consideration in a future version of JATS.


  1.  Provide a way to tag code fragments that should be displayed inline with
the surrounding text  b possibly a new element <inline-code> based on the
<code> element, or possibly a new style attribute on the <code> element.
  2.  Add the content-type attribute to face markup elements (including
<monospace>) to enable identifying the type of content (such as code).

There are people on this list who are familiar with PMCbs systems, including
Laura, who might have more to add.

Kind regards,
Vincent

_____________________________________________
Vincent M. Lizzi
Head of Information Standards | Taylor & Francis Group
vincent.lizzi@xxxxxxxxxxxxxxxxxxxx<mailto:vincent.lizzi@xxxxxxxxxxxxxxxxxxxx>
Time zone: US Eastern
[https://res.public.onecdn.static.microsoft/assets/bookwithme/misc/CalendarPe
rson20px.png]<https://outlook.office.com/bookwithme/user/aa80d42cbb5b46dba06a
5ad241d7665b@xxxxxxxxxxxxxxxxxxxx?anonymous&ep=owaSlotsEmailSignature>
Book time to meet with
me<https://outlook.office.com/bookwithme/user/aa80d42cbb5b46dba06a5ad241d7665
b@xxxxxxxxxxxxxxxxxxxx?anonymous&ep=owaSlotsEmailSignature>



Information Classification: General
From: Castedo Ellerman <castedo@xxxxxxxxxxx>
Sent: Monday, September 8, 2025 9:19 AM
To: Lizzi, Vincent <Vincent.Lizzi@xxxxxxxxxxxxxxxxxxxx>
Subject: Re: [EXTERNAL] [jats-list] inline code vs monospace in JATS


Regarding <code specific-use="inline">, I consider using whatever PMC has
actually implemented to render HTML from XML actually archived in the Open
Access Subset. So if PMC wants to implement that, that sounds great.
<monospace specific-use="code"> is also great, if it is actually implemented
by PMC.



That said, until PMC actually implements HTML rendering of <code
specific-use="inline"> there is backwards compatibility problem. The way PMC
is currently implemented, a <code specific-use="inline"> will not gracefully
degrade. It will break-up a containing block element and render code content
as a new block element when the author intended it to be inline. In contrast
<monospace specific-use="code"> will gracefully degrade before is it actually
supported by PMC.



I'm sorry for the delayed response. An emailing lists like this one is really
nice and useful for certain "slow" types of communication. But for detailed
discussions about tech, I find GitHub far more conducive to that kind of fast
techy discussion. There's a related discussion on this topic, but in the
context of authoring using pandoc, at



https://github.com/jgm/pandoc/discussions/11108<https://github.com/jgm/pandoc
/discussions/11108>



There's a lot more details and thoughts from Denis Maier and myself over
there.



Best regards,
  Castedo




On 9/5/25 00:07, Lizzi, Vincent wrote:
Hi Castedo,

I see your point about the <code> element typically being treated as a block
for rendering and the desire to use <code> as an inline element sometimes. It
may sometimes be possible to infer from the context or the content whether
block or inline display is preferable, but not always.

Would you consider using an attribute on the <code> element to specify when it
is intended to be inline? For example:

<code specific-use="inline">

This would ballow specifying inline when needed, and assuming block as the
default.

You can, if you wish, submit a comment to the JATS Standing Committee to
consider suggestions for improving this in a future version of JATS. The
comment form is at
https://groups.niso.org/higherlogic/ws/public/document?document_id=31409<http
s://groups.niso.org/higherlogic/ws/public/document?document_id=31409>

Thank you,
Vincent