Git Product home page Git Product logo

schematron-test's Introduction

This repository was archived and made read-only on 1 October 2020.

At that time, new applications of Schematron were advised to use the SchXslt Schematron implementation at https://github.com/schxslt/schxslt. The list of currently known Schematron implementations is maintained in the 'Awesome Schematron' repository at https://github.com/Schematron/awesome-schematron#software.

schematron Release

This is the most recent version of the "skeleton" XSLT implementation of ISO Schematron by Rick Jelliffe and many others. Notable early contributions were made by Oliver Becker and his students.

It is a library of XSLT scripts suitable for embedding in applications or servers, or running from command shells. There is a version for XSLT1 and one for XSLT2. There is an XSLT API to allow easy integration, but most popular is to use the generated output XML documents which use the flat SVRL (Schematron Validation Reporting Language) defined as part of ISO Schematron.

This Open Source software was first released in 2000, and has had various homes since them: xml.ascc.net (Academia Sinica, Taiwan), Schematron.com (Rick Jelliffe's information site, courtesy Allette Systems), GoogleCode and now GitHub. There are several other minor forks of Schematron on the web: as at January 2017, this site is Rick's "official" distribution site for the code.

Status: The code has tracked the various versions of Schematron from version 1.1 to ISO Schematron 2006 and draft ISO Schematron 2nd edition (now ISO Schematron 2016). The scripts are currently being checked against the released ISO Schematron 2016 International Standard to confirm conformance, and to merge various bug fixes and enhancements that have been requested over the last decade.

Bugs and Limitations

As of October 2020 this implementation is not conformant to the ISO specification with regards to the following requirements:

  • The language tag of a diagnostic is not copied to the SVRL output.
  • Property references are not copied to the SVRL output.
  • The xsl:copy-of instruction is not executed inside a sch:property element.
  • The sch:name element with a @path attribute does not expand into the value of evaluating the expression in @path.
  • An xsl:key element cannot contain a sequence constructor.
  • A variable defined for a phase is not scoped to this phase, but has global scope.
  • A variable defined for a patter is not scoped to this pattern, but has global scope.
  • The rule context cannot be a comment node.
  • The rule context cannot be a processing instruction node.
  • A subordinate document expressions cannot contain a variable.
  • A rule can extend an abstract rule that is defined in a different pattern.

schematron-test's People

Contributors

dmj avatar rjelliffe avatar tgraham-antenna avatar

Stargazers

 avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

schematron-test's Issues

How to name/structure tests of ISO testable statements?

If the goal is (as I think it should be) to (also) have minimal Schematron files to exercise the testable statements in the ISO standard, how should the tests be named/test directories be structured?

Naming tests after clause number -- e.g., 5.15.11-1.sch, 5.5.11-2.sch -- is potentially fragile since clause numbers have changed between ISO versions (as @AndrewSales points out). It's also opaque. (Who, other than @AndrewSales, knows that Clause 5.5.11 is the role attribute?)

Should the tests be named after what they test? E.g., role-1.sch, role-2.sch?

A future ISO version could invalidate an existing test (once such tests exist). However, putting 2016 in every test name as it's written seems like just adding noise.

I suggest:

  • Put all tests in an iso-schematron directory.
  • Name tests after what they test, e.g., role-01.sch
  • Use two digits when numbering tests so that they sort well on operating systems that don't pretend to be able to recognise files with a numeric sequence. (Can we realistically ever expect more than 99 tests for a single concept?)
  • If/when a new ISO version invalidates an existing test, make iso-schematron-2016 and, say, iso-schematron-2018 directories then move the existing test to iso-schematron-2016 and make a new test in iso-schematron-2018. That way, an implementation can say that it passes all of the common and version-specific tests rather than never being able to pass 100% of tests if they are all lumped together.
  • Maybe the structure should go straight to iso-schematron/common, iso-schematron/2011, and iso-schematron/2016 directories instead?
  • Test names should be unique across all test directories so there's no problems with test frameworks that flatten directories. E.g., if role-01.sch is moved to iso-schematron-2016 (or similar), the 2018(?)-specific test would be named role-02.sch rather than making another role-01.sch test.

Comments welcome but, realistically, the first person making an organised effort at producing tests is going to have the biggest effect on the test naming convention.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.