CLiX Language Specification Version 1.0

5.4.1 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:

<clix:rules xmlns:clix="http://www.clixml.org/clix/1.0"
  xmlns:mine="http://www.mycompany.com/mylanguage">

  <clix:rule id="rule-1">
    <clix:forall var="x" in="//mine:elements">
      <clix:equal op1="$x/mine:value" op2="'15'"/>
    </clix:forall>
  </clix:rule>

</clix:rules>

5.4.2 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.

The following examples are all illegal:

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.

The following examples are all illegal:

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 5.4.3 Node set conversion. The following are examples of legal predicate paths:

The following examples are all illegal predicate paths:

5.4.3 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:

<foo>
    <bar id="1">a</bar>
    <bar id="2">b</bar>
</foo>

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".

5.4.4 clix:forall

<clix:forall
  var = cdata
  in = quantifierpath>
  <!-- Content: formula -->
</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:

<clix:forall var="x" in="/spec">
  <clix:forall var="x" in="//p">
    ..
  </clix:forall>
</clix:forall>

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 5.4.2 Absolute Paths, Quantifier Paths and Predicate Paths.

Here is an example of a constraint that says all elements price must have a currency attribute set to EUR:

<clix:forall var="price" in="/items/item/price">
  <clix:equal op1="$price/@currency" op2="'EUR'"/>
</clix:forall>

5.4.5 clix:exists

<clix:exists
  var = cdata
  in = quantifierpath>
  <!-- Content: formula? -->
</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 5.4.4 clix:forall.

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 5.4.2 Absolute Paths, Quantifier Paths and Predicate Paths.

The following constraint expresses that every dinner element must include a dessert element:

<clix:forall var="dinner" in="/restaurant/dinner">
  <clix:exists var="d" in="$dinner/dessert"/>
</clix:forall>

5.4.6 clix:not

<clix:not>
  <!-- Content: formula -->
</clix:not>

clix:not implements logical negation not. It returns true if its subformula returns false, otherwise it returns false.

5.4.7 clix:and

<clix:and>
  <!-- Content: (formula,formula) -->
</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

5.4.8 clix:or

<clix:or>
  <!-- Content: (formula,formula) -->
</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

5.4.9 clix:implies

<clix:implies>
  <!-- Content: (formula,formula) -->
</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

5.4.10 clix:iff

<clix:iff>
  <!-- Content: (formula,formula) -->
</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

5.4.11 clix:equal

<clix:equal
  op1 = predicatepath
  op2 = predicatepath/>

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 5.4.2 Absolute Paths, Quantifier Paths and Predicate Paths. 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 5.4.3 Node set conversion 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.

<foo>
	<bar1>A value</bar1>
	<bar2>5.0</bar2>
</foo>

5.4.12 clix:notEqual

<clix:notequal
  op1 = predicatepath
  op2 = predicatepath/>

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 5.4.2 Absolute Paths, Quantifier Paths and Predicate Paths. Differing parameter types are cast to a base using the rules specified for 5.4.11 clix:equal.

The behaviour of clix:notequal is such that the following two formulae are equivalent:

<clix:notequal op1="$x/bar" op2="$y/bar"/>

<clix:not>
  <clix:equal op1="$x/bar" op2="$y/bar"/>
</clix:not>

5.4.13 clix:same

<clix:same
  op1 = varref
  op2 = varref />

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:

<foo>
	<bar1>A value</bar1>
	<bar2>A value</bar2>
</foo>

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:

<clix:forall var="x" in="/foo">
  <clix:forall var="y" in="/foo">
    <clix:implies>
      <clix:equal op1="$x/@id" op2="$y/@id"/>
      <clix:same op1="$x" op2="$y"/>
    </clix:implies>
  </clix:forall>
</clix:forall>

5.4.14 clix:less

<clix:less
  op1 = predicatepath
  op2 = predicatepath/>

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 5.4.2 Absolute Paths, Quantifier Paths and Predicate Paths. Before comparison, different types of parameters are cast to a common base as specified for 5.4.11 clix:equal

<foo>
	<bar1>A value</bar1>
	<bar2>5.0</bar2>
</foo>

5.4.15 clix:lessOrEqual

<clix:lessOrEqual
  op1 = predicatepath
  op2 = predicatepath/>

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 5.4.2 Absolute Paths, Quantifier Paths and Predicate Paths. The following two formulae are equivalent:

<clix:lessOrEqual op1="$x" op="$y"/>

<clix:or>
  <clix:less op1="$x" op="$y"/>
  <clix:equal op1="$x" op="$y"/>  
</clix:or>

5.4.16 clix:greater

<clix:greater
  op1 = predicatepath
  op2 = predicatepath/>

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 5.4.2 Absolute Paths, Quantifier Paths and Predicate Paths. Before comparison, different types of parameters are cast to a common base as specified for 5.4.11 clix:equal

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:

<clix:greater op1="$x" op="$y"/>

<clix:less op1="$y" op="$x"/>

<foo>
	<bar1>A value</bar1>
	<bar2>5.0</bar2>
</foo>

5.4.17 clix:greaterOrEqual

<clix:greaterOrEqual
  op1 = predicatepath
  op2 = predicatepath/>

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 5.4.2 Absolute Paths, Quantifier Paths and Predicate Paths. The following two formulae are equivalent:

<clix:greaterOrEqual op1="$x" op="$y"/>

<clix:or>
  <clix:greater op1="$x" op="$y"/>
  <clix:equal op1="$x" op="$y"/>  
</clix:or>

5.5.1 clix:operator

<clix:operator
  name = cdata>
  <!-- Content: clix:param* --> 
</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:

<clix:param
  name = cdata
  value = predicatepath/>

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 5.4.2 Absolute Paths, Quantifier Paths and Predicate Paths. Implementing CLiX processors will evaluate this predicate path and pass its value on as a string, number or boolean to the operator implementation.

<clix:forall var="n" in="/mylist/number">
  <clix:operator name="isPrime">
    <clix:param name="num" value="number($n)"/>
  </clix:operator>
</clix:forall>

5.5.2 macro:*

This formula construct is used for macro invocation. This mechanism will be defined in a minor version upgrade of this specification.