Hi Peter, On Chapter documents and Spec files, I'm still getting this series of errors: Variable gse has not been declared (or its declaration is not in scope) (from p5odds.isosch) java.lang.IllegalStateException-Errors were reported during stylesheet compilation (from p5.nvdl) IllegalStateException - getSchemaProperties requires a schema (from the document) Does this align with what you're seeing? Cheers, Martin On 2021-02-03 7:27 a.m., Peter Stadler wrote:

I’m opening the URL http://jenkins.tei-c.org/job/TEIP5-dev/lastSuccessfulBuild/artifact/P5/relea... in my oXygen23 and hit the „Validate“ button.

This produces the following error report from oXygen: ``` <?xml version="1.0" encoding="UTF-8"?> <report xmlns="http://www.oxygenxml.com/ns/report"> <incident> <engine>Jing</engine> <severity>fatal</severity> <description>Variable gse has not been declared (or its declaration is not in scope)</description> <systemID>https://jenkins.tei-c.org/job/TEIP5-dev/lastSuccessfulBuild/artifact/P5/release/xml/tei/odd/p5odds.isosch</systemID> <operationDescription> <mainValidationFile>https://jenkins.tei-c.org/job/TEIP5-dev/lastSuccessfulBuild/artifact/P5/release/xml/tei/odd/p5.nvdl</mainValidationFile> </operationDescription> </incident> <incident> <engine>Jing</engine> <severity>fatal</severity> <description>Variable gse has not been declared (or its declaration is not in scope)</description> <systemID>https://jenkins.tei-c.org/job/TEIP5-dev/lastSuccessfulBuild/artifact/P5/release/xml/tei/odd/p5odds.isosch</systemID> <operationDescription> <mainValidationFile>https://jenkins.tei-c.org/job/TEIP5-dev/lastSuccessfulBuild/artifact/P5/release/xml/tei/odd/p5.nvdl</mainValidationFile> </operationDescription> </incident> <incident> <engine>Jing</engine> <severity>error</severity> <description>IllegalStateException - Errors were reported during stylesheet compilation</description> <systemID>https://jenkins.tei-c.org/job/TEIP5-dev/lastSuccessfulBuild/artifact/P5/release/xml/tei/odd/p5.nvdl</systemID> <operationDescription> <mainValidationFile>https://jenkins.tei-c.org/job/TEIP5-dev/lastSuccessfulBuild/artifact/P5/release/xml/tei/odd/p5.nvdl</mainValidationFile> </operationDescription> </incident> </report> ```

Now you probably ask: „Yes, but *what* schema is it trying to validate the file at http://jenkins.tei-c.org/job/TEIP5-dev/lastSuccessfulBuild/artifact/P5/relea... agains?!“ – I don’t know.

Peter

...

Am 03.02.2021 um 16:03 schrieb Bauman, Syd <s.bauman@northeastern.edu>:

Trying to validate which schema file against which schema?

Just trying to validate the schema itself in oXygen.

_______________________________________________ Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

_______________________________________________ Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

-- ------------------------------------- Humanities Computing and Media Centre University of Victoria mholmes@uvic.ca

The problem seems to be in the generated p5.isosch file, with one or more of these patterns: <pattern id="egia-elementSpec" is-a="en-gloss-if-any"> <param name="gse" value="tei:elementSpec"/> </pattern> <pattern id="egia-classSpec" is-a="en-gloss-if-any"> <param name="gse" value="tei:classSpec"/> </pattern> <pattern id="egia-dataSpec" is-a="en-gloss-if-any"> <param name="gse" value="tei:dataSpec"/> </pattern> <pattern id="egia-macroSpec" is-a="en-gloss-if-any"> <param name="gse" value="tei:macroSpec"/> </pattern> ... <pattern id="egia-attDef" is-a="en-gloss-if-any"> <param name="gse" value="tei:attDef"/> </pattern> ... <pattern id="egia-valItem" is-a="en-gloss-if-any"> <param name="gse" value="tei:valItem"/> </pattern> These patterns are used here: <pattern abstract="true" id="en-gloss-if-any"> <rule context="$gse[tei:gloss]"> <assert test="tei:gloss[ lang('en') ]">If there is any gloss inside <value-of select="name(.)"/>, there must be an English gloss.</assert> </rule> </pattern> What's weird there is this bit: <assert test="tei:gloss[ lang('en') ]"> Surely we'd expect <assert test="tei:gloss[@xml:lang='en']">, wouldn't we? That said, I've never actually used Abstract Patterns in Schematron so I may be missing something obvious. Cheers, Marttin On 2021-02-03 9:13 a.m., Peter Stadler wrote:

