Deprecate `<superEntry>`

[trishaoconnor]

While working with @sydb on #2456, the discussion with @laurentromary highlighted that <superEntry> may no longer be needed now that <entry> is recursive.

Proposal: Have a long deprecation period to facilitate legacy usage of <superEntry> with the suggestion to use <entry> with the value "relatedEntry" instead going forward.

[ebeshero]

I'm just triaging the unassigned tickets that have the next release milestone on them--I put all three of you on this one (@HelenaSabel @sydb @trishaoconnor) so we can keep an "eye" on it and make sure it's done by refrigeration...but please feel free to punt to someone else!

[sydb]

Question (particularly of @laurentromary) — what should the suggested value of @type of <entry> be when it is being used to replace what we currently call <superEntry>? (The value suggested in the OP above is obviously a copy-and-paste error from #2487. :-) Suggestions: "super", "encompassing", or no @type at all (the theory being that one does not need an attribute to differentiate an entry that holds an entry from one that does not: just //entry[ not( entry ) ] vs //entry[ entry ] will differentiate them just fine).

BTW, I am presuming when we implement this ticket we should change the content model of <entry> to

( hom | sense | pc | model.entryPart.top | model.global | model.ptrLike )+
|
(  ( form?, entry+ ) | dictScrap )

i.e., either the content of a normal <entry> or the content of that which used to be a <superEntry>.

[laurentromary]

Concerning the content model. The trick is simply to make <entry> a member of model.entryPart.top. You'll get recursively while keeping the content model nice and clear.

[laurentromary]

As to @type on <entry>, the TEI Lex group will discuss this more precisely (we have a 2 day workshop mid-February). We will probably not come with a definite set of value since it may change from one dictionary editorial profile to another (think for instance of root based dictionaries where entries are grouped together in roots - e.g. for Arabic), but we could at least suggest reformulation for all exemples in the guidelines using <superEntry>.

[sydb]

@laurentromary — any thoughts from the TEI Lex group on the value of the @type attribute of an <entry> that has other <entry> elements as its children? My thoughts are things like "super", "wrapping", "encompassing", "outer", or "group".

[trishaoconnor]

Added deprecation information and updated the prose and examples accordingly, see PR #2532.

[laurentromary]

After iterating on this with @ttasovac we would suggest to have a default value of wordFamily there within an open list and avoid a more linguistically marked set of values, nor something not really meaningful (such as group :scream:). wordFamily is already something we suggest in the TEI Lex 0 documentation.

[sydb]

European subgroup (with @sydb), in particular @tuurma, prefers no @type on the wrapping <entry> (that replaces what we now call <superEntry>). Thus we have changed it so that one example uses "wordFamily" and the other has no @type at all.

[GusRiva]

This issue was addressed in pull request: #2532