Support for a simplified rule-XPath-value DSL

[electrickery]

The JUnit style of checking values at a XPath works good for a limited set of values. When more values are to be checked, the code becomes unwieldy. A pattern to extract the check-data from the code is using a multi-column text file approach, somewhat similar to Fitnesse. An implementation already being used/evaluated is a three column text file, like:

# rule              | XPath                             | value
stylesheetVersion   | /add/document/stylesheetVersion   | 33

Each line is a check, unless it is empty or starts with a #. The value should be a literal, but (later) adding regular expression matching could be useful too.

[renevanderark]

@electrickery do you propose a runner which picks up the dsl from the command-line, or in a CI environment directly? In that case I need some ideas on:

1. where are xslt's under test declared?
2. where is xml input declared?
3. where are the xpaths declared?
4. will it recurse a directory tree?

A more clean solution might be to just ship an interpreter for the DSL and have the tester write junit code themselves. what would you prefer?

[electrickery]

Of course the options are legion, but for the current needs, a setup close to the jUnit model is ok.

The DSL as it is contains only three types of lines:

• rule triplets, existing of a rule/check-name, an XPath and a literal value,
• comment lines, starting with a # (the "#version: ..." line is a special case),
• empty lines, containing only whitespace.

Adding more line types or sections with properties like paths to files could make the current test code a generic runner but at the price of making it less generic.
Leaving most configuration in the jUnit test code is best for now.
One reason for extracting the rules/checks to a DSL ws to keep the actual junit test code compact.
Another is that non-java programmers can maintain the set of rules.