ndw
commented
1 month ago Yes. There are a number of build automation/QA issues that we could work on. I've been dragging my feet a little bit because it's fiddly work and it isn't practical to start until the spec is "relatively stable". But perhaps we've reached that time.
Another obvious improvement that we could make is to change warnings about broken links and such into actual errors that prevent the PR from passing. That would encourage better markup hygiene.
For a number of functions we have provided executable specifications: that is, we have provided an XQuery function declaration that claims to be a conformant implementation of the function being specified.
We should add machinery to ensure that these reference implementations are correct: that is, that they compile, that they correctly run the examples in the spec, and that they can be used to run the tests for the relevant function in the test suite.
There are one or two cases where we have been doing this in an ad-hoc way by having additional test cases in the test suite that use the reference implementation (or a copy of it!) in place of the real function; but this is clumsy and the process should be automated.
It can be tied in with the mechanism that currently generates test cases from the examples in the spec.
We should probably handle several levels:
(a) There are cases where the reference implementation can be a simple XPath expression: for example the function
fn:local-name($x)deliversfn:local-name-from-QName(fn:node-name($x)).(b) In other cases a full XQuery function declaration is needed, especially where it makes use of a supporting helper function.
Ideally the reference implementation should use 3.1 syntax only (to make it easily testable on 3.1 implementations); but not if this sacrifices clarity, given that the primary audience is the human reader.