Enabling or Enforcing [was: Re: [jats-list] Lists with a single item are valid, will they always be?]

["Tommie Usdin btusdin@xxxxxxxxxxxxxxxx" <jats-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

Hi Chiara --

Your comment touches on one of the core principles on which JATS is based,
something that perhaps we should discuss more. These are fundamental to
understanding JATS as it is and to contributing to JATS as it continues to
change to meet user needs.

The goals of JATS have been, from the beginning, to enable the creators of
journal articles to encode the content they actually do publish. While there
have been many suggestions of ways JATS could/should be changed to force
publishers to publish what the suggester thinks content creators SHOULD
publish rather than the what they DO publish; the JATS Standing Committee has
rejected these suggestions.  JATS is designed to describe what is, not to
guide or dictate what should be.

I am talking about history. It is certainly possible that a future,
non-backwards-compatible version of JATS, perhaps a straight-and-narrow-JATS,
might have a different philosophy. For example, there might be one and only
one way to:
 - encode people's names
 - associate affiliations with contributors
 - encode math
 - tag and style citations
 - locate footnotes

The recommendations of JATS4R, DataCite, Force11, NISO's ALI, the W3C's WAI,
and probably a dozen others,  might be built into JATS and thus elevated from
recommendations to requirements.

Similarly, expectations about:
 - provision of metadata about graphics, people, and organizations, and
 - number of citations in a reference,
 - the number of items in a list,
 - labels on sections, footnotes, references,
 - the content of many organizational style guides
could be built into a future JATS.

Especially if JATS were to abandon DTDs and move to either only RNGs or only
XSDs (both have been suggested), JATS could require that all dates were valid
dates. Several have said that JATS MUST enforce correct dates.

There are real-life reasons that people need what seems like ridiculous
flexibility. For example, many people think it is reasonable for a vocabulary
to require that all dates are valid dates. But, what about the situation of an
existing document that has a publication date of "February 31, 1922"? Should
it be impossible to include this document in a JATS-based database? Should the
people doing the tagging correct the date? How can data conversion people be
expected to know what the correct date is?

In my opinion, making a straight-and-narrow version of JATS would be wasted
effort. Just as JATS BLUE has been becoming more and more GREEN over the years
because users wanted the tighter models of BLUE but "just this one thing"
should be looser because they need it and their use case it reasonable. Or,
perhaps more likely, the user community would simply ignore it.

This does not mean that I think JATS is perfect or that JATS should not
change. Indeed, I think there are many ways in which JATS could/should be be
improved and I expect that JATS users will continue to identify ways in which
JATS should be extended to meet new or newly recognized requirements.

Discussions such as this one are very useful in identifying ways in which JATS
can be improved. Thank you for raising an important topic.

-- Tommie


> On Dec 17, 2025, at 7:36b/AM, Chiara Del Vescovo chiara.delvescovo@xxxxxxx
<jats-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> Hi all,
> The definition of lists in
https://jats.nlm.nih.gov/publishing/tag-library/1.4/element/list.html states
that they are sequences "of two or more items, which may or may not be
ordered". However, lists with a single item are valid against the DTD, and
indeed we do have plenty of examples in our catalogue of such lists.
> Will this always be the case, or do you think it's possible that sooner or
later the DTD may get changed to align with the description?
> I'm just a tiny bit nervous about the impact that this could have, so
looking for reassurance!
> Best wishes,
> Chiara
> Chiara Del Vescovo
> Senior Content Data Model Architect | Operations
> Oxford University Press
>
> Oxford University Press (UK) Disclaimer
> This message is confidential. You should not copy it or disclose its
contents to anyone. You may use and apply the information for the intended
purpose only. OUP does not accept legal responsibility for the contents of
this message. Any views or opinions presented are those of the author only and
not of OUP. If this email has come to you in error, please delete it, along
with any attachments. Please note that OUP may intercept incoming and outgoing
email communications.
> JATS-List info and archive
> EasyUnsubscribe (by email)


======================================================================
B. Tommie Usdin mailto:btusdin@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc. https://www.mulberrytech.com
----------------------------------------------------------------------
Mulberry Technologies, Inc.: A Consultancy Specializing in XML for Prose
Documents
======================================================================