Building models that capture the desired state of  modeled systems is an important use case for SML. In addition to using the schema-based constraints supported by XML Schema, SML models can also use SML’s schema-based constraints on inter-document references and Schematron-based constraints. I am going to discuss the use of  Schematron-based constraints in this post.  

You should use Schematron-based constraints if

1.       You want to define constraints that can’t be expressed using schema-based constraints. E.g.,

a.       Your model for a Computer contains two elements: FirewallEnabled and SecurityLevel, and you want to define a constraint that specifies that  if SecurityLevel=”High” then FirewallEnabled=”true”

b.      Your model for a DataCenter has references to the Computer instances in the data center, and you want to define a constraint that specifies that FirewallEnabled=”true” for all  computers in a data center

SML supports this case by allowing Schematron constraints to be embedded in the xs:annotation/xs:appinfo child element of complex type and element definitions. 

 

2.       You want to define constraints outside of the schema documents, i.e., without creating new schema documents or modifying existing schema documents. The schema-based constraints in XML Schema and SML can only be defined in a schema documents, and these constraints apply to all instances of the type/element definition for which they are defined. To see this, consider the example where your ISV has provided you with an SML model of Computer, and you want to define constraints that represent your IT policies for computers used by  Sales, Finance, HR, Engineering etc.  These policies may change based on business and regulatory requirements, and you may want to apply multiple policies to the same computer.  Even if you were willing to create new subtypes of Computer, you’ll run into the limitations of single inheritance and the resulting type explosion. SML supports this by allowing Schematron constraints to be defined in separate Schematron documents and binding these Schematron documents to one/more documents in an SML model. Note that in this specific example, you will have to create a new SML model that adds the new Schematron documents corresponding to your IT policies and bind these documents to the Computer instance documents for Sales, Finance, HR, etc.

3.       You want to define a constraint with your own error message (possibly with insertion arguments). E.g., you want the following error message “Firewall is not enabled on Computer <name>”.  SML doesn’t do anything special for this case – you get it for free with Schematron J

The ability to define Schematron constraints outside of schema and selectively/dynamically bind them to one/more documents in a model is very powerful since it allows new constraints to be applied to one/more documents in a model without the need to create new types. It allows you to define multiple and potentially overlapping subsets of documents in your model, and apply specific constraints to each subset. I expect that this feature will be extensively used in the IT service management scenarios where IT administrators want to define target different policies to different instances of the same type.

So how do you define these dynamic bindings in your SML model? The SML specification allows implementations to choose suitable mechanisms for dynamic binding, but does not mandate the use of any specific mechanism. The SML IF specification does define a standard mechanism for the interchange of dynamic binding information in a model, and I expect that most implementations will use the SML IF mechanism (or a mechanism which maps cleanly to the SML IF mechanism).  To illustrate this mechanism, let’s assume that all Computer instances in our SML model have the following aliases (a document alias is basically a URI):

·         Computer instances in Sales – alias begins with “/Instances/Computer/Sales

·         Computer instances in Finance – alias begins with “/Instances/Computer/Finance

SML IF allows a document to have multiple aliases, so it is possible that a Computer instances may have two aliases - /Instances/Computer/Sales/commission.xml and /Instances/Computer/Finance/payout.xml

Further, let’s assume that the Schematron documents that capture the policies for Sales and Finance computers have the following aliases

·         Sales policies - alias begins with “/Schematron/Sales

·         Finance  policies - alias begins with “/Schematron/Finance

The following XML fragment (based on SML IF) shows how these policies  can be dynamically bound to computer documents

<ruleBindings>

      <!-- Bind all constraints defined in Schematron documents

           whose alias begins with /Schematron/Sales to all

           computer documents whose alias begins with

           /Instances/Computer/Sales-->

      <ruleBinding>

            <documentAlias>

              /Instances/Computer/Sales

            </documentAlias>

            <ruleAlias>

              /Schematron/Sales

            </ruleAlias>

      </ruleBinding>

      <!-- Bind all constraints defined in Schematron documents

           whose alias begins with /Schematron/Finance to all

           computer documents whose alias begins with

           /Instances/Computer/Finance-->

      <ruleBinding>

            <documentAlias>

              /Instances/Computer/Finance

            </documentAlias>

            <ruleAlias>

              /Schematron/Finance

            </ruleAlias>

      </ruleBinding>

</ruleBindings>

Once you have defined the above bindings in your SML model, you can apply the desired policies to a Computer document by assigning suitable aliases to it. The aliases can be defined when a new document is created, and the aliases can be added/removed during the life of a document. This does not require any changes to your SML model.