Actually, the three lists that describe block elements: 'paragraphLevel', 'lists', 'mathML', and 'other' are taken directly from the JATS spec of any element that can contain a element, all of which share a similar structure. For example, the list of allowed contents for element <abstract> is defined here (click on Models and Context/Description/Any combination of""). It overlaps significantly with other elements containing , such as <ack>, <glossary>, <note>, etc.

So its seems that "block elements" is intended to mean the common set of elements that are allowed in elements that contain a . Then the 'inLine' tags are the list of elements that can be contained inside a element. I am not sure of the intent or rationale of filtering out the latter from the former, but It seems to me that parsedMixed in line 166 was more designed to be applied to containers of , rather than to . And that the case "p" should simply do something along the lines of:

On Friday, 19 May 2023 at 17:22:29 UTC-5 Julia Diaz wrote:

On Friday, 19 May 2023 at 07:32:51 UTC-5 Albert Krewinkel wrote:
The JATS reader is based on the DocBook reader, AFAIK, and reuses a good
bit of the DocBook code. The list of block tags in the DocBook reader is
much longer, so this is most likely a leftover than could be simplified.

Looks like legacy from DocBook indeed.

I just realised something else: as the JATS reader is written now, the isBlockElement never returns TRUE.
This is because the only function that calls isBlockElement is parseMixed, which is only used for the case of "p", which by definition of the JATS models cannot contain itself an inner "p" element. Thus the only case that could possibly trigger a TRUE result for isBlockElement is impossible.

In other words, as it is written now, not only the isBlockElement is pointless, also parseMixed is. Since isBlock is always FALSE, the rest is always empty, and lines 208-211 are never reached. So we could always in all confidence parse the full contents of "p" just with parseInLine as done here.

I would things something got mixed up in the process when the isBlockElement was adapted for the JATS reader. I could not help but notice that the order of the inLineTags in the isBlockElement function is almost identical, and in the exact same order, to the list of allowed contents of "p" in the JATS specification (only missing are a few more recent elements, mostly Q&A elements, that presumably did not exist when the JATS reader was first written). The paragraphLevel list is also an exact copy of the "Paragraph-level Display Elements" sublist in the same JATS specification page. It makes no sense to me to define these separately only to filter them out immediately and inevitably, specially when no record of which list the element in question belonged to, and only a context-less Boolean value is ever provided...