|
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. /Roger
From: Costello, Roger L. 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”. /Roger ----------------------------------------------------------------------------------------------- 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”> 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.,
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 |