JSchematron

This page is under construction. For more information please see the project page. If you'd like to contact me directly via email, my sf.net user is csscott (at) sourceforge.net.

JSchematron is a thin Java wrapper around the offical reference implementations of the schematron validation lanuage. As such it's validation behavior should be exactly the same as the reference implementations.

In the coming weeks, I will finish and publish the first public release 0.1

The 0.1 distribution will include the following features:

• Bundling of the java library along with reference implementations to make installation a one file jar to deploy
• There will be no need to extract configuration or the reference implementions. The library will refer to these inside the jar file. Thus there is no installation, only deploying the jar file to you classpath for use in your program.
• The will be a simple commandline program to drive the two main features.
• A resource zip that includes the supporting libraries (apache commons.*,saxon, and junit), baring any redistribution clauses (though I don't forsee any)
• A revamped project webpage will simple code examples.

The feature set of 0.1 will include:

• A one step transformation that returns the results from the various reference implementation outputs. This is most notable for the ability to generate the iso SVRL xml.
• A drop-in validation engine that will be as close as possible to what is currently supported in java (i.e. similar validation code and results to W3C XML Schema)

The feature set of 0.2 will include:

• The ability to validate against schematron that is embedded in W3C XML Schema
• The aforementioned ability with relaxng
• The ability to perform validation against the schematron document

FAQ

• Why? Because using Schematron shouldn't involve figuring out the two-stage transformations and handling the various reference implementation XSLs. It should be as simple as possible, as resemble, as much as possible, how documents are validated with W3C XML Schema.
• Why not use another implementation? Because other implementaions are either: not java, defunct, or not based on the reference implementations
• Why JSchematron for the name? Good question. I couldn't think of a good one other than the tired old j* naming convention. I'm open to suggestions though.
• When will you release 0.1? When it's ready ;). Also, the number of rainy weekends is directly proportional of the speed of development.

Since all of the core logic is already developed in the reference implementations, this implementation shouldn't take terribly long (on the order of months) to produce a production level wrapper to that functionality

Downloads will be available from the project page.

Thanks to SourceForge.net for hosting this project