Replies: 2 comments
-
An implication of making RFC 9535 a dependency is that, for consistency, template string literals should follow the same rules for escape sequences. Such as Unicode escape sequences. Liquid2 - strings defines Python style Unicode escape sequences, whereas RFC 9535 uses JSON style. |
Beta Was this translation helpful? Give feedback.
0 replies
-
Discussions and development of a specification for Liquid2 have been moved to https://github.com/liquid2-org. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Here I describe syntax and semantics for variables in Liquid2.
For context, and until such time that expressions have been defined for Liquid2, variables are used in output statements
{{ some_identifier }}
And as arguments to filters
Or as arguments to tags
Variables can be paths, with segments chained together to retrieve values from arbitrarily nested template context data.
And bracket notation is used when a variable's name is not a valid identifier.
Variables and paths
Every variable is a JSONPath expression with syntax following RFC 9535, plus the following extensions/modifications.
With these extensions to the JSONPath standard, most legacy Liquid variables are valid Liquid2 paths.
Syntax
TODO: modified ABNF from RFC 9535
Semantics
JSONPath expressions are evaluated with template contextual data as their query argument, and the results used as variables in the enclosing Liquid expression, after applying the following rules:
Examples
With the optional root identifier (
$
), these paths are equivalent:Embedded queries are coerced to name or index selectors:
Beta Was this translation helpful? Give feedback.
All reactions