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

RE: Schematron Best Practice: Embed Schematron into a Grammar-

• From: <Nicholas.Ardlie@g...>
• To: <rasmussen.bryan@g...>, <costello@m...>
• Date: Tue, 24 Jul 2007 11:37:41 +1000

In response to Bryans comment,
Some of us in the GML community (those developing domain models based on ISO
19109 - Rules for Application Schema) are following a model-driven approach
to schema encoding and grammar-validation/cross-validation.

Conceptual Models are developed in UML (using a specific subset of UML Class
diagrams) and an XML Encoding (i.e. XML schemas) is automatically generated
from an XMI representation of the UML model.
The generated schemas provide a basis for grammar validation. Embedded
Schematron rules (in some schemas) provide assertion of the UML class
constraints.
The intention if for a subset of OCL to be used to declare the UML Class
constraints (where that set of constraints can be mapped to Schematron rules
by an encoding tool). However any currently embedded Schematron rules are
hand-crafted.

Having said that, the ISO metadata community (at least in Australia and New
Zealand) are using Schematron rules in separate files from the XML schemas.
Part of the motivation for this is that the XML encoding of this application
schema is itself an ISO standard and not open to post-addition of Schematron
assertions.

So how does this apply to what's been noted in this thread so far?
The recommendation noting "maximum flexibility and long-term maintainability"
by using separate files is less applicable when the schema AND Schematron
assertions are auto-generated from the same source model.
Swapping out of the grammar would imply a rework of the Schematron generation
component anyway.
The advantages noted regarding performance and process-chain flexibility are
still applicable, but can be achieved with embedded Schematron anyway by
extracting the rules in a pipeline or other process chain.
There's a possibility we may end up with a mixture as Rick has suggested.

Cheers,
Nick Ardlie.


-----Original Message-----
From: bryan rasmussen [mailto:rasmussen.bryan@g...] 
Sent: Monday, 23 July 2007 11:01 PM
To: Costello, Roger L.
Cc: xml-dev@l...
Subject: Re:  Schematron Best Practice: Embed Schematron into a
Grammar-Based Language? Or Keep Separate?

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

_______________________________________________________________________

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