Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

tagdocs elements are available in silly contexts #2306

Open
martindholmes opened this issue Jun 15, 2022 · 9 comments
Open

tagdocs elements are available in silly contexts #2306

martindholmes opened this issue Jun 15, 2022 · 9 comments
Assignees
@sydb @HelenaSabel
Labels
atop another TEI ODD processor CouncilResponsibility Status: Go TEI: ODD Type: Bug

Comments

@martindholmes
Copy link
Contributor

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?
@martindholmes martindholmes added the atop another TEI ODD processor label Sep 12, 2022
@sydb
Copy link
Member

sydb commented Oct 14, 2022

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
Copy link
Member

sydb commented Jan 16, 2023

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
Copy link
Member

bansp commented Jan 16, 2023

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
Copy link
Member

sydb commented Feb 7, 2023

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
Copy link
Member

sydb commented Mar 10, 2023

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
Copy link
Member

lb42 commented Mar 14, 2023

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
Copy link
Member

sydb commented Mar 18, 2023

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
Copy link
Member

ebeshero commented Jun 9, 2023

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

@HelenaSabel HelenaSabel assigned HelenaSabel and sydb and unassigned hcayless Mar 27, 2024
@HelenaSabel
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@sydb sydb

@HelenaSabel HelenaSabel

Labels
atop another TEI ODD processor CouncilResponsibility Status: Go TEI: ODD Type: Bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
8 participants
@hcayless @sydb @raffazizzi @bansp @lb42 @martindholmes @ebeshero @HelenaSabel