OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
ANN: 10 Laws of Schematron Design

Hi Folks,

I think the below “10 Laws of Schematron Design” are good. I distilled them from examination of this [1]. I welcome your additions to these “Laws”.



1. Assign each business rule a unique identifier. For example, assign this rule:

               Each Book must contain Title, Author, Date, ISBN, and Publisher

the ID: Books-ID-00015.

2. In each file place just one pattern element (i.e., the file doesn’t have the schema element).

3. Give each pattern a unique identifier, e.g., <sch:pattern id=”Books-ID-00015”

4. In each pattern element place one rule element and in the rule element place one assert element. Give the assert element the same ID as the pattern element, e.g., <sch:assert id=”Books-ID-00015”

5. In the body of the assert element is a natural language description of rule. Start that description with the ID within brackets followed by [ERROR] followed by the natural language description, e.g.,

                <sch:assert test=”…” id=”Books-ID-00015”>
                     [Books-ID-0015][ERROR] Each Book must contain Title, Author,
                      Date, ISBN, and Publisher information.

6. Give the filename the same name as the ID, e.g. Books-ID-00015.sch

7. Identifiers are all of the format Book-ID-XXXXX, with rule files named Books_ID_XXXXX.sch.

Rationale for design guidelines 1-7: By following the guidelines there is complete traceability. Each business rule can be traced to exactly one Schematron implementation. Conversely, each Schematron implementation can be traced to exactly one business rule. Also, it is easy to change an implementation of a rule: simply replace the file containing the rule with another file that implements the same rule.

8. Create a Book Schematron Guide which describes every file, e.g.,


2.1 - Rules/Books/Books_ID_00015.sch


Rule Description: Books-ID-00015 Each Book must contain Title, Author, Date, ISBN, and Publisher information.


Code Description: If the context item is a Book, then …


Schematron Code: -- show the Schematron code here –


9. Create a top-level Schematron file. This file has no patterns or rules. It has the schema root element. It has all namespace declarations. It includes all of the other files. It defines any variables that will be needed in any of the files. It defines any (XSLT) functions that will be needed in any of the files. Validate instance documents against this file; the instance document will be validated against all the rules defined in all the files.


Rationale for design guideline 9: No need to perform multiple Schematron validations; simply validate instances against this top-level Schematron file. There is a single, central place where namespaces and variables and functions are defined, so it is easy to adjust them, when needed.


10. Identify common information patterns in the business rules; define the pattern once (use Schematron abstract patterns and abstract rules); reuse the pattern wherever possible. Place the files that contain abstract patterns/rules in a “Lib” folder. Place the files that contain concrete (non-abstract) patterns/rules in a “Rules” folder and within there create subfolders, e.g., Books, Magazines, Articles.

[1] http://www.dni.gov/files/documents/CIO/ICEA/Foxtrot/ISM_V10.zip

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS