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:
> subscribe:
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
