[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Schematron design best practices?

  • From: Rick Jelliffe <rjelliffe@allette.com.au>
  • To: "Costello, Roger L." <costello@mitre.org>
  • Date: Tue, 28 Oct 2014 15:14:55 +1100

Re:  Schematron design best practices?

Two ways we organise rules here
(fir two projects)

1. Project one: test hundreds of thousands conversions from one family of dtds to another family of dislike schemas. So...Have one schema for.constraints that apply for all conversions between the families: the generic elements.  Have one schema each for the specific constraints fir each input output pair: often these are.simple changes only. Categorise each assertion into sev1 sev2 etc.

2. Project two. Documents flowing through a pipeline of converters/enrichers. At each stage different failures are shiwstoppers, but we want complete results each time so 'phase' is not appropriate. So...have the role attribute with 'error' 'warning or 'caution' values. Workflow engine responds differently depending on role values.

Both projects have.multiple assertions per rule and multiple rules per pattern. Busy patterns are used so that phases can be used to quickly trim the constraints when maintaining schemas: so we can run on thousands of documents to confirm fixes or to scope out problems.

Cheers
Rick

On 07/10/2014 10:44 pm, "Costello, Roger L." <costello@mitre.org> 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.