Yes, exactly!

...

Am 03.02.2021 um 17:25 schrieb Martin Holmes <mholmes@uvic.ca>:

Hi Peter,

On Chapter documents and Spec files, I'm still getting this series of errors:

Variable gse has not been declared (or its declaration is not in scope) (from p5odds.isosch)

java.lang.IllegalStateException-Errors were reported during stylesheet compilation (from p5.nvdl)

IllegalStateException - getSchemaProperties requires a schema (from the document)

Does this align with what you're seeing?

Cheers, Martin

On 2021-02-03 7:27 a.m., Peter Stadler wrote:

...

I’m opening the URL http://jenkins.tei-c.org/job/TEIP5-dev/lastSuccessfulBuild/artifact/P5/relea... in my oXygen23 and hit the „Validate“ button. This produces the following error report from oXygen: ``` <?xml version="1.0" encoding="UTF-8"?> <report xmlns="http://www.oxygenxml.com/ns/report"> <incident> <engine>Jing</engine> <severity>fatal</severity> <description>Variable gse has not been declared (or its declaration is not in scope)</description> <systemID>https://jenkins.tei-c.org/job/TEIP5-dev/lastSuccessfulBuild/artifact/P5/release/xml/tei/odd/p5odds.isosch</systemID> <operationDescription> <mainValidationFile>https://jenkins.tei-c.org/job/TEIP5-dev/lastSuccessfulBuild/artifact/P5/release/xml/tei/odd/p5.nvdl</mainValidationFile> </operationDescription> </incident> <incident> <engine>Jing</engine> <severity>fatal</severity> <description>Variable gse has not been declared (or its declaration is not in scope)</description> <systemID>https://jenkins.tei-c.org/job/TEIP5-dev/lastSuccessfulBuild/artifact/P5/release/xml/tei/odd/p5odds.isosch</systemID> <operationDescription> <mainValidationFile>https://jenkins.tei-c.org/job/TEIP5-dev/lastSuccessfulBuild/artifact/P5/release/xml/tei/odd/p5.nvdl</mainValidationFile> </operationDescription> </incident> <incident> <engine>Jing</engine> <severity>error</severity> <description>IllegalStateException - Errors were reported during stylesheet compilation</description> <systemID>https://jenkins.tei-c.org/job/TEIP5-dev/lastSuccessfulBuild/artifact/P5/release/xml/tei/odd/p5.nvdl</systemID> <operationDescription> <mainValidationFile>https://jenkins.tei-c.org/job/TEIP5-dev/lastSuccessfulBuild/artifact/P5/release/xml/tei/odd/p5.nvdl</mainValidationFile> </operationDescription> </incident> </report> ``` Now you probably ask: „Yes, but *what* schema is it trying to validate the file at http://jenkins.tei-c.org/job/TEIP5-dev/lastSuccessfulBuild/artifact/P5/relea... agains?!“ – I don’t know. Peter

...

Am 03.02.2021 um 16:03 schrieb Bauman, Syd <s.bauman@northeastern.edu>:

Trying to validate which schema file against which schema?

Just trying to validate the schema itself in oXygen.

_______________________________________________ Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

---

Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

-- ------------------------------------- Humanities Computing and Media Centre University of Victoria mholmes@uvic.ca _______________________________________________ Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

-- ------------------------------------- Humanities Computing and Media Centre University of Victoria mholmes@uvic.ca

Apologies (particularly to Peter & Martin), I did not get to this today,[1] and am getting too tired to be useful. If you’d like for me to short cut the conversation so far and just see if I get the same errors, could you say how and where you are getting them? ________________________________ Yes, exactly!

