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]
RE: ANN: 10 Laws of Schematron Design

Hi Folks,

Rick Jelliffe provided good reasons for why the below design approach is not good.

I just found another reason: performance is terrible with the approach!

Using the approach described below I implemented a bunch of Schematron rules and evaluated the rules on an XML document that has over 110,000 items. The execution time was: 100 seconds.

The approach described below results in creating lots of Schematron <sch:rule> elements, each containing only one <sch:assert>. Well, lots of <sch:rule> elements makes for terrible performance. So, I consolidated the <sch:rule> elements into just three, each containing a bunch of <sch:assert> elements. The execution time dropped to 5 seconds! Wow! That is a huge difference.

Bottom line: when designing Schematron, use few <sch:rule> elements.



From: Costello, Roger L.
Sent: Wednesday, October 08, 2014 2:04 PM
To: xml-dev@lists.xml.org
Subject: 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