search

TEIC / TEI

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

tagdocs elements are available in silly contexts #2306

Open martindholmes opened 2 years ago

martindholmes commented 2 years ago

The <elementSpec> element (to take one example) is available inside 126 different elements, which include <u>, <witness>, <epigraph>, and <figDesc>, to mention a few of the silliest. The ATOP team, in trying to figure out namespace hierarchies and other processing complexities, would really appreciate it if this could be cleaned up. It's surely arguable that the only logical parents of <elementSpec> are other tagdoc elements, specifically <specGrp> and <schemaSpec>. Similar issues apply to <classSpec> and other members of model.oddDecl, which is a member of model.inter, leading to its availability all over the place. Could we make better use of model.oddDecl to solve this problem?

sydb commented 1 year ago

My 2¢ — Unless someone (@lb42? @jamescummings? @laurentromary?) has a good reason why model.oddDecl should be a member of model.inter, I think we should just remove it as a corrigible error. (Which means that <specGrp> would then have to be made a member of model.inter, as it does make sense there. Now that I am thinking about it, should <specGrp> be a member of model.oddDecl?)

sydb commented 1 year ago

So not having heard an objection from @lb42 nor @jamescummings, and having gotten a thumbs-up from @laurentromary, I think we are good to go in removing model.oddDecl from model.inter (and taking care of the various fallout problems).

Question — Do we think this has to be deprecated? (I think our policy says “yes”, because this is a schema change that might invalidate a users’ file (however unlikely that is), we need to deprecate. But it is a bit of a pain, because we can’t just use @validUntil.)

bansp commented 1 year ago

I think it's a very bad practice to remove something skipping the agreed procedure and using ignorance as the argument/justification . The Guidelines are released into an open world. The fact that a brilliant Council member can't imagine something to be used in a 'strange' context doesn't mean that it is not being used (maybe wrongly, according to some/most practices, but still in good faith) :-) . I believe that the Council should in such cases always keep its end of the agreed (implied) bargain.

sydb commented 1 year ago

So given that no one has suggested that model.oddDecl remain a member of model.inter, or even offered an explanation for why it is there; given that several of us (at least @martindholmes, myself, and @laurentromary) think model.oddDecl should be removed from model.inter, and at least 2 of us (myself and @bansp) think it should be deprecated, I think this should be made GREEN for giving a deprecation warning if any of <classSpec>, <constraintSpec>, <dataSpec>, <elementSpec>, <macroSpec>, <moduleSpec>, <outputRendition>, or <specGrpRef> (note: NOT <specGrp>) appears as a child of any one of <dictScrap>, <entryFree>, <etym>, <form>, <gramGrp>, <head>, <l>, <lem>, <rdg>, <trailer>, <witness>, <xr>, <desc>, <fDescr>, <figDesc>, <fsDescr>, <meeting>, <rendition>, <tagUsage>, <accMat>, <acquisition>, <additions>, <cell>, <change>, <collation>, <condition>, <custEvent>, <decoNote>, <filiation>, <foliation>, <handNote>, <item>, <layout>, <licence>, <metamark>, <musicNotation>, <note>, <occupation>, <origin>, <provenance>, <q>, <quote>, <said>, <scriptNote>, <signatures>, <source>, <stage>, <summary>, <support>, <surrogates>, <textLang>, <typeNote>, <view>, <ab>, <add>, <camera>, <caption>, <case>, <colloc>, <corr>, <damage>, <def>, <del>, <docEdition>, <emph>, <gen>, <gram>, <hi>, <hyph>, <iType>, <imprimatur>, <lang>, <lbl>, <mod>, <mood>, <number>, <orig>, <orth>, <p>, <per>, <pos>, <pron>, <ref>, <reg>, <restore>, <retrace>, <rhyme>, <salute>, <secl>, <seg>, <sic>, <signed>, <sound>, <stress>, <subc>, <supplied>, <surplus>, <syll>, <tech>, <title>, <titlePart>, <tns>, <u>, <unclear>, <usg>, <writing>, <argument>, <body>, <castList>, <div>, <div1>, <div2>, <div3>, <div4>, <div5>, <div6>, <div7>, <epigraph>, <epilogue>, <figure>, <performance>, <postscript>, <prologue>, or <set>.

sydb commented 1 year ago

Two major thoughts on this one.

1. Not quite true It turns out our supposition that the *Spec elements are never inside prose, but rather only appear (and only need appear) in other specification elements is utterly false. Might be true for customization ODDs, but in the Guidelines themselves these elements often occur in prose contexts. Here is a list of each of the elements in question with its parent and grandparent. Those that do not match our previous intuition have preceding and following bangs.

    523 div/specGrp/elementSpec
!   115 div/div/classSpec  !
     90 div/specGrp/classSpec
     65 div/specGrp/specGrpRef
     62 specGrp/elementSpec/constraintSpec
     58 p/specGrp/elementSpec
     35 div/specGrp/dataSpec
!    31 div/div/specGrpRef  !
!    21 div/p/moduleSpec  !
!    18 div/p/specGrpRef  !
     15 attList/attDef/constraintSpec
      7 div/specGrp/macroSpec
      6 specGrp/classSpec/constraintSpec
      5 p/specGrp/specGrpRef
!     4 div/div/elementSpec  !
!     3 body/div/specGrpRef  !
      2 p/specGrp/classSpec
!     1 div/classSpec/constraintSpec  !
!     1 div/elementSpec/constraintSpec  !

Thus I no longer think this should be GREEN to go, but rather still requires a good bit of consideration and discussion.

2. Reverse logic If we were to implement this (or similar), I was thinking it would be a whole lot easier if we thought of it the other way around: that there should be a deprecation warning if any of <classSpec>, <constraintSpec>, <dataSpec>, <elementSpec>, <macroSpec>, <outputRendition>, or <specGrpRef> (note: NOT <specGrp>) is not a descendant of <specGrp> or <schemaSpec>. (Note that <moduleSpec> is not in the list, above (and may not really deserve bangs in (1)), because I actually suspected it would appear as a child of <div>, and suspect we may want to leave it that way. But maybe we should require it be a child <specGrp>?)

lb42 commented 1 year ago

From the list above, it seems clear that *spec elements are overwhelmingly given within specGrp elements in the Guidelines, which is really rather unsurprising, and might even be a sensible restriction (it is also one implied by the style guidelines for writing TEI P5, as far as I recall them). The very small number of exceptions to this I suggest should be considered corrigible errors in P5. As to where specGrp (and specGrpRef) should be permitted, they seem to me like typical members of model.inter -- they can appear between or within paragraphs, but not (for example) in headings or outside divs

sydb commented 1 year ago

I think what @lb42 is suggesting, above, is to restrict the vast majority of all specification elements so that they cannot be plopped directly inside prose, but can be a child of <specGrp>, which itself could be plopped directly inside prose as a member of model.inter.

I like this for two reasons. First, it presents a more simple system. If you are looking for specification stuff, this reduces the number of places you need look; and if you are encoding a document using tei_all (shame on you), this reduces the number of elements in your pop-up list that have nothing to do with transcribing humanities texts.

Second, unlike moving all specification stuff out of the prose (another possible solution), this still allows for a more “literate” style of ODD writing. In fact, the extra layer of compartmentalization might even encourage it.

ebeshero commented 1 year ago

Council green-lights this for @hcayless to work on and set a 6-month deprecation period.

HelenaSabel commented 3 months ago

Work done on 2024-04-03: required changes in the specs (missing deprecation notes), and required changes in the guidelines. Next steps: deprecation + schematron

sabineseifert commented 1 month ago

VF2F decision on 2024-04-13: Action on SB and HBS: attempt to deprecate this easily (if possible) and update Council on outcome