search

TEIC / TEI

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

Schematron extraction incomplete #1189

Closed TEITechnicalCouncil closed 8 years ago

TEITechnicalCouncil commented 11 years ago 
[Sorry, Sebastian or whomever else, but I don't have time to delve
more deeply into this right now. I will try to look into it
further early next week if you haven't already.]

When I process the attached ODD file using either commandline roma
(against the SF development stylesheets and Guidelines) or Roma
the website (against current released versions, I presume), I find
that only the <constraintSpec>s inside <elementSpec>, <attDef>,
and <schemaSpec> make it to the compiled ODD (i.e., those in
<classSpec> and <macroSpec> are dropped). Further, only those in
<elementSpec> and <attDef> make it from the compiled ODD into the
.rng file (i.e. the one in <schemaSpec> is dropped); all three
make it into the .isosch file.

Original comment by: @sydb

TEITechnicalCouncil commented 8 years ago

This issue was originally assigned to SF user: rahtz Current user is: sebastianrahtz

TEITechnicalCouncil commented 11 years ago

This is a bit odd. I checked an example from Jenkins, for a Schematron constraint I added to att.datable.xml, and it must be making it through the ODD and RNG process because it's being tested. If you look in the expected results:

http://teijenkins.hcmc.uvic.ca/job/TEIP5/ws/Test/expected-results/detest.log

the message " @calendar indicates the system or calendar to which the date represented by the content of this element belongs, but this date element has no textual content. (string-length(.) gt 0)" appears, so it must be working OK, as far as I can see. Unfortunately the generated detest.log from the last build is not there. Perhaps it's getting deleted after the build (which is actually not good, because we need it to tweak the expected results after a change).

Original comment by: @martindholmes

TEITechnicalCouncil commented 11 years ago

there are subtle forces at play here. I have corrected mistakes in the XSLT, so the constraints now pass through the gut of odd2odd unscathed (all other things being equal). However, when it comes to making a rule from a macroSpec or a classSpec, the generation in odd2relaxng fails because it feels it cannot work out a match context, other than a notional "*". What do you think should be generated from the constraintSpec embedded in a macroSpec, if no <rule> is provided?

Original comment by: @sebastianrahtz

TEITechnicalCouncil commented 11 years ago

PS please let me know if you need a quick stylesheet release before your workshop.

Original comment by: @sebastianrahtz

TEITechnicalCouncil commented 11 years ago 
What do you think should be generated from the constraintSpec
embedded in a macroSpec, if no <rule> is provided?

Gotta run, but my first thought was "an error message". I may think better of that knee-jerk reaction later, but ... :-)

Original comment by: @sydb

TEITechnicalCouncil commented 11 years ago

sounds like we need a Schematron constraint banning constraintSpec inside macroSpec....

Original comment by: @sebastianrahtz

TEITechnicalCouncil commented 10 years ago

I think this has gone as far as needed. there's a pending action to thinking about banning a constrainSpec inside a macroSpec, but that would be a new ticket

Original comment by: @sebastianrahtz

TEITechnicalCouncil commented 10 years ago

Original comment by: @sebastianrahtz