I know Syd was trying to get rid of the old datatypes. But when I was a lad, we made sure that the P5 dev tree was left usable after a release, even if it meant reverting desirable changes that hadn't quite worked. On 04/10/18 10:34, Hugh Cayless wrote:

It’s all because you went and invented Pure Odd. Syd was just getting rid of the old data types, etc.. I don’t think he’s merged those changes yet.

Hugh

...

On Oct 3, 2018, at 5:00 PM, Lou Burnard wrote:

I updated Stylesheets, and pulled the latest P5 sources, and ran "make clean; make"

Everything worked up to the point where the "special purpose" validity checks began. At that point I got a shed load of annoying errors, starting with

BUILD: Check validity with special-purpose XSL code, looking for bad links etc ANT_OPTS="-Xss2m -Xmx752m -Djava.awt.headless=true" ant -q -lib Utilities/lib/saxon9he.jar -f antbuilder.xml -DXSL=/usr/share/xml/tei/stylesheet validators [echo] Run Schematron script (normal part of Guidelines) [echo] Run Schematron script (Examples in Guidelines marked as valid) [echo] Run ad hoc XSLT validators

BUILD SUCCESSFUL Total time: 27 seconds <Messages> <ERROR>Schematron error: The data.certaintyconstruct is outdated (as of 2018-10-01); ODD processors may ignore it, and its use is no longer supported [Test: @validUntil cast as xs:date ge current-date()] Location: /TEI[1]/text[1]/body[1]/div[1]/div[6]/macroSpec[1]</ERROR> <WARNING>Schematron warning: The data.certainty construct becomes outdated on 2018-10-01 [Test: @validUntil cast as xs:date ge $advance_warning_period] Location: /TEI[1]/text[1]/body[1]/div[1]/div[6]/macroSpec[1]</WARNING> [and so on for a few screens, concluding with]

<WARNING>Schematron warning: The macro.anyXML construct becomes outdated on 2018-06-12 [Test: @validUntil cast as xs:date ge (current-date() + (60*xs:dayTimeDuration('P1D')))] Location: /TEI[1]/text[1]/body[1]/div[1]/div[4]/div[1]/specGrp[1]/macroSpec[7]</WARNING>

...

<ERROR>Schematron error: Error: both the versionDate and xml:lang attributes on "remarks" are required when it is a child of "attDef". [Test: not( @xml:lang and @versionDate )] Location: /TEI[1]/text[1]/body[1]/div[22]/div[3]/specGrp[1]/elementSpec[4]/attList[1]/attDef[1]/remarks[1]</ERROR>

Makefile:185: recipe for target 'valid' failed make: *** [valid] Error 1 lou@foxglove:~/Public/TEI/P5$

Tell me, what have I done to deserve this?

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

I guess the way I'd look at it is that because of the deprecation, the build is already broken. It might be broken differently if you merge your branch into dev, but hopefully it'll be less broken. Even if what you have isn't 100% right, it's still going to be better, and we can work on fixing it completely. H On Thu, Oct 4, 2018 at 12:58 PM Syd Bauman wrote:

But you mis-interpret the problem. I did *not* check in a version of P5 w/o the old datatypes to dev. (I created a new branch for it.) But the build process barfs on the old datatypes, because it notices that the @validUntil has expired. (Because I haven't checked into dev the version that no longer has those old datatypes.) I.e., this is more an error of omission than comission.

The good news is I expect to have a good chunk of time to look at this within the next 36 hours.

But perhaps I should just try checking in the changes I made to my local branch. After all, it won't be worse than it is now -- broken.

Hugh or other gitxpert -- is there a safe way to a) merge changes made recently in dev to sydb-endDeprecation_2018-10-01 b) merge sydb-endDeprecation_2018-10-01 back into dev such that it can be backed out if things are dramatically worse (which I don't think they will be)?

For that matter, do I need to even bother with (a)?

...

I know Syd was trying to get rid of the old datatypes. But when I was a lad, we made sure that the P5 dev tree was left usable after a release, even if it meant reverting desirable changes that hadn't quite worked.

...

...

It’s all because you went and invented Pure Odd. Syd was just getting rid of the old data types, etc.. I don’t think he’s merged those changes yet.

...

...

...

I updated Stylesheets, and pulled the latest P5 sources, and ran "make clean; make"

Everything worked up to the point where the "special purpose" validity checks began. At that point I got a shed load of annoying errors, starting with ... Tell me, what have I done to deserve this?

---

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

Point taken, Lou. But we have the build die as soon as the @validUntil is over on purpose, to force our hand at paying attention to getting the deprecated thingy out. So (IMHO), we can't just automatically pop up the deprecation date forward. That said, you're right, even if (as Martin put it elsewhere earlier today) "dev [is] the branch which will break things, while master is the branch that shouldn't break", we shouldn't leave dev broken for too long, lest other errors that don't get checked correctly become introduced. But the good news is I'm working on a fix now ... can't imagine I'll get it done before my next meeting in 12 mins, but (crossing fingers) likely shortly thereafter. (And, BTW, the thing that seems to break Travis's build on this is not the loss of data.*, but the loss of <catchwords> other than a descendant of <msDesc>.)

Er no,  I am not misinterpreting the problem. The problem is that the current build is broken, and it's not as if the current brokenness was a complete surprise. You knew this was coming months ago, when you set the deprecation date on the old datatypes. If implementing the deprecation is proving tricky, the answer (in my old fashioned opinion) is not to say "oh well it'll work eventually when Syd gets round to it", but to say "drat, we will have to move the deprecation date forward", sine die if necessary.

...

I guess the way I'd look at it is that because of the deprecation, the build is already broken. It might be broken differently if you merge your branch into dev, but hopefully it'll be less broken. Even if what you have isn't 100% right, it's still going to be better, and we can work on fixing it completely.