Add warning when using <constraintSpec> inside <classSpec> #2173

HelenaSabel · 2021-08-20T18:22:54Z

As a temporary solution for Stylesheets ticket #519, a warning should be fired whenever a <constraintSpec> is used inside <classSpec> without an explicit @context.

The text was updated successfully, but these errors were encountered:

sydb · 2021-08-21T02:54:11Z

Actually, since <constraintSpec> is permitted in lots of (mostly ridiculous) places,[1] methinks the warning should be fired whenever a <constraintSpec> is used without an explicit @context anywhere an intelligent context is not generated by the Stylesheets.

So the first step in resolving this ticket is generating the list of places the Stylesheets do provide an intelligent context. Schematron is processed in at least 2 different ways, I submit that if the context is generate in either method, we should not issue a warning.

[1] The list is: <ab>, <accMat>, <acquisition>, <add>, <additions>, <argument>, <attDef>, <body>, <camera>, <caption>, <case>, <castList>, <cell>, <change>, <classSpec>, <collation>, <colloc>, <condition>, <corr>, <custEvent>, <damage>, <dataSpec>, <decoNote>, <def>, <del>, <desc>, <dictScrap>, <div>, <div1>, <div2>, <div3>, <div4>, <div5>, <div6>, <div7>, <docEdition>, <elementSpec>, <emph>, <entryFree>, <epigraph>, <epilogue>, <etym>, <fDescr>, <figDesc>, <figure>, <filiation>, <foliation>, <form>, <fsDescr>, <gen>, <gram>, <gramGrp>, <handNote>, <head>, <hi>, <hyph>, <iType>, <imprimatur>, <item>, <l>, <lang>, <layout>, <lbl>, <lem>, <licence>, <macroSpec>, <meeting>, <metamark>, <mod>, <mood>, <musicNotation>, <note>, <number>, <occupation>, <orig>, <origin>, <orth>, <p>, <per>, <performance>, <pos>, <postscript>, <prologue>, <pron>, <provenance>, <q>, <quote>, <rdg>, <ref>, <reg>, <rendition>, <restore>, <retrace>, <rhyme>, <said>, <salute>, <schemaSpec>, <scriptNote>, <secl>, <seg>, <set>, <sic>, <signatures>, <signed>, <sound>, <source>, <specGrp>, <stage>, <stress>, <subc>, <summary>, <supplied>, <support>, <surplus>, <surrogates>, <syll>, <tagUsage>, <tech>, <title>, <titlePart>, <tns>, <trailer>, <typeNote>, <u>, <unclear>, <usg>, <view>, <witness>, <writing>, and <xr>. Aren’t you sorry you asked?

sydb · 2021-08-21T03:29:49Z

Contexts in which odds/teiodds.xsl generates a `@context`

attDef//
elementSpec//

Contexts in which odds/extract-isosch.xsl generates a `@context`

elementSpec//attDef//
elementSpec//
schemaSpec//, but not one of above (I think this should just be schemaSpec/)

Note that it seems like @validUntil generates proper @context for deprecation when it is on at least macroSpec, elementSpec//attDef, classSpec//attDef, elementSpec, elementSpec//valItem, and macroSpec.

Contexts in which odds/extract-isosch.xsl generates a poor-man’s `@context` and issues a warning

classSpec//attDef//
classSpec//

These should still be invalid, IMHO. (That is, I think the TEI schema should still say to a user “don’t use Schematron without a context in a <classSpec>, even if the processor would also issue a warning.)

Contexts in which odds/extract-sch.xsl generates a proper `@context`

I don’t think we care, because I don’t think this program is used anymore at all.

result

So it seems to me that

<rule context="constraintSpec[@scheme eq 'schematron' and not( .//@context )]">
  <assert test="ancestor::elementSpec | ancestor::attDef | parent::schemaSpec"> WARN </assert>
</rule>

would almost do the job. Only thing is, have to think about <specGrpRef>s, which add another (large) layer of complexity.

martindholmes · 2021-08-21T14:23:36Z

It seems to me that allowing constraintSpec anywhere except tagdocs elements makes no sense at all. In the case of elementSpec/attDef, IIRC the context that is generated is often wrong; I'll test that out and report back.

But when you say elementSpec//, do you mean any descendant of elementSpec? That seems wrong. I would say (in all cases) direct child only.

sydb · 2021-08-23T22:14:08Z

Well, yes and no. I did mean “descendant of <elementSpec>”, because that is what the Stylesheets say. While I would be more than happy to go about restricting where <constraintSpec> can go (elementSpec/listRef/ref/constraintSpec; really??), that is another ticket.

There is, of course, at least one sensible place inside <elementSpec> for <constraintSpec> to go other than as direct child: inside an <attDef>. Because a context is automaticaly generated in that case, it should not (IMHO) get a “you did not use a context” warning.

In the specific case of elementSpec//attDef (which is what I presume you mean), I do not know what odds/teiodds.xsl does. But odds/extract-isosch.xsl does

          <xsl:value-of select="ancestor::elementSpec/@nsp"/>
          <xsl:value-of select="ancestor::elementSpec/@ident"/>
          <xsl:text>/@</xsl:text>
          <xsl:value-of select="ancestor::attDef/@nsp"/>
          <xsl:value-of select="ancestor::attDef/@ident"/>

