Align the content model of <additional> with other top-level elements within <msDesc>

[schassan]

The content model of <additional> is much stricter than the ones of the other top-level elements within <msDesc>, except <msIdentifier> (for obvious reasons).

I would like to ask to relax the content model of <additional> and allow <p> and <ab>.

BTW: We need a more relaxed content model in the scope of the Handschriftenportal.

[sydb]

Hi Torsten! (I suppose I should say “@schassan” :-)
Can you be more precise about what it is you want to tuck into <additional> (that does not fit well into additional/adminInfo/note or additional/surrogates/desc or whatever)?
I do not, off the top of my head, recall why the content model of <additional> is as it is instead of, say { ( adminInfo?, surrogates?, listBibl? ) | ( p | ab )+ } (a content model that I would not be completely happy with, but would perhaps fit the mores of the rest of MS Description somewhat better). Maybe David Birnbaum, Matthew Driscoll, Merrilee Proffitt, or @lb42 can say?

[lb42]

Would you be happier if the content model were changed so that <additional> disappeared entirely, and was replaced by ( (adminInfo?, surrogates?, listBibl? ) ? As far as I recall, it was only invented so as to add a bit more structure to this rather miscellanous collection of metadata.

[schassan]

I wrote a lengthy answer to @sydb and @jamescummings on the list but want to repeat here that we are in need of a container for fulltext of different kinds. @sydb's suggestion would be easier to implement I think while I kind of like @lb42 s suggestion as well. But that might break existing documents and is thus not the favoured solution I guess?

[holfordm]

@schassan would it be worth sharing some examples of the material you'd like to be able to include? I just wonder if rather than p or ab there might be more semantically rich options that might be better for future interoperability

[larkvi]

Per the msDesc SIG meeting at TEI2022, there was general agreement that we have no strong opinions against p in additional and would accordingly support adding it to meet the needs of @schassan's project.

[sydb]

Which brings us back to my question — would

model.pLike+ | ( adminInfo?, surrogates?, listBibl? )

be sufficient, or would you need

( adminInfo?, surrogates?, listBibl?, model.pLike* )

Things to keep in mind:

• Most elements in the MS description module that allow model.pLike have a content like the first possibility above: i.e. they allow EITHER a sequence of one or elements from model.pLike OR a sequence of more structured, semantically meaningful elements, BUT NOT both.[1]
• <additional> is not a repeatable element, so if you want to have both <surrogates> and a paragraph of prose you need the second approach.

Note

[1] I did a quick check, according to which:
The following elements follow this “EITHER paragraphs OR structured semantic stuff” approach: <custodialHist>, <decoDesc>, <handDesc>, <history>, <layoutDesc>, <msContents>, <msDesc>, <msFrag>, <msItem>, <msItemStruct>, <msPart>, <objectDesc>, <recordHist>, <scriptDesc>, <sealDesc>, <supportDesc>, and <typeDesc>.

The following elements allow paragraphs interspersed with other content: <binding>, <bindingDesc>, <physDesc>, and <seal>.

[schassan]

Sorry for not having commented on that earlier, but this would be sufficient:

model.pLike+ | ( adminInfo?, surrogates?, listBibl? )

[sydb]

See PR #2470.