Create l3build testing for tagging structure of example documents

[zauguin]

Add l3build configuration to use latex3/pdf_structure to do automated test of the XML representation of the tagging of all test documents in tagging-status.

Currently no special extensions are used, the tests end with .tex to reduce differences.

[FrankMittelbach]

a bit overwhelming that :-)

Right now we have tests that fail (or give wrong results). So I wonder if we should not distinguish the good and the bad ones in some way. Now sure how. Perhaps we should have an extension like .lxt instead of .tex and only change to that for files where we consider the result already "good"?

Or what would you suggest?

[davidcarlisle]

@FrankMittelbach (@zauguin ) possibly we should not commit the reference xml files for bad cases so only the good xml are checked in?

Apart from that, I couldn't get these tests to fail locally, it doesn't seem to be diffing the xml at any stage?

[FrankMittelbach]

The reason why I was suggesting to have a special extension other than .tex is that then it is easy to find files that fail (or are not yet checked = those that are still .tex). Of course you can also look for files that don't have an xml output but that is much more complicated to to imo

[davidcarlisle]

@FrankMittelbach yes we should probably do both: checked in wrong xml trees probably end up being confusing.

[zauguin]

@davidcarlisle

yes we should probably do both: checked in wrong xml trees probably end up being confusing.

I like having even wrong XML trees checked in since this makes it clearer how they are broken and also makes it more visible more these are affected by changes.

Maybe we could have both types checked in but separated? Something like

• Unknown state: .tex tests with .draft.xml reference
• Known good: .lst tests with .struct.xml reference
• Known broken: .bad tests with .broken.xml references

or three testfiles directories to allow running them separately?

[zauguin]

Apart from that, I couldn't get these tests to fail locally, it doesn't seem to be diffing the xml at any stage?

That should be fixed now, it triggered a l3build issue before.

[FrankMittelbach]

@davidcarlisle

yes we should probably do both: checked in wrong xml trees probably end up being confusing.

I like having even wrong XML trees checked in since this makes it clearer how they are broken and also makes it more visible more these are affected by changes.

Maybe we could have both types checked in but separated? Something like

* Unknown state: `.tex` tests with `.draft.xml` reference

* Known good: `.lst` tests with `.struct.xml` reference

* Known broken: `.bad` tests with `.broken.xml` references

how should that work? I mean conceptually?

You would manually change the name? but the test would still work?

or three testfiles directories to allow running them separately?

I think it would be simpler do do it this way. It still means some manual moving, but if we then all all 3 test dirs we would even notice if a formally broken file suddenly changes (for the better hopefull).

[FrankMittelbach]

Hi @zauguin, what is the status here?

[zauguin]

Hi @zauguin, what is the status here?

I'm trying to get this to pass (which keeps breaking due to being slow and the repo involving). Once I have this in a state where the Workflow passes and the branch is up to date with main I will merge and then due optimization after merging to avoid further rebasing.

[FrankMittelbach]

Hi @zauguin, what is the status here?

I'm trying to get this to pass (which keeps breaking due to being slow and the repo involving). Once I have this in a state where the Workflow passes and the branch is up to date with main I will merge and then due optimization after merging to avoid further rebasing.

We can refrain to do updates or additions to test files for a while if that helps, ie hold merging an new stuff by @mbertucci47 or me or anybody else.