produce-xml-converter.xsl: XSpec tests and minor XSLT improvements

[galtm]

Committer Notes

Closes #86

XSpec tests:

• XSpec tests for produce-xml-converter.xsl in isolation
• Stub of tests for produce-xml-converter.xsl from the context of produce-json-converter.xsl
• Helper XSLT for use in XSpec tests
• Sample definition maps to provide testing contexts

XSLT improvements:

• Declare data types where known
• Declare context item for named templates
• Start XPath path from context instead of root, for testability

I ran the XSpec tests in Oxygen 26.0 and there are no failures.

All Submissions:

• [x] Have you followed the guidelines in our Contributing document?
• [x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• [x] Have you squashed any non-relevant commits and commit messages? [instructions]
• [ ] Do all automated CI/CD checks pass?

Changes to Core Features:

• [ ] Have you added an explanation of what your changes do and why you'd like us to include them?
• [ ] Have you written new tests for your core changes, as applicable?
• [ ] Have you included examples of how to use your new feature(s)?
• [ ] Have you updated all website and readme documentation affected by the changes you made? Changes to the website can be made in the website/content directory of your branch.

[github-actions[bot]]

XSpec Test Results

  2 files  ±0  40 suites  ±0   0s :stopwatch: ±0s 105 tests ±0  90 :white_check_mark: ±0  15 :zzz: ±0  0 :x: ±0  114 runs  ±0  99 :white_check_mark: ±0  15 :zzz: ±0  0 :x: ±0 

Results for commit 04f5159a. ± Comparison against base commit 04a4a4cd.

:recycle: This comment has been updated with latest results.

[galtm]

I rebased my commit off the develop branch and force-pushed, to refresh this pull request. The checks ran and all passed.

However, I don't think the new XSpec tests that are in this pull request are being picked up in the CI/CD testing.

[wendellpiez]

@galtm it is possible the configuration for XSpec runtimes here is skipping yours - we will have to look. Most likely there is a line to add in a Makefile or something similar.

What is your current sense? -- after merging the earlier two outstanding PRs I wonder if we should look at this together. The CI/CD doesn't actually have to run yet (in my view we can come back to that) but just in case there is something else. Apart from that question, how close is this to ready?

[galtm]

Apart from that question, how close is this to ready?

There are two comments that contain the word "reviewers" or "Reviewers" and that haven't been resolved yet.

[galtm]

What is your current sense? -- after merging the earlier two outstanding PRs I wonder if we should look at this together. The CI/CD doesn't actually have to run yet (in my view we can come back to that) but just in case there is something else.

Sure, we can look at it together next time we talk. Or, if you are inclined to merge this even before the CI/CD runs the new tests, I'm OK with that. If the CI/CD somehow picks up the new tests after the PR is merged, great; if not, one of us can create a GitHub issue so we won't forget to come back to this later.

[wendellpiez]

Another option maybe we should consider is merging this PR into develop, but into a common branch where we can test further, prior to the develop merge.

Indeed, such a staging branch might be a good place also to

• Consolidate #108 prior to merging it into develop
• Sort out CI/CD issues and house rules on XSpec deployment

And of course can work out remaining code/test issues there also.

As for xsl:template/@priority, I don't mind leaving them around when they make things more explicit. Of course comments make things more explicit as well.

Thanks Amanda!

[galtm]

I have no opinions about branching approaches, so whatever you want to do is fine with me.

[wendellpiez]

So ... I made branch merge-June2024 as a place to pull things together.

Let's try pointing this PR there and seeing what trouble we get into. The merge branch is the same as develop right now so I expect no issues.

Then on that branch I can address #117 before merging into develop.

[wendellpiez]

I'm merging this into a merge branch where the work can be reviewed before pushing up to develop.

Also will work on #117 in that branch.