rudimentary documentation for ixml-test-catalog vocabulary now available

Test suite fans,

As fans of test suites, you will perhaps be pleased, or at least
interested, to know that over the weekend I improved a few shining
hours by drafting some rudimentary documentation for the XML
vocabulary specified in [1] and [2] and used in the ’straw test’
samples at [3].  The schema has been revised slightly and I have
modified all of the catalogs in [3] to be valid under the schema’s
current form.  (At least, I have tried; if you notice I missed
something please let me know.)

[1] https://github.com/cmsmcq/ixml-tests/blob/main/lib/test-catalog.rnc
[2] https://github.com/cmsmcq/ixml-tests/blob/main/lib/test-catalog.rng
[3] https://github.com/cmsmcq/ixml-tests/tree/main/tests-straw

The new documentation is at [4] and [5].

[4] https://github.com/cmsmcq/ixml-tests/blob/main/doc/test-catalog.tags.xml
[5] https://github.com/cmsmcq/ixml-tests/blob/main/doc/test-catalog.tags.xhtml

If I ever learn how to make github serve the XHTML as XHTML, or serve
the XML in a way that uses the stylesheet, I will do so, but for the
moment if you want formatted documentation you have to make a copy of
the repo and open the file from your file system or on your local web
server.

In writing the documentation and thinking about how test catalogs need
to be used, I have noticed a few rough spots, particularly in the
handling of ambiguous sentences, and most of all for sentences with
an infinite number of parse trees.  That suggests that the definition
of 'result' will need to change, though I hope to be able to avoid
invalidating anything that is currently valid.

It is worth saying, probably, that both the QT3 test suite and XSpec
solve similar problems by allowing the result specification to take
the form of a set of assertions expressed in XPath; I had hoped to
avoid the kind of machinery which seems to be needed to make that
work, but that may not be possible.

For the moment, anyone writing a test catalog using this vocabulary
who needs more powerful ways of describing the expected result can use
the 'app-info' element and embed whatever result specification their
test harness can use.  That is what I plan to do, to try to work out a
solution to the problem.

Comments and suggestions are, as always, welcome.

As fans of test suites will recall, the idea was that everyone would
work on a way of building and documenting test suites so we could
compare notes.  If anyone else has a publicly visible or shareable
test suite for ixml, I would be glad to hear about it.

Michael

p.s. This work on the test suite schema is (as you might have guessed)
in preparation for building a better test harness for Aparecium, so I
can run the tests in [3] and make some more.

Received on Monday, 8 November 2021 15:08:14 UTC