Expression Reference

This page is the complete reference for expression syntax: operators and every verified public function. It covers the shared grammar used by Validation, Skip Logic, and Calculations.

If you are just getting started, read Form Logic Overview first. This page is a reference, not a tutorial.

Literals

Expression operators

Comparison

There is no <> operator. Use !=.

Logical

Arithmetic

Precedence (highest to lowest)

1. Unary: -, not, !
2. Multiplication / division: *, /, div, mod
3. Addition / subtraction: +, -
4. Comparison: =, !=, <, >, <=, >=
5. Logical AND: and
6. Logical OR: or (lowest)

Parentheses override precedence. For complex expressions, add parentheses even when not strictly required — they make the intent clear and guard against precedence mistakes:

(${age} >= 15 and ${age} <= 49) and ${pregnant} = 'yes'

Ternary

MQUAD uses the if() function for conditional values — see below. The ? : ternary syntax exists only in the Flutter expression engine and does not parse on the web runtime, so it is not part of the supported public grammar.

Function reference

All functions listed here are verified in the MQUAD expression engines. The Platforms column shows where each function is implemented:

• Web — web designer validation, web form runtime
• Mobile — Flutter field app
• Backend — survey-service validation whitelist / form-service evaluation

Unless noted, a function is available on all three. Functions marked MQUAD extension are MQUAD-specific additions; the rest are standard XLSForm/ODK functions.

Date

Time

Age

Health / pregnancy

Numeric

Text / string

Selection

Conditional

Utility

Cross-platform compatibility notes

The following functions have different behaviour across platforms. They are verified as they stand; use them with care and prefer the recommended alternative where one is given.

days-between argument order (⚠ significant)

• Web: days-between(d1, d2) computes d2 − d1 (second minus first).
• Mobile & backend: days-between(d1, d2) computes d1 − d2 (first minus second).

Recommendation: use date-diff('days', start, end) instead — it is frozen, consistent on every platform, and signed.

substring / substr indexing

• Web: substring(s, start, end?) — 0-based start; end is an end index (JavaScript semantics).
• Mobile: substr(s, start, length?) — 0-based start; third argument is a length.
• Backend: substring(s, start, length?) — XPath-style 1-based start; third argument is a length.

Recommendation: prefer contains(), starts-with(), and string-length() for cross-platform text logic.

Ternary ? :

Only the Flutter expression engine parses ? :. Use if() everywhere.

regex() anchoring

The web engine treats regex(v, pattern) as a full-string match (the pattern is anchored: ^(?:pattern)$). The mobile app and backend use a partial match (hasMatch / search). The designer's validation builder generates fully anchored patterns (regex(., '^[0-9]+$')), which behave the same everywhere. If you write regex() by hand, include the ^...$ anchors so results are identical on every platform.

selected() return type on web

The web calculation engine returns the string 'true' / 'false' from selected() (for parity with ODK), while mobile and backend return real booleans. In a boolean context (and/or/if), both strings are truthy on web — so prefer writing selected(${multi}, 'x') as a constraint or relevance expression (where it is handled correctly) rather than nesting it inside an if() calculation on web.

Backend-only functions

floor, ceiling, normalize-space, translate, last, empty, decimal-date-time exist in the backend registries but not in the web or mobile runtimes. They will not produce results in a web or mobile calculation — avoid them in survey logic.

Mobile-only functions

pulldata (external CSV lookup), substr, boolean, decimal-round, decimal-log10 are mobile-only. pulldata requires a bundled CSV file and is not available on the web runtime.

Design-time vs runtime validation

The survey designer validates expressions when you save:

• Unknown question references are flagged.
• Unknown function names are flagged against the backend whitelist.
• Unbalanced quotes/parentheses are flagged.
• Circular dependencies between expressions are detected and blocked.
• Skip-logic scope rules (same-group + top-level references) are enforced.

These same expressions are then evaluated at runtime by the web runtime, the mobile app, and the form-service backend — a "valid at design time" expression is guaranteed to run, but its result depends on the rules above (see Blank and Invalid Values).

Client-side vs server-side evaluation (web)

On the web runtime, constraint (validation) checking while answering uses an inline checker that supports simple comparisons (${age} >= 18, . >= 5), selected(), and and / or / not() — it does not evaluate function-based constraints such as string-length(.), regex(., ...), or count-selected(...). Those are enforced by the server at submission (and by the mobile app inline). The mobile app evaluates all constraints with the full expression engine.