A further detail: 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 is defined here (click on Models and Context/Description/Any combination of""). It overlaps significantly with other elements containing

, such as , , , 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: "p" -> para $ trimInlines . mconcat <$> mapM parseInline (elContent e) A bug? 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... > -- You received this message because you are subscribed to the Google Groups "pandoc-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/52eb7338-b175-4241-91cd-6c8ab998f837n%40googlegroups.com.