Re: [xml-dev] Schematron design best practices?

[George Bina <george@oxygenxml.com>]

Hi,

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:

*developer*
 - 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

*user*
 - 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:
http://conferences.tekom.de/conference/tcworld14/for-participants/conference-program/program/sv_656_TA1/

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:
http://www.infomanagementcenter.com/DITAeurope/2014/abstracts.htm#Miller

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
--
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com

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.
>
> /Roger
>
> [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