Re: [xml-dev] Schematron Best Practice: Embed Schematron into a Grammar-

["bryan rasmussen" <rasmussen.bryan@gmail.com>]

hmm, just a note:

Usually the scenario for pipelines is

1. Grammar Validation (prob. XML Schema)
2. Other validation (prob Schematron)

However dependent on the way Schemas are designed, the schematron
implementation used, and other relations, someone wanting to wring the
most performance out of a pipeline might want to put some schematron
validation first.

In discussing the advantages/disadvantages you might like to talk to
somebody in the GML community, since they chose the intertwined way
IIRC.




Cheers,
Bryan Rasmussen

On 7/23/07, Costello, Roger L. <costello@mitre.org> wrote:
> Hi Folks,
>
> I would like to begin the next Schematron Best Practice issue.  Below
> is the issue.  I have made a start on addressing the issue, including a
> preliminary recommendation.  I invite you to add to the list of
> advantages and disadvantages, and to enhance/modify the recommendation.
> /Roger
>
>
> ISSUE
>
> You have a set of data validation requirements for your system.  You
> have decided to implement the requirements using a combination of a
> grammar-based language (e.g. Relax NG or XML Schema) plus Schematron.
> Should the Schematron implementation be embedded within the grammar
> document, or should the Schematron implementation be in a separate
> document from the grammar document?
>
>
> EXAMPLE
>
> Suppose this XML instance document is representative of the type of
> data that your system exchanges:
>
>         <?xml version="1.0"?>
>         <Document classification="secret">
>               <Para classification="unclassified">
>                    One if by land; two if by sea.
>               </Para>
>         </Document>
>
>
> And suppose your system's data requirements are:
>
> 1. The <Para> classification value cannot be more sensitive than the
> <Document> classification value (top-secret is more sensitive than
> secret, which is more sensitive than confidential, which is more
> sensitive than unclassified).
>
> 2. The <Document> element must have a classification attribute, whose
> value is either top-secret, secret, confidential, or unclassified.
>
> 3. The <Para> element must have a classification attribute, whose value
> is either top-secret, secret, confidential, or unclassified.
>
> The first requirement will be implemented using Schematron.  The next
> two requirements will be implemented using XML Schemas.
>
> There are two alternatives:
>
> A. Create two documents: one document for the Schematron
> implementation, and a second document for the XML Schema
> implementation.
>
> B. Create one document: the Schematron patterns, rules, and assertions
> are embedded within <appinfo> elements in the XML Schema.
>
>
> ADVANTAGES/DISADVANTAGES OF SEPARATE SCHEMATRON AND GRAMMAR DOCUMENTS
>
> ADVANTAGES
>
> 1. The particular grammar language currently being used can be easily
> replaced.  Thus, if XML Schema is currently being used, at a later date
> you can easily replace it with Relax NG without impacting the
> Schematron schema.
>
> 2. Constraint checking can be done in stages, in a pipeline fashion.
> It might be desirable for your system to implement constraint checks in
> phases - first do grammar checking, then do something, then do
> co-constraint checking (using Schematron) then do something, then do
> data cardinality checking (using Schematron), then do something, then
> do algorithmic checking (using Schematron).
>
> 3. There may be a performance improvement. Suppose grammar checking is
> done first and suppose it fails (i.e. outputs errors) then it may not
> be necessary to execute the Schematron validation; thus there is a time
> savings.
>
> DISADVANTAGES
>
> 1. There may be a performance degradation.  Running several validations
> rather than a single validation may be more expensive.
>
>
> ADVANTAGES/DISADVANTAGES OF SCHEMATRON EMBEDDED WITHIN A GRAMMAR
> DOCUMENT
>
> ADVANTAGES
>
> 1. There may be a performance improvement.  Running one validation
> rather than several validations may yield a savings in performance.
>
> DISADVANTAGES
>
> 1. Swapping out the particular grammar language that is currently being
> used and replacing it with a different grammar language may be
> difficult since the two are tightly intertwined.
>
> 2. Constraint checking is a big-bang event.  All constraints --
> grammar, co-constraints, cardinality, algorithmic -- are checked at
> once.
>
> 3. There may be a performance degradation. It is not possible to take
> advantage of omitting Schematron validation when grammar validation
> fails.
>
>
> RECOMMENDATION
>
> For maximum flexibility and long-term maintainability, keep the
> Schematron schema separate from the grammar schema.
>
> _______________________________________________________________________
>
> 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
>
>