Unihan phase2

[duncdrum]

this obviously extends #1900
i can't get the deprecation to work though, from past commits i understand that I should update the expected results, but no matter how i copy, move, teleport the unopened validatorLog.xml it doesn't like it.

If anybody sees where my error lies I'd welcome the feedback. Should I maybe remove the examples on the spec pages which have the deprecation warning?
Phase 2 off #1805
close #1804

[duncdrum]

So it is telling me that my build is invalid because the elements i m trying to deprecate are going to be deprecated. If there is another error i don't see it. I need help here.

[ebeshero]

@duncdrum Yeah—looks like your Schematron tests are flagging every example in the Guidelines featuring the code you are deprecating. That is probably good, but do we need to do some editing of those examples to indicate they are invalid? I guess we would not want to remove them entirely because they can now help guide people to the new code.

[duncdrum]

And they are not supposed to be invalid until 2021. Do I maybe need to edit specific occurrences?

[martindholmes]

@duncdrum No time to check, but do you have a good validUntil date on your deprecations? They should be ignored by the build until the validUntil has expired.

[duncdrum]

validUntil="2021-07-09"

[duncdrum]

this concludes phase 2 from my side. It incorporates some Phase 5 changes since deprecating the children without changing the parent didn't work.

Now on to the real fun.

[martinascholger]

While looking at this, the checks have passed now. What was the reason for the error?

[duncdrum]

death by a thousand paper cuts. Normalizing the deprecations and adding @versionDates to examples finally got me to some actionable errors. Basically, the content model pitting unicodeProp etc as alternative to unicodeName meant that examples for other gaiji modules where no longer valid.

[peterstadler]

deployed at https://jenkins.tei-c.org/job/TEIP5-branch-unihan/lastSuccessfulBuild/artifact/P5/release/doc/tei-p5-doc/en/html/index.html for facilitating review

[duncdrum]

Thank you @peterstadler. Will this automatically update? I already found some prose typos, and my use of @mode=“change” does not seem to have had the desired effect. The closed list of values for e.g. unicodeProp seems to have been overwritten with the empty list from the att.gaijiProp class.

[peterstadler]

Just briefly regarding the Jenkins setup: Yes, it will build automatically from your duncdrum:unihan-phase2 branch. If you create phase3, please drop me a line ;)

[duncdrum]

could someone please comment on the way that att.gaijiProp provides attributes to e.g. unicodeProp but is itself not generated as a spec-att.gaijiProp.html. I have a missing spec in the webguidelines 😨 . Similarly, unicodeProp.xml provides a list of closed values for @name yet this is overwritten with the empty list from the non existing att.gaijiProp. Anything obvious I m doing wrong? bug in odd generation?

[lb42]

Is the classSpec getting included correctly in the output from odd2odd?

[duncdrum]

@lb42 good questions, what is the output of odd2odd? Is it run as part of make test or do I need to do that as a manual transform?

[duncdrum]

going to rebase and push some minor fixes since my build PR has been merged in he meantime.

[lb42]

Odd2odd generates a set of complete declarations corresponding to your odd. It should be run by make test but I think the output is deleted after use.

[martinascholger]

The only difference I noticed when comparing with other attribute class definitions is the <attList org="group">. I cannot find an example using this attribute. But ... ?

[lb42]

It's the default value. See the spec for attList.

[duncdrum]

There is definitely something fishy about the processing of change. process this object, and process its children, and those of any existing object with the same identifier, in change mode.

The class defines three attributes (@value, @name, @version) which all three xxxProp elements inherit. However, @name and @value define their value lists on unixxxProp spec so they replace the att.gaijiProp definition.@version is the other way around it has a list of values on the class spec page, which should be inherited by the elements. I can make these work individually but not in combination, as soon as change enters the picture the accompanying att.gaijiProp html page is no longer generated, and the class membership is no longer displayed on the elements spec pages.

Apart from testing each attribute solo, i have tried:

• not to have @version on the element specs and rely on inheritance
• provide @version on the element spec to be either changed, replaced, or added

This seems to be something @TEITechnicalCouncil might want to take a look at, but its not really a uniHan related problem.

[duncdrum]

If there is anything that i can do to help with review let me know. I think the new elements and removal of faulty info from the GL would actually make a good addition to upcoming release. Phase 3-6 are not really necessary for that.

[duncdrum]

soo ?

[sydb]

Not done reviewing, but done for now. Hope to do more of WD tomorrow.

[sydb]

Think I’m done. (At least for now.)

[sydb]

Think I’m done. (At least for now.)

[duncdrum]

ok i m going to make some final tweaks and do another rebase that squashes the review commits.

[sydb]

So … I went to try to see what was done with my various change requests, but I can’t figure out how. Is that because GitHub just doesn’t have an interface for that, or because @duncdrum did another rebase that squashed the review commits 4 days ago?
Either way, is there an easy way to see what was done with each of my requested changes?

[duncdrum]

You can check the batch of changes by looking at the last commit, or you have to look through Each outdated conversation marker in the history up here

[sydb]

I’ve glanced at all of @raffazizzi’s proposed changes, and the English ones all look good to me.

[raffazizzi]

@sydb thanks for looking this over again! Could you approve your review today? If I don't hear back by mid-day EST 2020-02-07, I'll go ahead and merge.