April 20, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

XPath Rules!

  • November 19, 2003
  • By Jeff Ryan
  • Send Email »
  • More Articles »

Introduction

XPath is a language used in XSLT and DOM programming for addressing elements and asserting expressions in XML documents. This latter capability of asserting expressions is a lesser known and used capability of the language. It's possible to use XPath as a non-proprietary rule language. We'll look to exploit this capability and demonstrate how DOM and XPath can be used to build a simple declarative rule engine.

This article will assume some level of familiarity with DOM and XPath. The conceptual model of the rule engine depicted here could be implemented using various DOM and XPath implementations. We'll build a Java implementation. Because JAXP (Java API for XML) doesn't include any native XPath APIs at this time, we'll look to open source to fill the gap. In order to run the code presented here, you'll need to have Apache Xalan[i] installed in your classpath.

The following outline is a roadmap for how we'll cover the topic:

  • First, we'll begin with a conceptual model of our rule engine
  • Then, we'll review the schemas for the various XML documents we'll be using
  • Next, we'll dive into the code for our rule processor and review it step by step
  • Then, we'll discuss pros and cons of this type of approach
  • Finally, we'll wrap up by summarizing what we've learned

Conceptual Model

Using the capabilities of DOM and XPath, our goal is to build a declarative rule engine as illustrated in the following diagram:

The model document represents an instance of the domain data that rules will be run against. Because we desire our rule processor to be generic, this document may be of any schema.

A rules document contains the rules to be asserted versus a domain model document. The rules defined must adhere precisely to the rules schema we define. The rule processor will have a dependency upon this schema.

The rule processor will assert the rules in the rules document versus the model document and output an errors document showing any rules that were violated. The errors document is also generic and can report the errors for any schema.

Development and maintenance of rules is accomplished by simply adding rules to the rules document via boolean XPath expressions. This means that the rule engine is declarative. New rules can be entered without programming.

XML Schemas

Let's review the schemas in more detail for our three XML documents and look at some sample XML streams.

Model Document

The model document may be any schema. For our purposes, we'll be using a fairly simple schema containing a collection of customer records. Each Customer element contains Name, City, and State elements.

A sample stream follows:

<Customers>
  <Customer id="C1">
    <Name>XYZ Plumbing</Name>
    <City>New Haven</City>
    <State>CT</State>
  </Customer>
  <Customer id="C2">
    <Name>Joes Bar and Grill</Name>
    <City>Waterbury</City>
    <State>CT</State>
  </Customer>
  <Customer id="C3">
    <Name>ABC Pizza</Name>
    <City>Hartford</City>
    <State>CT</State>
  </Customer>
    <Customer id="C4">
    <Name>A really long customer name goes here</Name>
    <City>Southington</City>
    <State>CT</State>
  </Customer>
  <Customer id="C5">
    <Name>xxx</Name>
    <City>xxx</City>
    <State>CT</State>
  </Customer>
</Customers>

Notice that each Customer has an id attribute uniquely identifying the customer.

Rules Document

The rules schema is also fairly simple and contains a collection of rules. Each rule has Context, ValidationAssertion, and ErrorMessage elements.

The Context node contains an XPath expression representing a node list in the model document. The ValidationAssertion contains an XPath expression that will be asserted versus the nodes in the Context node list. The ErrorMessage represents the message to be returned when a ValidationAssertion evaluates false.

In the sample document below, the first rule checks to see that a customer name is not more than 30 characters. The second rule, that a customer name is greater than 3 characters. The third rule, that the City is greater than 3 characters. Each assertion is an XPath expression that evaluates to a boolean result. Assertions that evaluate to false are considered errors or violations.

<Rules>
  <Rule>
    <Context>/Customers/Customer</Context>
    <ValidationAssertion>string-length(normalize-space(Name))
     &lt;= 30</ValidationAssertion>
    <ErrorMessage>Customer name must be less than 30
     characters</ErrorMessage>
  </Rule>
  <Rule>
    <Context>/Customers/Customer</Context>
    <ValidationAssertion>string-length(normalize-space(Name))
     &gt; 3</ValidationAssertion>
    <ErrorMessage>Customer name must be greater than 3
     characters</ErrorMessage>
  </Rule>
  <Rule>
    <Context>/Customers/Customer</Context>
    <ValidationAssertion>string-length(normalize-space(City))
     &gt; 3</ValidationAssertion>
    <ErrorMessage>City must be greater than 3
     characters</ErrorMessage>
  </Rule>
  </Rules>

The ACORD standards body for the insurance industry defines custom rules to its schema in a similar way in the service provider extensions or SPX specification[ii].

Errors Schema

The Errors Schema represents a collection of rule violations. Each Error contains a Context element representing the model document node that generated the error, and an associated Message. As you can see from the sample stream, the Context is an XPath expression indicating the specific node in the document whose rule was violated.

<Errors>
  <Error>
    <Context>/Customers/Customer[@id='C4']</Context>
    <Message>Customer name must be less than 30
     characters</Message>
  </Error>
  <Error>
    <Context>/Customers/Customer[@id='C5']</Context>
    <Message>Customer name must be greater than 3
     characters</Message>
  </Error>
  <Error>
    <Context>/Customers/Customer[@id='C5']</Context>
    <Message>City must be greater than 3 characters</Message>
  </Error>
  </Errors>




Page 1 of 2



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel