This section explains SQL92 syntax predicates and the subset of XPath supported by FioranoMQ CBR. In addition, it explains the type of XMLs that are supported, along with suitable examples of the XMLs and message selectors.

General Form

Message selection criterion is registered by consumers using the FioranoMQ Content-based Message Selector (CbMS) language, which is a subset of the SQL92 conditional expression syntax. It is combined with XPath like notation for retrieving identifiers and values from XML documents.

The order of evaluation of a CbMS takes place from left to right incorporating within it levels of precedence. Parentheses can be used to change this order. Predefined selector literals and operator names are written in uppercase though they are case insensitive.

XPath notation is used as a reference mechanism to return one or many elements from an XML file. The entire XPath specification is sometimes inaccurate for content-based message selection, particularly where speed and scalability is essential. XPath notation must return only a single value, else an exception is launched.

The general form of CbMS is:

Where:

"[/ /] One or many.
"{} Optional.
"{|} Optional, and if used then select one C Identifier: For details refer to the section on
‘Identifiers’.
"q Operator. For details refers to the section on ‘Operators’.
"y Literal. For details refer to the section on ‘Literals’.

Examples:

Below are a few examples of the FioranoMQ content-based message selector language:

Subset of Supported XPath Queries

The current limitations of CbMS XPath as compared to the full XPath specifications are:

1. Only absolute paths are allowed.
   This indicates that all the XPath strings must start with '/'. '//' is not supported for relative paths. All the paths must be specified from the root of the XML. For example, the following XPath query is invalid:
   "//person" 
   If a person is found under parent researchers, then the correct XPath query would be:
   ["/researchers/person"
    
2. A test node can have only one predicate.
   This indicates that the query below is invalid, even though it can be valid in XPath:
   "//researchers/person[@name = "Shin"][@loc = "Bethesda"]"
   The query below is acceptable:
   "/researchers/person[@name = "Shin"] and /researchers/person[@loc = "Bethesda"]"
 
3. A predicate cannot appear inside another predicate.
   This indicates that the query below is invalid since it has a predicate nested inside another predicate.
   "/researchers/person[@name = /salesperson/person/name[@id > "8080"]])"
 
4. The character '|' and the expressions 'and' and 'or' are not supported inside a predicate.
   This implies that the operator "|" (Union operator) is not allowed for connecting path expressions outside predicates. Connecting path expressions outside predicates is accomplished through the use of the 'OR' keyword. Inside predicates, "|", "and" and "or" operators are not allowed. Therefore, the following query is invalid:
   "/a[@id="1" or in("2","3")]"
   The above invalid query becomes a valid query when represented as:
   "/a[@id="1"] or /a[@id=2] or /a[@id=3]"
   
   
5. One side of the equality and relation operator (=, <, >, <=, >=) must be a literal.
    
6. The'join' operation is not supported.
   Points (5) and (6) indicate that comparison inside predicates is limited. At least one argument must be literal for the equality and comparison operator. For instance, the query below is valid: 
   

   "//a[@id > "100"]" or "//a[title = "XPERT"]"
   Whereas, the query below is invalid: 
   "//a[@id=//b/@id]"
   At present, the 'semi-join' operation is not supported.
    

7. Only three functions, "contains()", "in()", and "between()" are supported.
   This indicates that only three functions are supported; "contains()", "in()", and "between()".
   
   
8. "" representing 'anything' is not supported{*}.
   This indicates that the wildcard character "*" is not supported in any form.

Identifiers

Identifiers are expressed in terms of XPath notation. XPath can be used to refer to any part or parts of an XML document. Since message selection is based on actual contents of a message and not just upon the presence of the message, the XPath notation must return a single attribute of an element in the XML file. Any valid XPath notation is supported, but in case an XPath returns multiple elements, only the first one will be evaluated. The following XPath notation is recommended:

Operators

XPATH selectors involve the use of various arithmetical, logical and conditional operators. FioranoMQ CBR supports most of the operators. This section explains, with examples, the support of the following operators:

Standard bracketing () is supported. This implies that the conditions inside a bracket are evaluated first followed by the conditions outside the bracket.

Logical operators in order of precedence: NOT, AND, OR

Comparison operators: =, >, >=, <, <=, <>

Only like type values can be compared. A string can be compared to a string and a boolean to a boolean. However, it is valid to compare exact numeric values and approximate numeric values (the type of conversion required is defined by the rules of Java numeric promotion). If the comparison of non-like type values is attempted, then the selector is always false. 

String and Boolean comparison is restricted to = and <>. Two strings are equal if and only if they contain the same sequence of characters.

"-+, - unary
"*, / multiplication and division
"+, - addition and subtraction
"Arithmetic operations must use Java numeric promotion
"{NOT} BETWEEN arithmetic-expr1 and arithmetic-expr2 (exact numeric values only)

NOT BETWEEN x and y is supported internally as z < x OR z > y
" {NOT} IN (string-literal1, string-literal2...)

(OPTIONAL) {NOT} LIKE pattern-value [ESCAPE escape-character] comparison operator, where identifier has a String value. Pattern-value is a string literal, where '' represents any single character; '%' represents any sequence of characters (including the empty sequence); and all other characters represent themselves. The optional escape-character is a single character string literal, whose character is used to release the special meaning of '' and '%' in pattern-value.

Below are few examples of the use of the LIKE operator with the results:

• "Phone LIKE '12%3' is true for '123' '12993' and false for '1234'
• "Word LIKE 'l_se' is true for 'lose' and false for 'loose'
• "Underscored LIKE '_%' ESCAPE '\' is true for '_foo' and false for 'bar'
• "Phone NOT LIKE '12%3' is false for '123' and '12993' and true for '1234'
• "If identifier of a LIKE or NOT LIKE operation is NULL, the value of the operation is unknown.
• "{NOT} NULL allows for testing of the existence of an element or elements within an XML without actually testing any values.

Examples:
/quotes/bidprice NOT NULL succeeds for any XML which has any elements matching /quotes/bidprice /quotes/bidprice. NULL succeeds for any XML which has no elements matching /quotes/bidprice

Literals

A string literal is enclosed in single quotes with a single quote included, represented by doubled single quote such as 'literal' and 'literal''s'. Similar to Java String literals, these use the Unicode character encoding.

An exact numeric literal is a numeric value without a decimal point: 57, -957, +62. Numbers in represented within the range of 'Java long' are supported. Exact numeric literals use the Java integer literal syntax.

An approximate numeric literal is a numeric value in scientific notation: 7E3, -57.9E2 or a numeric value with a decimal such as 7., -95.7, +6.2. Numbers represented within the range of 'Java double' are supported. Approximate literals use the Java floating point literal syntax.

The two Boolean literals are 'TRUE' and 'FALSE'.