Well, the build is now a lot healthier. The new validation method which checks examples against the schema being documented, rather than TEI All as before threw up a number of bugs in the source of the simplePrint odd. So not all change is bad!

The Make still fails though: now with a message the meaning of which defeats me: Anyone got any idea what's going on here?

BUILD FAILED
/home/lou/Public/TEI/P5/Test/antruntest.xml:147: Fatal error during transformation using /usr/share/xml/tei/stylesheet/profiles/tei/relaxng/to.xsl: I/O error reported by XML parser processing https://www.tei-c.org/release/xml/tei/Exemplars/mathml2-qname-1.mod.rng: Server returned HTTP response code: 429 for URL: https://www.tei-c.org/release/xml/tei/Exemplars/mathml2-qname-1.mod.rng; SystemID: file:/usr/share/xml/tei/stylesheet/odds/teiodds.xsl; Line#: 1292; Column#: 21

Total time: 9 seconds
Makefile:54: recipe for target 'tei_allPlus.special' failed
make: *** [tei_allPlus.special] Error 1

I can live happily without tei_allPlus.special tbh.

Hi Lou,

Our main objective was to try to get the build working ahead of the release, not to say that what was done in the simplePrint ODD was wrong. I think you're right that there's something broken in the Stylesheets that wasn't broken before, but all our attempts to figure that out have failed so far. You're very welcome to help with that, and I really wish you would, rather than shouting at people.

Cheers,
Martin

On 2019-06-29 8:50 a.m., Lou Burnard wrote:

Thinking about this debacle again, it seems to me that the approach taken in issue #370 (oh tei_simpleprint.odd has stopped working: so there must be something wrong with it) is really not defensible.

1. The unmodified tei_simplePrint odd is structured in exactly the same way as countless other ODDs, not excluding the TEI Guidelines. It has free floating globs of specification elements, which are invoked from a single schemaSpec by means of specGrpRefs.

2. The only thing which is slightly different about it is that some objects are declared more than once in multiple specGrps, with  @mode=change. This is because the specGrps are organised thematically (for example one contains changes needed to introduce processing models, another contains changes needed to introduce schematron rules). This kind of logical organisation is perfectly reasonable as far as I am aware, indeed why else bother to have specGrps.

3. The only objection I can see to it is that an ODD processor has to decide how to combine two or more @mode=change specs. It's not just a matter of applying one set of changes: there may be a bunch of them. This is kind of the way unification grammars work in NLP: you build up the complete spec one bit at a time. Yes, occasionally you may find contradictions -- one spec adds an attribute x (say) which another one deletes, or gives a different datatype to.  But this is not the only place where ODD processing is underspecified and rules of thumb are not hard to imagine (e.g. delete always wins; in the absence of delete, most recent modification always wins; etc.).

4. Moreover, and this is where I am really a bit annoyed, THIS USED TO WORK! So some infrastructural change has made it impossible to run the makefile and impossible to use the simpleprint odd as originally designed. And instead of trying to find what change has caused this, we are shooting the messenger. This my friends is called zealotry. In the immortal words of Michael SpMcQ in another recent context, "please don't".