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: [xml-dev] Schematron design best practices?


This is very interesting information Roger!

I presented on Schematron at a number of conferences lately and I will do it again soon at TCWorld/Tekom and DITA Europe. What I found really useful for our users is the use of abstract patterns to create a library of generic rules and write the actual rules only as instantiations of those abstract patterns. This basically splits the use of Schematron into different roles that enable Schematron adoption within a large organization:

- creates the library of generic rules implemented as abstract patterns and updates it as needed
- requires Schemtron/XPath knowledge

*information architect*
- instantiates generic rules (Schematron abstract patterns) just by naming the rule and providing values for the rule parameters
- no Schematron knowledge is needed, just a minimal training to specify the rule name and its parameters
- if a new rule type is needed he asks the developer to create a new generic rule/abstract pattern and uses that to add new rules of that type

- will benefit of running all the Schematron checks that will guide him to create correct/better XML content
- no need to know anything about Schematron

I will cover this as well as many Schematron use cases in my TCWorld/Tekom session:

A step further from this is that if you look at the instantiation of generic rules there is very little information that needs to be encoded there, only a name and a set of parameter/value pairs. We can encode this information within the style guide/information model, and have the Schematron generated from that, thus single sourcing the style guide/information model prose and the automatic rules that enforce it. I will present this at DITA Europe together with Frank Miller from Comtech Services:

In this case the trace from an error message to the rule can be achieved though generated @see attributes that can point back to the style guide/information model topic that generated that error message, so no special naming convention is needed or encoding pattern codes into the error messages.

Best Regards,
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger

On 07/10/14 14:44, Costello, Roger L. wrote:
Hi Folks,

Do you have lots of Schematron rules? If yes, how do you organize them?

I have been reviewing one community's approach to organizing lots of Schematron rules [1]. This community does the following:

a. Within each file have one pattern and in the pattern place one rule and within the rule place one assert.

b. Uniquely identify each pattern, e.g., <sch:pattern id="Books-ID-00015"

c. Give the assert element the same ID as the pattern element, e.g., <sch:assert id="Books-ID-0015"

d. Give the filename the same name as the ID, e.g. Books-ID-0015.sch

What is the rationale for organizing rules in this manner? Why uniquely identify each pattern and each assert? Why limit each file to one pattern, containing one rule, containing one assert?

I am not questioning that these are good design practices, I just want to understand their rationale.


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


XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[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