Well, then. That’s clearly problematic. (And why is it trying to validate against last successful instead of local? Not that it matters for this purpose.) So it looks like NVDL is validating the ISO Schematron schema before it tries to use it, and (incorrectly) finding it invalid, rejects it. I say “incorrectly” because the schema file being used[1] is valid with respect to $gse: * according to oXygen (v. 23.0) * against P5/iso-schematron.rnc[2] * against the 2015 ISO Schematron RELAX NG schema[3] Can we tell what schema oNVDL is using to validate p5odds.isosch? The parameter “gse” is set in 6 places (lines 318, 322, 326, 330, 404, & 467 in the current version), and referred to only once (line 506), so that must be where the error is being flagged. But (I think) this is exactly the kind of use that is intended. (As evidence, here are excerpts copied from the spec itself: ​ <sch:pattern abstract="true" id="table"> <sch:rule context="$table"> <sch:assert test="$row"> The element <name/> is a table. Tables contain rows. </sch:assert> </sch:rule> <sch:rule context="$row"> <sch:assert test="$entry"> The element <name/> is a table row. Rows contain entries. </sch:assert> </sch:rule> </sch:pattern> And <sch:pattern is-a="table" id="HTML_Table"> <sch:param name="table" value="table"/> <sch:param name="row" value="tr"/> <sch:param name="entry" value="td|th"/> </sch:pattern> <sch:pattern is-a="table" id="CALS_Table"> <sch:param name="table" value="table"/> <sch:param name="row" value=".//row"/> <sch:param name="entry" value="cell"/> </sch:pattern> <sch:pattern is-a="table" id="calendar"> <sch:param name="table" value="calendar/year"/> <sch:param name="row" value="week"/> <sch:param name="entry" value="day"/> </sch:pattern> ) So I am reasonably confident the reference to the $gse parameter in the value of @context is legal. Notes [1] https://jenkins.tei-c.org/job/TEIP5-dev/lastSuccessfulBuild/artifact/P5/rele... [2] Although for reasons I do not understand, I have to provide the -i​ switch on the commandline, otherwise it bombs with a java trace. [3] I do not know from where I got this schema. It is in my ISO 19757/​ directory. ________________________________ Open a Spec file in Oxygen and validate it. :-)

Maybe we could just simplify that stuff into conventional rules without params temporarily, for the sake of stabilizing this release, then work on it later? I must admit I have never used params in this way, and I had to go away and read the spec to understand what was happening. But having done that, I agree with you that it's right, assuming that what a parameter which has multiple is-a atts pointing at it is constructed in the form of a sequence of the elements found -- is this: $gse[tei:gloss] definitely right? Cheers, Martin On 2021-02-04 11:21 a.m., Bauman, Syd wrote:

Well, then. *That’s* clearly problematic. (And why is it trying to validate against last successful instead of local? Not that it matters for this purpose.)

So it looks like NVDL is validating the ISO Schematron schema before it tries to use it, and (incorrectly) finding it invalid, rejects it. I say “incorrectly” because the schema file being used[1] is valid with respect to $gse:

* according to oXygen (v. 23.0) * against P5/iso-schematron.rnc[2] * against the 2015 ISO Schematron RELAX NG schema[3]

Can we tell what schema oNVDL is using to validate p5odds.isosch?

The parameter “gse” is set in 6 places (lines 318, 322, 326, 330, 404, & 467 in the current version), and referred to only once (line 506), so that must be where the error is being flagged. But (I think) this is /exactly/ the kind of use that is intended. (As evidence, here are excerpts copied from the spec itself:

​  <sch:pattern abstract="true" id="table">     <sch:rule context="$table">       <sch:assert test="$row">         The element <name/> is a table. Tables contain rows.       </sch:assert>     </sch:rule>     <sch:rule context="$row">       <sch:assert test="$entry">         The element <name/> is a table row. Rows contain entries.       </sch:assert>     </sch:rule>   </sch:pattern>

And

  <sch:pattern is-a="table" id="HTML_Table">     <sch:param name="table" value="table"/>     <sch:param name="row" value="tr"/>     <sch:param name="entry" value="td|th"/>   </sch:pattern>   <sch:pattern is-a="table" id="CALS_Table">     <sch:param name="table" value="table"/>     <sch:param name="row" value=".//row"/>     <sch:param name="entry" value="cell"/>   </sch:pattern>   <sch:pattern is-a="table" id="calendar">     <sch:param name="table" value="calendar/year"/>     <sch:param name="row" value="week"/>     <sch:param name="entry" value="day"/>   </sch:pattern>

) So I am reasonably confident the reference to the $gse parameter in the value of @context is legal.

_Notes_ [1] https://jenkins.tei-c.org/job/TEIP5-dev/lastSuccessfulBuild/artifact/P5/rele... [2] Although for reasons I do not understand, I have to provide the |-i| ​ switch on the commandline, otherwise it bombs with a java trace. [3] I do not know from where I got this schema. It is in my |ISO 19757|/ ​ directory.

------------------------------------------------------------------------

Open a Spec file in Oxygen and validate it. :-)

_______________________________________________ Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

-- ------------------------------------- Humanities Computing and Media Centre University of Victoria mholmes@uvic.ca