Rules Schema
![]()
clix:rules
]]>
CLiX constraints are contained in rule files, which must start with the clix:rules
element. Any namespace prefixes bound at the clix:rules elements become available for use in
path expression in the rule file, as explained in .
Optionally, the clix:rules element can contain macros, variable and key elements:
clix:macros
]]>
Instructs the CLiX processor to include a macro file for macro processing. This mechanism is left
unspecified in this version of the spec and will be updated in a minor release.
clix:variable
]]>
clix:variable creates a global variable that all rules in a CLiX file may make use of. The
id attribute becomes the variable name and xpath is evaluated to become the variable
value. Since there is no context defined at this point, xpath must be an
absolute path, as defined in
clix:key
]]>
This creates a key for lookup using the key() function inside a path, in exactly the same
way as the
key construct. The
name attribute is a unique identifier for the key. match must be an absolute path
as defined in , and use must be a path relative to the nodes retrieved
by evaluating the absolute path.
A key defined in such a way can then be accessed using the XPath function key(name, nodeset),
which evaluates its second path parameter to a node set and gets all elements from the key for which use
evaluates to the same value.
Key example
Suppose we have the following document:
Crepes
2.50
Chocolate gateaux
3
Crepes
]]>
Then we could define a key over the dinners by dessert names using <clix:key name="dessertKey" match="//dinner" use="dessert"/>. Assuming that we have a variable fav bound to the favourites element, we could check
the price of our favourite dessert using: <clix:equal op1="key('dessertKey',$fav)/price" op2="2.50"/>
Rules file
This is a more complete example of the structure of a rule file:
Michael Marconi
A set of rule examples
This should help to demonstrate the rules element
...
...
]]>
Constraint formulas
Rules in CLiX are based on a fairly simple language that combines first order
logic with XPath: quantifiers are used to iterate over
sets of nodes, boolean operators like and and or
allow the construction of more complex formulae, and predicates like equals
and notequals compare sets of nodes to get a result.
The purpose of this section is to define an XML syntax for this formula language.
Every construct in the language makes use of XPath to retrieve elements from documents for
processing. The XPath expressions that can be used to address elements in documents are restricted
depending on the formula type. The next few sections define the permissible types of path expressions.
Namespace prefixes in paths
XPath location steps use prefixes to retrieve elements from certain namespaces. For example, given our
definition of the clix prefix above, /clix:rules/clix:rule would select all
rule elements in the namespace http://www.clixml.org/clix/1.0.
When CLiX formulas make use of namespace prefixes in their paths, those prefixes must be bound. CLiX processors
will accept all prefixes bound at the root of the rule file, clix:rules as valid prefixes for
path expressions. The following example shows how to write a rule over elements in a custom namespace,
http://www.mycompany.com/mylanguage:
Example of rule with namespaces
]]>
Absolute Paths, Quantifier Paths and Predicate Paths
The CLiX formula constructs make use of XPath to select elements from documents. Predicate elements
like clix:equal may be relative to variables only, global variables must use
absolute path expressions and quantifiers like clix:forall need path expressions that evaluate
to node sets, since they are iteration constructs. We will define these three path types below.
An absolute path starts either with a / or a //. If the path is
a union, then each path in the union must be absolute itself. For example,
/foo/bar is an absolute path and so is /foo | /bar.
Legal absolute paths
-
/foo/bar is an absolute path that selects all elements
]]> contained in ]]>.
-
/foo/@bar is an absolute path that selects the attribute
bar in all elements ]]>.
-
/foo/bar/text() is an absolute path that selects all
text nodes in ]]>.
The following examples are all illegal:
Illegal absolute paths
-
$x/foo is illegal because it is relative to a variable (x).
-
substring(/foo,1,5) is illegal because, even though the contained path
is absolute, the expression as a whole does not begin with an absolute path.
A quantifier path is either an absolute path or a path expression whose locator paths
are relative to a variable. In addition, a quantifier path must evaluate
to a node set. This is because these paths are used by clix:forall and clix:exists, which are iteration
constructs.
Legal quantifier paths
-
/foo/bar is legal because is an absolute path and selects a set of bar nodes.
-
/foo/@att is legal because is an absolute path and selects a set containing the
att attribute, or an empty set if no such attribute is present.
-
$x/foo/@bar is legal because it is relative to a variable and selects an attribute node.
The following examples are all illegal:
Illegal quantifier paths
-
foo/bar is legal because is neither absolute, nor relative to a variable. It assumes an
implied context node.
-
substring(/foo/@att,1,5) is illegal because it results in a string.
A predicate path is a path expression that may contain only location paths that are relative to
variables, or expressions that yield strings, booleans or numbers. It is called a predicate path becaues it
is the only permissible type of path in the CLiX "predicates" like clix:equal. As an example, $x/bar
is a predicate path and so is 54.
Predicate paths are always evaluated to yield a value of type string, number or boolean. If a path
evaluates to a node set, the node set is converted to a string using the conversion rules set out
in . The following are examples of legal predicate paths:
Legal predicate paths
-
54 is legal because it selects a number
-
true() is legal because it selects a boolean.
-
$x/foo/@bar is legal because it selects a nodeset that contains an attribute node.
-
substring($x/foo,5) is legal because it selects a string, and because the parameter
path is relative to a variable.
The following examples are all illegal predicate paths:
Illegal predicate paths
-
/foo/bar is illegal because it is not relative to a variable.
-
substring(/foo,5) is illegal because the path parameter is not relative to a variable.
Node set conversion
The result of evaluating a predicate path is always a string, number or boolean. Nevertheless,
paths that evaluate to node sets, for example /foo/bar or $x/@bar are legal predicate
paths. We therefore need to define conversion rules for converting node sets to strings.
A node set is converted to a string by determining the string value of each node in the set, and then
concatenating the string values into a single string. The string values for the different types of nodes are
defined as follows:
-
Elements: the string value is the concatenated value of all text node children of the element
-
Attributes: the string value is the value of the attribute.
-
Text nodes: the value is the content of the text node.
-
Comments: the value is the content of the comment, excluding the <!--
and --> escape characters.
-
Processing instructions: the value is the string content of the processing instruction following
the target, but excluding the terminating ?>
Here is an example document to illustrate these conversion rules:
Sample document for conversion rules
a
b
]]>
In this document, assuming that x is bound to the root element:
-
the value of $x/bar[1]/@id is "1",
-
the value of $x/bar/@id is "12",
-
and the value of $x/bar is "ab".
clix:forall
]]>
clix:forall is a universal quantifier that iterates over a set of nodes and returns
true if and only if its subformula evaluates to true for all assignments
to the variable.
var is the variable that the quantifier will bind nodes to. It must be a valid
XPath variable identifier. In addition, no variable with the same name must be bound
in any ancestor formula. The following example is illegal:
Illegal, duplicate variable binding
..
]]>
in defines an quantifier path that is evaluated to a set of nodes to iterate
over. The path must follow the constraint on quantifier paths defined in .
Here is an example of a constraint that says all elements price must have a
currency attribute set to EUR:
Using forall
]]>
clix:exists
]]>
clix:exists is an existential quantifier that iterates over a node set, binding a variable to each
node in turn, and returns true if and only if its subformula returns true for at least
one assignment to the variable. If clix:exists has no subformula, if returns true if and
only if the set selected using the path expression is non-empty.
var is the variable that the quantifier will bind nodes to. It must be a valid
XPath variable identifier. No duplicate bindings are allowed, as specified in .
in defines an quantifier path that is evaluated to a set of nodes to iterate
over. The path must follow the constraint on quantifier paths defined in .
The following constraint expresses that every dinner element must include a
dessert element:
Using exists
]]>
clix:not
]]>
clix:not implements logical negation not. It returns true if its subformula
returns false, otherwise it returns false.
clix:and
]]>
clix:and implements logical conjunction: it returns true if and only if both of its
subformulae are true. This behaviour is captured in the following truth-table, where f1 refers
to the first subformula and f2 to the second:
Truth table for and
| f1 |
f2 |
f1 and f2 |
| true |
true |
true |
| true |
false |
false |
| false |
true |
false |
| false |
false |
false |
The following constraint expresses that every dinner element must include a
dessert and a price:
Using and
]]>
clix:or
]]>
clix:or implements logical disjunction: it returns true if either of its
subformulae are true. Another way of looking at this is that it returns false only if both
subformulae are false. This behaviour is captured in the following truth-table, where f1 refers
to the first subformula and f2 to the second:
Truth table for or
| f1 |
f2 |
f1 or f2 |
| true |
true |
true |
| true |
false |
true |
| false |
true |
true |
| false |
false |
false |
clix:implies
]]>
clix:implies provides logical implication. "a implies b", where a and b are
the two subformulae, expresses the constraint that if a is true then b must also be
true. It does not express any notion about what happens when a is false - in this case the outcome
of the implication is always true. This is captured more precisely in the following truth table:
Truth table for implies
| f1 |
f2 |
f1 implies f2 |
| true |
true |
true |
| true |
false |
false |
| false |
true |
true |
| false |
false |
true |
clix:iff
]]>
clix:iff is a shorthand for "if and only if". It is true if both subformulae evaluate to
the same result, that is if they are either both true or both false. "a iff b" is
a common way of abbreviating the equivalent "(a implies b) and (b implies a)":
Truth table for iff
| f1 |
f2 |
f1 iff f2 |
| true |
true |
true |
| true |
false |
false |
| false |
true |
false |
| false |
false |
true |
clix:equal
]]>
clix:equal compares two values for equality and returns true if and only if the values
are equal. The two parameters are predicate paths and have to meet the constraints set out in
. If both parameters evaluate to the same types, they are compared directly, that is
strings are compared to strings using standard string comparison, numbers are compared to numbers using numeric
comparison (which disregard lexical artefacts so that for example 5.0 is equal to 5)
and booleans are similarly compared using a boolean comparison.
If either parameter evaluates to a node set, it is converted using the conversion rules specified
in and treated like a string. The following casting rules are then
applied as normal.
If the two parameters do not evaluate to the same type, casting rules are applied to convert the
type of lower priority into the type of the other parameter. The order of the parameters is insignificant,
type priority is the overriding concern. Thus, Type 1 and Type 2 in the following table
do not refer to the types of the first and second parameter, but are simply a way of referring to a pair of
types. The
Base Type | is the type that the lower priority type is converted into:
Type conversion rules
| Type 1 |
Type 2 |
Base Type |
| Boolean |
Number |
Boolean |
| Boolean |
String |
String |
| String |
Number |
String |
There are thus three type conversions that may take place and their implementation proceeds as follows:
-
Number to Boolean: A non-zero number except NaN is converted to
true. 0 and NaN are converted to false.
-
Boolean to String:
true is converted to "true" and
false is converted to "false".
-
Number to String: Numbers with zero remainders are converted by taking the string
representation of the integer part of the number on a decimal base, preceded by a minus sign if the
number is negative. Thus 5 is converted to "5". Numbers with non-zero remainders
are represented as decimal numbers with a period representing the decimal point, with at least one digit
in the integer part, and as many digits in the fractional part as are required to distinguish the number from
all other IEEE754 values. Thus 5.23400 is converted to "5.234". Finally,
NaN is converted to "NaN".
As a result of these conversions, care must be taken when comparing numbers to strings. For example,
<clix:equal op1="5" op2="'5.0'"/> returns false because the number
5 would be converted into the string "5", which is not equal to
"5.0". In general, it would be best to compare numbers to numbers directly, or to make use
of the XPath number function where this is not possible.
Using equal
Assume the following example document, and that the variable x has been bound to
bar1 and y has been bound to bar2:
A value
5.0
]]>
Then equal would behave as follows:
-
<clix:equal op1="$x" op2="'A value'"/> is true
-
<clix:equal op1="$y" op2="5"/> is false
-
<clix:equal op1="number($y)" op2="5"/> is true
clix:notEqual
]]>
clix:notequal compares two values for equality and returns true if and only if
the values are not equal. The two parameters are predicate paths and have to meet the
constraints set out in . Differing parameter types are cast to a base using the
rules specified for .
The behaviour of clix:notequal is such that the following
two formulae are equivalent:
]]>
clix:same
]]>
clix:same is the only predicate in CLiX that does not take two XPaths as a parameter.
Instead, it takes two variable references of the form $varname and checks if
exactly the same nodes are bound to the two variables.
This is different from clix:equal, because the two parameters are not compared by
value. Take the following document as an example:
A value
A value
]]>
If you assume that x is bound to bar1 and y is bound
to bar2, then:
-
<clix:same op1="$x" op2="$y"/> is false because x
does not point to the same node as y.
-
<clix:equal op1="$x" op2="$y"/> is true, because the two nodes
contain the same value
-
<clix:same op1="$x" op2="$x"/> is true
Same is useful for certain types of constraints like complex uniqueness constraints. We can
express that all elements foo are unique if compared by @id as follows:
Using same
]]>
clix:less
]]>
clix:less compares its two parameters and returns true if the first parameter is either
lexicographically or numerically strictly less than the second, in the case of strings and numbers, or if it is
not equal to the second, in the case of booleans. The two parameters are predicate paths and
have to meet the constraints set out in . Before comparison, different types
of parameters are cast to a common base as specified for
Using less
Assume the following example document, and that the variable x has been bound to
bar1 and y has been bound to bar2:
A value
5.0
]]>
Then clix:less would be evaluated as follows:
-
<clix:less op1="$x" op2="'No value'"/> is true
-
<clix:less op1="number($y)" op2="6"/> is true
-
<clix:less op1="number($y)" op2="5"/> is false - the value
needs to be strictly less.
-
<clix:less op1="true()" op2="false()"/> is true
clix:lessOrEqual
]]>
clix:lessOrEqual is a combination of clix:less and clix:equal.
The two parameters are predicate paths and have to meet the constraints set out
in . The following two formulae are equivalent:
]]>
clix:greater
]]>
clix:greater compares its two parameters and returns true if the first parameter is either
lexicographically or numerically strictly greater than the second, in the case of strings and numbers, or if it is
not equal to the second, in the case of booleans. The two parameters are predicate paths and
have to meet the constraints set out in . Before comparison, different types
of parameters are cast to a common base as specified for
With the exception of booleans, for which both clix:greater and clix:less return
true if and only if the two parameters evaluate to the same boolean value, the following two formulae
are equivalent:
]]>
Using greater
Assume the following example document, and that the variable x has been bound to
bar1 and y has been bound to bar2:
A value
5.0
]]>
Then clix:greater would be evaluated as follows:
-
<clix:greater op1="$x" op2="'No value'"/> is false
-
<clix:greater op1="number($y)" op2="5"/> is false - the value
needs to be strictly greater.
-
<clix:greater op1="true()" op2="false()"/> is true
clix:greaterOrEqual
]]>
clix:greaterOrEqual is a combination of clix:greater and clix:equal.
The two parameters are predicate paths and have to meet the constraints set out
in . The following two formulae are equivalent:
]]>
Extension Mechanisms
CLiX provides two extension mechanisms for the constraint language, plugin operators and
macros. Plugin operators are scripted predicates that can take a number of parameters and
return true or false. They can be used to perform a variety of tasks like database lookups,
communication with legacy systems or extensive computation.
Macros are parameterised CLiX formulas that are kept in a macro definition file. They can be
invoked in a rule to automatically expand the rule. This makes it possible to reuse frequently
used constraint types. Macros are not further defined in this version of the spec but will be
added in a minor release.
clix:operator
]]>
clix:operator can be used wherever any other predicate like clix:equal or
clix:notEqual can be used. Like these predicates, it takes a number of parameters and
returns true of false. The difference is that the operator can take any number of parameters, and its
computation is outside the scope of this specification.
It is assume that a CLiX execution engine will make operators available for use in a formula. The way
this is done is language specific and thus this specification does not constrain it further. The only
requirement imposed here is that the name attribute of the operator must point to some
implementation construct with the same name, and implementors should clearly specify how this relationship
is established.
An operator can take a number of clix:param elements, which are defined as follows:
]]>
Every parameter has a name and a value. The name must bind to a parameter that the
externally specified implementation expects. For example, in an ECMAScript implementation, this will reference
a parameter passed to the function implementing the operator. The value must contain a
predicate path, as specified in . Implementing CLiX processors will evaluate this
predicate path and pass its value on as a string, number or boolean to the operator implementation.
Using operator
Suppose we want to check that some element in a document is a prime number, and we provide an operator
implementation that can execute this check. We would make this operator available in some programming
language and then invoke it as follows:
]]>
macro:*
This formula construct is used for macro invocation. This mechanism will be defined in a minor version
upgrade of this specification.