Overview
Drools provides xsd files for schema validation of drls. These xsd files are used in Drools to validate drls at load time by a JAXP1.2 or later compliant api - JDK1.4 is not JAXP1.2 compliant and schema validation will be turned off, this will not affect Drools' ability work with drls in anyway, schema validations are purely text based warnings. The xsd files can also be used with other XML, schema aware, editors such as XML Spy. The relevant .xsd files are in the META-INF directory for each module jar, and can also be picked up online via fisheye:
How to specify Schema Locations
xs:schemaLocation is used to make Xerces aware of xsds:
xs:schemaLocation="http://drools.org/rules rules.xsd
http://drools.org/semantics/python python.xsd"
Drools overrides resolveEntity to allow a schemaLocation to be resolved in four ways. Bear in mind that relative urls, as above, are returned as an absolute url resolved to the same directory (or location within a jar) as the drl:
1. try given url string as provided
Take the text after the last "/" or "\" and try following locations:
2. META-INF/
3. Root of classpath
4. Current working directory
If a schemaLocation is not given then the following error will be given:
(file://xxx.drl: 11, 108): cvc-elt.1: Cannot find the declaration of element 'rule-set'.
If one of the schemas specified in the attribute cannot be resolved an error also be given for unresolved entities.
How it Works
Validation is performed during the loading of a Rule Set from a drl via Xerces and the given Schema xsds; the output from the validations are text-based warnings and will never interrupt the program execution. It is possible to disable this validation by setting the system property "drools.schema.validating" to false. Four schemas currently exist in the drools project:
drools-base/src/conf/META-INF/rule.xsd drools-java/src/conf/META-INF/java.xsd drools-groovy/src/conf/META-INF/groovy.xsd drools-python/src/conf/META-INF/python.xsd
rule.xsd is the base schema and cannot be used by itself. This schema enforces the structure of the drl and uses abstract elements and root types for imports, object types, extractors, conditions and consequences.
The abstract elements are then implemented, via substitution, by the various semantic implementations to enforce type and integrity for that semantic namespace. This provides extensibility for specific problem domain langauges. rule.xsd defines the following abstract elements:
<xs:element name="abstractImport" type="xs:anyType" abstract="true"/> <xs:element name="abstractClass" type="xs:anyType" abstract="true"/> <xs:element name="abstractClassField" type="xs:anyType" abstract="true"/> <xs:element name="abstractCondition" type="xs:anyType" abstract="true"/> <xs:element name="abstractConsequence" type="xs:anyType" abstract="true"/>
The follow code shows an example of how a semantic implementation, for a condition, can then enforce its restraints on this element. In this example we specify an element of type xs:string and no attributes:
<xs:element name="condition" type="xs:string" substitutionGroup="rules:abstractCondition"/>
