Object models, vocabularies and parameters from an XSD

Business Rules Embedded generates a BOM from an XML schema (an XSD document). Business Rules Embedded can also use the BOM to generate a vocabulary for a locale (VOC).

You use a set of XML schemas (XSD documents) to describe the application domain model.

Example

Here is an example of an XSD:

<?xml version="1.03" encoding="ISO-8859-1"?>
<xsd:schema
	targetNamespace="http://www.company.com/rules/customer"
	xmlns="http/www.company.com/rules/customer"
	xmlns:xsd="http://www.w3.org/2001/XMLSchema"
	elementFormDefault="unqualified"
	attributeFormDefault="unqualified">
	<xsd:element name="customer" type="customer"/>
	<xsd:complexType name="customer">
		<xsd:sequence>
			<xsd:element name="name" type="xsd:string"/>
		</xsd:sequence>
	</xsd:complexType>
</xsd:schema>

Business Rules Embedded creates the BOM class com.company.rules.customer.Customer, with the property name of type string, from the XSD. The default vocabulary locale (Locale.US) for this class defines the concept customer that contains the fact type name. Business Rules Embedded automatically generates the name of the concept and the fact type from the BOM class name and property name. This generation is not specific to a locale. In a French business rule, for example, name would be used, and not the local word nom.

Note: Business Rules Embedded uses default verbalization to generate a vocabulary from a BOM. For example, if the XSD has a ComplexType called customer, Business Rules Embedded creates a type called customer in the BOM. The type is verbalized as the customer in an English VOC, and le customer in a French VOC.

Parameters

To execute a rule, the code must pass an instance of a variable as an XML document, and bind the document to a parameter.

Here is a rule based on the code sample:

if the name of customer contains "Smith"
then print "Hello John!";

The code that calls the IlrXMLRuleService instance must pass in an instance of the customer XSD as an XML document, and state that the document is bound to the parameter customer.

Parameters serve two related purposes:

They define the variables that the rules can reference and reason about.
They determine the signature of the ruleset. The signature describes the list of parameters required to execute the ruleset.
Business Rules Embedded only supports INOUT parameters: the client instantiates parameters, rules in the rule engine might modify the parameters, and the parameters return to the client.

Parameter usage analysis

Business Rules Embedded supports parameter usage analysis. The user can declare a set of parameters as available for rule authoring, but only the parameters that are actually used by the rules are declared in the ruleset signature.