A downloadable version of the code is attached to this blog post. It includes not only an executable version of the code, but also a copy of the validation code at this point in time and the source to the executable version.

I was lucky to be able to attend the #coursedata meetup last Tuesday in Aston and it was fantastic to meet the instutions that are creating XCRI feeds and to see those feeds starting to trickle into the demonstrator applications that JISC have funded.

During the technical sessions I was approached separately by two individuals who were interested in integrating the validator into their build process. Whilst the online validator isn’t the best solution for these scenarios, there’s absolutely no reason why the validator code can’t be utilised to achieve the end-game. As a result I decided to write this blog post to explain how the validator can be compiled into an executable that could be used as part of an automated process and include a downloadable version for people who may want to do just that.

This post builds upon a version I built to help an institution that were having issues with the validator timing out for long-running queries. The code itself currently outputs a HTML file – without styling – for ease of the person who was using it but there’s no reason why this couldn’t be altered to output into XML or something that could be queried by a separate application. Also note that I’ve not touched on the actual integration of this with your build systems (as the variation would be too significant to cover).

Making the validator work locally really only involves three steps:

  1. Organising some dependencies
  2. Calling the validation routines
  3. Outputting the results

I’m not going to go through every single line of code (there’s the attachment if you really want to), but the important elements are detailed below.

Organising some dependencies

This code is within the “Program” class within the XCRI.Validator.App project
The validation code itself requires some other elements in order to work. In addition to some objects required for the program to function, it also takes a “Validation Module” (an XML file containing rules that are run on the input file) and an “Interpretation Module” (an XML file that contains interpretations for common issues thrown by the built-in .NET XML validation). These two files were created as part of the XCRI-CAP 1.2 validator project and are included both within the Google Code repository and also within the downloadable document.

Calling the validation routines

This code is within the Run method of the “ValidateRunner” class within the XCRI.Validator.App project
Once the validation module, interpretation module and input file (along with all the objects required for the code to run) have been collated, the actual validation code is run. This is handled by the Validate method of the applicable ValidationService and will download the referenced XSD files and use them, along with the XML rulebase, to validate the file.

Outputting the results

This code is within the Output method of the “ValidateRunner” class within the XCRI.Validator.App project
Once the validation data is collated, it is output to a HTML file named “output” within the folder that the application is running in. In an automated build system it would make more sense to parse out the results for rules that passed and rules that are only recommendations and to concentrate solely on the Exceptions and applicable Warnings. These could either be printed out to screen or into a structured data file for another process to pick up and deal with.

Calling the executable

The executable takes one mandatory and two optional arguments:

“-i”
The input file (e.g. “input.xml”)
“-vm”
The Validation Module file (e.g. “xcricap12.xml”). Defaults to “xml-files\ValidationModules\XCRICAP12.xml”.
“-im”
The Interpretation Module file (e.g. “interpretation.xml”). Defaults to “xml-files\XmlExceptionInterpretation.xml”.

An example call using all three parameters may be:
XCRI.Validator.App.exe -i input.xml -vm xcricap12.xml -im interpretation.xml
Remember to quote any paths that contain spaces.