In this post, I am going to use a very simple example to illustrate how SML can be used to capture desired configuration in an IT environment. Suppose that Alice - an IT administrator - wants to secure the deployment of payroll application in her datacenter. Alice determines that the best way to secure the deployment is to require that the firewall must be enabled on the machines on which the payroll application is deployed. She now wants to define this policy/rule in SML  so that she can use the SML-based management tool from her favorite vendor to verify compliance.

Let’s assume that the operating system vendor has already defined the following types  for operating system and application (Alice could define these, but we don’t want her to do too much work in this example).  We’ll also assume that all types in this example are defined in a single XML namespace – represented by the alias ex – and use the alias sml for the SML namespace and the alias sch for the Schematron namespace.

 <xs:complexType name="OperatingSystemType">


      <xs:element name="Name" type="xs:string"/>

      <xs:element name="FirewallEnabled" type="xs:boolean"/>




  <xs:complexType name="ApplicationType">


      <xs:element name="Vendor" type="xs:string"/>

      <xs:element name="Version" type="xs:string"/>

      <xs:element ref="ex:HostOSRef"/>




The ex:HostOSRef element represents the hosting relationship between an application and an operating system and is defined as follows:


  <xs:element name="HostOSRef" type="sml:refType"



Note that the above definition uses the sml:targetType constraint to require that the type of the element targeted by an instance of ex:HostOSRef must be ex:OperatingSystemType.

Now Alice can use the above definitions to define a global element that represents the payroll application deployments in her data center and embed a Schematron constraint that requires the firewall to be enabled on the host operating system. 

  <xs:element name="SecurePayrollApplication" type="ex:ApplicationType">




          <sch:ns prefix="smlfn"


          <sch:pattern id="Firewall">

            <sch:rule context=".">

              <sch:assert test=


                Firewall is not enabled on the host operating system









By embedding the Schematron constraint in the definition of the SecurePayrollApplication, Alice has ensured that the constraint will be evaluated for all instances of SecurePayrollApplication, and the embedded error message will be generated when the test expression evaluates to false. Suppose that P is an element instance of SecurePayrollApplication and O is its host operating system instance. Then the assert expression gets evaluated for P as follows:

smlfn:deref(HostOSRef) – results in O

/ex:FirewallEnabled=’true’ is evaluated in the context of O