Allowing <list> in edition

[manufrancis]

@danbalogh

Could you, please, update the EGD so as to allow <list> in edition?
I find this very useful to further structure long paragraphs which include lists of land boundaries or signatories, for example.

[danbalogh]

@manufrancis , <list> was at one point permitted in editions (I have used them myself in donee lists), but we had decided to forbid them. The reasons for doing so were already forgotten in 2021 (see the issue #150), but there probably were reasons :) In the discussion of that thread, Arlo and I both felt that a further level of complication to the XML hierarchy of the editions is not really desirable, but did not have strong feelings about it. Considering it now, it is my definite preference to keep this the way it is. But if neither @arlogriffiths nor @michaelnmmeyer have objections, I'm OK with permitting lists in the edition. They would be optional, and permitted, as outside the edition, only within <p> (so no list formatting for verse). In case of overlap with phrase-level elements (e.g. unclear, supplied, etc.), the latter would of course have to be split across the list items.

[michaelnmmeyer]

I am fine with this. In fact, the schema does not flag it as an error.

[danbalogh]

I assume that means we can rest assured that lists would not interfere with e.g. the referencing of line breaks and milestones, or the display of phraselike elements like unclear and supplied?

[michaelnmmeyer]

As long as inline elements (unclear, etc.) do not wrap lists, which are block elements, it is fine.

[danbalogh]

Good to know, thanks. I don' think anyone would ever think of wrapping a whole list in unclear etc.; I was rather thinking of cases like when an unclear or supplied element is broken up by list items.
E.g. without list encoding, you might have in your edition

lorem <unclear>ipsum dolor</unclear> sit amet

With a list, the encoding would change to

<list>
<item>lorem <unclear>ipsum</unclear></item>
<item><unclear>dolor</unclear> sit amet</item>
</list>

for which the logical display would need to look like this:

lorem (ipsum)
(dolor) sit amet

but the physical display should be the same as for the encoding without list markup:

lorem (ipsum dolor) sit amet

[michaelnmmeyer]

Merging adjacent elements depending on the display mode is not supported for now. This requires a revamp of the display code, which I will conduct in a few months. In fact, lists are themselves not really supported yet: the output looks fine in a Web browser, but it is not valid HTML.

[arlogriffiths]

I don't have a strong opinion on whether we should allow use of <list> in editions. I think part of why we decided not to earlier on might have been that it is possible to let the translation to the work of finely structuring the information contents of an inscription, so that the encoding of the edition need not be weighed down with all the same structural finesse. It is certainly my personal preference to work with some division of labor between edition and translation, and to use <list> only in the latter. If Manu is talking about inscriptions that he doesn't intend to translate, then this might be a consideration in favor of allowing use of <list>. If he does intend to translate them, then I'd encourage Manu to keep his edition simple on this point and use <list> only in the translation.

Example of little intrinsic structure in the edition paired with a lot of intrinsic structure in the translation: https://dharmalekha.info/texts/INSIDENKAnjatan.

[danbalogh]

@manufrancis , I'd like to leave the last word to you. Nobody is strongly against this, so if after considering the above observations you are sure you want it, go ahead and encode the list, and I'll add provision for it to the future EGD.

[manufrancis]

@danbalogh
Yes, I am sure I want it.
Please add provision to the future of the EGD along the lines you described above:

They would be optional, and permitted, as outside the edition, only within <p> (so no list formatting for verse). In case of overlap with phrase-level elements (e.g. unclear, supplied, etc.), the latter would of course have to be split across the list items.

[danbalogh]

OK, done.