which looks perfectly correct to me. (By this pass the @nsp attribute has been placed an all the spec elements.) Probably better expressed as

          <xsl:sequence select="
              ancestor::elementSpec/@nsp
            ||ancestor::elementSpec/@ident
            ||'/@'
            ||ancestor::attDef/@nsp
            ||ancestor::attDef/@ident"/>

these days.

sydb · 2021-09-13T03:36:42Z

OK, I think I now have a working solution. As expected, the Schematron to test this ignoring <specGrp> and <specGrpRef> is all but trivial; the Schematron to test this taking account of (only local) <specGrp> and <specGrpRef> is quite complex. (Perhaps someone else can simplify it.)

In any case, this needs testing, and it is not easy to test. While I have created a single ODD file that both contains the proposed constraint and has test cases for it, you can’t just generate schemas from it and validate against them because, by definition, the Schematron schemas generated from some of the test cases have errors. (That’s why we want a constraint to catch such problems at validation stage!)

So I have also created a test Schematron file by extracting the useful bits out of the generated .isosch file.

So it seems to me the procedure for testing this is to do at least the following:

download the ODD and Schematron file (which are together in issue_2173_2023-02-01T13.zip.)
read the ODD file (either directly or generating HTML or whatever if you prefer)
scan through the extracted Schematron file enough to convince yourself it is what it claims to be
validate the ODD file against the Schematron file
Hope you get only the expected messages

And we need better wording of the warning messages themselves, of course.

If that all goes OK (including someone coming up with better messages), I will generate a pull request with the new constraint (in Specs/constraintSpec.xml, presumably).

sydb · 2023-02-01T18:38:10Z

Note — I have edited the previous post by putting a new test file. The main difference is that the old test file was missing the word “not” in a key bit of prose which could have lead to serious confusion. 😕

sydb · 2023-06-09T14:13:36Z

Council makes GREEN to implement, with the further note that we are seriously considering requiring <sch:rule> with @context always. (Which would make this ticket obsolete.)

sydb self-assigned this Aug 21, 2021

sydb added this to the Guidelines 4.3.0 milestone Aug 21, 2021

martinascholger removed this from the Guidelines 4.3.0 milestone Aug 31, 2021

martinascholger added this to the Guidelines 4.4.0 milestone Oct 14, 2021

HelenaSabel self-assigned this Oct 14, 2021

peterstadler added TEI: ODD Type: FeatureRequest Status: Needs Discussion labels Dec 21, 2021

martinascholger modified the milestones: Guidelines 4.4.0, Guidelines 4.5.0 Apr 19, 2022

peterstadler removed this from the Guidelines 4.5.0 milestone Oct 24, 2022

martindholmes added the atop another TEI ODD processor label May 31, 2023

sydb added Status: Go and removed Status: Needs Discussion labels Jun 9, 2023

sydb added a commit that referenced this issue Jun 17, 2023

First crack at addressing #2173 in a serious way.

9c8e8cc

bansp mentioned this issue Jun 17, 2023

First crack at addressing #2173 in a serious way. #2442

Draft

martindholmes added the TEI: Schematron label Aug 9, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add warning when using <constraintSpec> inside <classSpec> #2173

Add warning when using <constraintSpec> inside <classSpec> #2173

HelenaSabel commented Aug 20, 2021

sydb commented Aug 21, 2021 •

edited

sydb commented Aug 21, 2021 •

edited

martindholmes commented Aug 21, 2021

sydb commented Aug 23, 2021 •

edited

sydb commented Sep 13, 2021 •

edited

sydb commented Feb 1, 2023

sydb commented Jun 9, 2023

Add warning when using <constraintSpec> inside <classSpec> #2173

Add warning when using <constraintSpec> inside <classSpec> #2173

Comments

HelenaSabel commented Aug 20, 2021

sydb commented Aug 21, 2021 • edited

sydb commented Aug 21, 2021 • edited

Contexts in which odds/teiodds.xsl generates a @context

Contexts in which odds/extract-isosch.xsl generates a @context

Contexts in which odds/extract-isosch.xsl generates a poor-man’s @context and issues a warning

Contexts in which odds/extract-sch.xsl generates a proper @context

result

martindholmes commented Aug 21, 2021

sydb commented Aug 23, 2021 • edited

sydb commented Sep 13, 2021 • edited

sydb commented Feb 1, 2023

sydb commented Jun 9, 2023

sydb commented Aug 21, 2021 •

edited

sydb commented Aug 21, 2021 •

edited

Contexts in which odds/teiodds.xsl generates a `@context`

Contexts in which odds/extract-isosch.xsl generates a `@context`

Contexts in which odds/extract-isosch.xsl generates a poor-man’s `@context` and issues a warning

Contexts in which odds/extract-sch.xsl generates a proper `@context`

sydb commented Aug 23, 2021 •

edited

sydb commented Sep 13, 2021 •

edited