Skip to main content
Windward

XPath Selects

Overview

This article goes over miscellaneous features related to XPath selects. Windward used XPath 1.0 until version 14.1 where it was upgraded to XPath 2.0 (using Saxon), and has all the features and limitations thereof. More information about the XPath upgrade can be found in the article below.

 

Announcing Additional Support for XPath 2.0

Select Modes

A select is the process of how an XPath statement is evaluated and what information is returned. Windward will uses a set of rules to guess as to which of the above modes to use. However, you can explicitly force a specific mode by setting the first character of the select to !, =, or ' (as shown below on each item) or selecting the icon next to the XPath statement in the Tag Editor.
 
AutoTag will always display the mode it is using on a select in the UI. In the tag builder if you set it to force a mode, it will place the first character only if that is not the guessed mode for that select.
 
XPath_Select4.png
 
A select can be evaluated in one of three ways:

  • The select is passed to the underlying data to evaluate. The select is evaluated by Windward's macro evaluator.
    • ​Text form for a fully written tag is denoted by an exclamation point and will appear as "  !select=  "

  • The select is placed as a string of text in the output. If a Windward variable is used in the XPath select, the value of the variable will be returned upon evaluation of the XPath statement. Keep in mind that variables can be used within XPath statements.
    • Text form for a fully written tag is denoted by a single apostrophe and will appear as "  'value  "

  • The select is placed as a combination of XPath, variables and/or operations. The variable values will be replaced and operations will be executed to return the final results. For example, if you have 2 XPath statements that need to be added together to return a result you can do this by separating both statements by a "+". Both statements will be evaluated, their values returned and then they will be summed together, returning the final summation result.
    • Text form for a fully written tag is denoted by an equal sign an will appear as "  =evaluate  "

 
Note: select modes were changed in version 10

Advanced

Evaluate Usage

View the following syntax usage for evaluate.

 

evaluate=′${item.price} * ${item.quantity}′

 

The values of the variable ${item} are an expression and the expression is multiplied for a final value. The evaluate substitutes Windward variables (in the form ${var}), yet evaluates the final text so that "${item.subtotal} / 100" will not appear as "1295 / 100" but as a total 12.95. This is useful for situations such as "${price} * ${quantity}" to retrieve a line item total from your data source.

Example of Value versus Evaluate Attribute

View the following syntax usage of value versus evaluate.

 

value=′${item.price} * ${item.quantity}′

 

Value causes a substitution of the values of these variables results in returning “12.95 * 3”. However, using evaluate causes evaluate=′${item.price} * ${item.quantity}′ which substitutes the values of the variables, then evaluates the expression, resulting in 38.85.

Parsing Limitations

Parsing is when the Windward reads the text in the data source element and attempts to determine its value.

 

In the case of using ‘value=’ in your tag syntax, no intelligent parsing of the string (a group of characters) occurs. It performs a simple text substitution for all Windward variable (${variable}) entries, then displays the final value. The string is not passed to the data source provider for evaluation. All of the optional attributes can be used in this case. For example, if ‘value=’ is a number, it can be displayed as a currency or date.

 

Several attempts are made to parse the input string. For a number or currency value, it first attempts to parse the string using the appropriate NumberFormat.parse() method and using NumberFormat.applyPattern() in the Engine. If this fails, it tries Double.parseDouble(). If that fails, it throws a NodeFormatException.

 

For more information parsing in the Engine, please view the Java documentation for the Java classes DateFormat, DecimalFormat, NumberFormat, and SimpleDateFormat.

Date Comparisons

XPath does not support inequality tests on dates. Therefore you cannot test /root/node < ${date}. You can do = and != because it treats them as strings of text but this may return the incorrect result. This is true even if you supply a schema and the node is set to xsd:dateTime, xsd:date, or xsd:time.

 

If you supply a variable such as ${date} that is a Date object, it will be placed in the xsd:date format for a select that is a value and in the xsd:dateTime format if the select is is a select or evaluate.

  • Was this article helpful?