namespace being ignored?

[sydb]

@ebeshero discovered that if you supply an @validUntil in the past (or, presumably, upt to 60D in the future) inside an <egXML> you still get a deprecation error and warning during build. You shouldn’t, because the Schematron <rule> for said error and warning (which is in att.deprecated) has a @context that only includes elements in the TEI namespace ("tei:*[@validUntil]" to be precise), not the TEI Examples namespace. What gives?

[ebeshero]

Thanks for filing a ticket on this @sydb! I was pretty steamed over it this AM when I thought I'd easily resolved https://github.com/TEIC/TEI/issues/1964. (I'm also not sure why my local build wasn't generating an error over it, and I only saw it generate a build error when I checked it in to the remote dev--but that may be a different can of worms entirely.)

[dmj]

The Guideline's build process extracts all examples [1] and validates them using the embedded Schematron ruleset [2]. The ruleset used for the examples is derived from p5.isosch by replacing the TEI namespace [3]. The validation error during build happens when validating the extracted examples, not the main file.

[1] https://github.com/TEIC/TEI/blob/37e9ca20a0684e0d2694bb79eb37874dee4f050b/P5/antbuilder.xml#L209 [2] https://github.com/TEIC/TEI/blob/37e9ca20a0684e0d2694bb79eb37874dee4f050b/P5/antbuilder.xml#L217 [3] https://github.com/TEIC/TEI/blob/37e9ca20a0684e0d2694bb79eb37874dee4f050b/P5/antbuilder.xml#L120

[dmj]

Addendum: The part about extracting the examples is a red herring. The build runs p5examples.isosch.xsl against the main file. The TEI namespace is renamed to the TEI Example namespace in [3], thus the rules are "directly" matching the examples. That's why putting @valid = false to the egXML does not do anything.

[martindholmes]

@npcole and I think:

We should strip off the @validUntil during [1] above, so that validation of the examples does not trigger the error. If something in the example code itself is in fact no longer valid, that should be caught and reported (assuming not @valid="false"".

[sydb]

@dmj is, of course, correct about the main issue: that the examples are validated against Schematron by changing all of the Schematron rules so that they are looking for the Examples namespace, not the main TEI namespace. Not sure off the top of my head why flagging an example as @valid=false should not still indicate that the content is not intended to be valid regardless of which namespace we’re looking at. But it doesn’t really matter, because declaring every example that has a @validUntil as demonstrating invalidity is not a good solution. I am not sure the “get rid of @validUntil” is a great solution, either. That said, it is not easy to come up with a better one. (Perhaps just incrementing the initial digit of the @validUntil value by 1 would do the trick. This would force any value to be in the future, and yet still validate that @validUntil is an allowed attribute and that its value is an xsd:date.)

[martindholmes]

@sydb and I investigated this again, and our proposed solution is that at the P5/Utilities/extractegXML.xsl stage, we first directly check any @validUntil attributes to ensure that they are valid xsd:dates. If not, we raise an error immediately. If they are valid dates, we change them to a date one year in the future from the date the process is being run, solving the validation problem down the line. This means that the @validUntil is checked for content, and also later checked to ensure it's appearing on an element which is allowed to bear it, but doesn't trigger the unwanted validation error/warning caused by an expired or expiring-soon date. @sydb has created the branch sydb_Stylesheets-issue-417 to implement this.

[martindholmes]

The new branch seems to be working correctly and is building in a special job on my Jenkins. Time for a pull request on the TEI repo.

[sydb]

So the error 127 from the kindlegen command is not something to worry about? (P5/Makefile line 131.)

[martindholmes]

I don't have Kindlegen installed on my server because it's not open-source, and also it's now obsolete. I think we have a ticket for that, or if not, we should. Personally I don't think we should care about Kindle; Amazon should make their devices support the open ePub standard, or regular users should be able to convert an ePub to a Kindle thing using Calibre.

[martindholmes]

@sydb Is this now obsolete? Can I remove the Jenkins build job I have for it?

[sydb]

Yes, I think so.