search

TEIC / TEI

The Text Encoding Initiative Guidelines
https://www.tei-c.org
Other
276 stars 88 forks source link

Why doesn't divGen have the same content model as div? #2221

Closed hcayless closed 2 years ago

hcayless commented 2 years ago

I've never used <divGen> and therefore had never really looked at it closely, but now that I have, I wonder: why can it only contain <head>? Presumably that means it's meant to be replaced by a generated <div> when processed, but I think it would make much more sense if it was just filled in with the generated content, and remained as a signal that "I was generated automatically, maybe don't edit me..."

Maybe someone with more TEI wisdom than I can comment?

martindholmes commented 2 years ago

I've always assumed it was intended to be completely replaced, and the head was there either as an explanatory heading for readers of the file before processing, or to supply a context-sensitive heading for a specific location, when the same contents might be supplied in place of multiple divGens in different contexts.

peterstadler commented 2 years ago

I don't know why the content model of <divGen> isn't simply empty but its purpose is definitely to be a placeholder (to be replaced by some generated content). A typical example is https://github.com/TEIC/TEI/blob/daab99ca7a2ea83c2d2f4ee8f1f8e874b288492c/P5/Source/guidelines-en.xml#L99

lb42 commented 2 years ago

Martin is right. <divGen/> is meant to indicate the intended location of some generated content (for example, a table of contents, an index etc.).It comes from the world of text processing systems like troff, and is indeed very like a processing instruction, as previously noted, but more specialised. It first appears in TEI P2 (see page 194), where it is discussed along with the element. The example given there shows the @n attribute being used to represent a title for the generated content. <divGen type="index 1" n="Index Nominum">. A more detailed description is found more or less unchanged in TEI P3, P4, and P5. My guess is that it gained the <head> child during the war on attributes, presumably to benefit some weirdo wanting to include markup inside the heading of a generated div, but I haven't looked through the electronic record.

lb42 commented 2 years ago

p.s. I've just noticed that the content model of <divGen/> currently references model.headLike rather than plain old <head>. Which allows for all sorts of bonkersness e.g. listPlace. I think that was a bit over zealous on someone's part: better make it empty again methinks.

bleekere commented 2 years ago

In discussion with @sydb and @HelenaSabel we found it hard to come up with a good use case. Perhaps @hcayless could suggest a case where it makes more sense for a <divGen> to be filled with the generated content? That would be really helpful. It seems normally sufficient to have @type, @subtype, or @ana = "generated" on <div>.

With regard to the comment of @lb42: <head> is the only member of model.headLike so there seems no risk of <listPlace> and other bonkersness being allowed in <divGen>, so no need to make it <empty>.

martindholmes commented 2 years ago

I don't think divGen is supposed to be filled; it's supposed to be replaced by a div that you generate.

bleekere commented 2 years ago

Indeed <divGen> is not supposed to have any content at all: it is supposed to be empty. So technically it should not contain <head> either, but in view of the Birnbaum doctrine we cannot make its datamodel empty. After discussing this at F2F council we decide to close this ticket.