XSLT-based implementation of navigation and document endpoints

[lueck]

I have developed generic XSLT packages for the navigation and document endpoints. A web service, where they will be deployed for several projects will follow soon.

https://github.com/SCDH/dts-transformations

Right now they are quite handy for developing and testing cite structure declarations.

Comments welcome!

[PonteIneptique]

That's great news! As a developer of a resource tailored for cite structure as well, I am wondering if we should have some kind of a test suite that shows level of compatibility with the elasticity of `citeStructure` and each other implementation, basically sharing input and output 😊. I love the fact you handle xPath 3 and its xQuery-like expression (I am not that familiar with those parts). How does this work with the cumulative way citeStructure is supposed to be ? (We talked about it with Hugh and how to declare potential non cumulative citeStructure without going back to the devilish refsDecl/cRefPattern).

[lueck]

As a developer of a resource tailored for cite structure as well, I am wondering if we should have some kind of a test suite that shows level of compatibility with the elasticity of citeStructure and each other implementation, basically sharing input and output 😊.

Yes, that would be great for implementers of DTS endpoints as well as for editors that develop cite structures. I definitively missed that during development. A community repository with test cases of TEI input source files and of output for specific parameters would be great.

I love the fact you handle xPath 3 and its xQuery-like expression

If you refer to the page-* citation trees declared in test/john.xml: Only some of them result in technically sound citation trees, but most of them do not. I wrote them during an investigation on how to declare citation trees for milestone-like markup, especially <pb/>. I've documented my findings in the project's Wiki.

(I am not that familiar with those parts). How does this work with the cumulative way citeStructure is supposed to be ? (We talked about it with Hugh and how to declare potential non cumulative citeStructure without going back to the devilish refsDecl/cRefPattern).

Although I'm not 100% sure about what "cumulative way citeStructure" entails, I think I have an idea about it. And I would say, that we should stick to it! It's well designed. That's even the result of my investigation on citation trees from milestone-like markup.

[PonteIneptique]

I have quite some files in https://github.com/distributed-text-services/MyDapytains/blob/main/tests/tei/ with some tests in

• https://github.com/distributed-text-services/MyDapytains/blob/main/tests/test_citeStructure.py
• https://github.com/distributed-text-services/MyDapytains/blob/main/tests/test_lb.py
• https://github.com/distributed-text-services/MyDapytains/blob/main/tests/test_tei.py

I guess I could make it as a separate package. They cover some weird situation normally.

[lueck]

I added a Makefile to my repo with a recipe for applying xsl/navigation.xsl on each of your TEI test files. It produces either a non-empty .json file or a non-empty error report in a .log file for each input file. I added the results in a tarball as an asset to the last release.

There are so many error reports because my function dts:get-citation-tree#2 for getting the right <refsDecl> is very strict: It assumes that the default citation tree is declared with the default="true" atttribute.

grep ERROR dist/navigation/*.log
dist/navigation/base_tei.json.log:ERROR: there must be exactly 1 default citation tree by declaration, but found 0
dist/navigation/double_tree_lb.json.log:ERROR: there must be exactly 1 default citation tree by declaration, but found 0
dist/navigation/lb_diff_ab.json.log:ERROR: there must be exactly 1 default citation tree by declaration, but found 0
dist/navigation/lb_same_ab.json.log:ERROR: there must be exactly 1 default citation tree by declaration, but found 0
dist/navigation/lb_uneven_ab_ending_node.json.log:ERROR: there must be exactly 1 default citation tree by declaration, but found 0
dist/navigation/lb_uneven_ab.json.log:ERROR: there must be exactly 1 default citation tree by declaration, but found 0
dist/navigation/simple_doc.json.log:ERROR: there must be exactly 1 default citation tree by declaration, but found 0
dist/navigation/tei_with_two_traversing.json.log:ERROR: there must be exactly 1 default citation tree by declaration, but found 0
dist/navigation/tei_with_two_traversing_with_n.json.log:ERROR: there must be exactly 1 default citation tree by declaration, but found 0
dist/navigation/xml_entity.json.log:ERROR: there must be exactly 1 default citation tree by declaration, but found 0
dist/navigation/xml_entity_tail.json.log:ERROR: there must be exactly 1 default citation tree by declaration, but found 0

However, the specification says:

If a Resource has a single CitationTree, that CitationTree object cannot have an identifier.

So, I will have to change my function so that in case of a single citation tree it get's this only one, no matter if it is declared default or not.

[lueck]

I fixed that.

For comparing the output of different implementations, I changed the deployment pipeline for releases: The output of my xsl/navigation.xsl for your TEI test cases in https://github.com/distributed-text-services/MyDapytains/blob/main/tests/tei/ is now added as an asset to every release.

For further comparison we could define parameters for the document endpoint. I would then add the results on the asset as well.

Current state: Generated member lists look reasonable as far as I can see. Only for double_tree_lb.xml there's still an error. It has two labelled citation tree, and the label 'default' does not make the tree the default tree. I think that trowing an error is right for the navigation endpoint in this case.

Is there a way in MyDapytains to make similar output for the test files on the command line? It's a bit hard to read the python test suite.

[PonteIneptique]

I am on vacation since the end of the afternoon, but I was thinking of making a simpler testsuite to follow after, using both the input and output of the Dapytains suite :)

[lueck]

Just to let you know when you're back: Here's a configurable driver for generating the output for a bunch of test cases: https://gist.github.com/lueck/d1476d00e07969685df5856518cdd053