Consistently used JEP-12 JSON literals in examples. (#147)

* Consistently used JEP-12 JSON literals in examples.

* Removed <blockquote> sidebar.

Author: springcomp

jep-003-functions.md

@@ -14,6 +14,8 @@ This document proposes modifying the
 [JMESPath grammar](https://jmespath.org/specification.html#grammar)
 to support function expressions.
 
+**Note**: this document uses [JEP-12 JSON Literals](https://github.com/jmespath-community/jmespath.spec/blob/main/jep-012-raw-string-literals.md#abnf) such as strings like `` `"foo"` `` and numbers like `` `-1` ``.
+
 ## Motivation
 
 Functions allow users to easily transform and filter data in JMESPath
@@ -259,9 +261,9 @@ As a final example, here is the steps for evaluating `abs(to_number(bar))`:
 
 |Expression|Result
 |---|---
-| `abs(1)` |1
-| `abs(-1)`|1
-| ``abs(`abc`)``| |`<error: invalid-type>`
+| `` abs(`1`) `` | `1`
+| `` abs(`-1`) ``| `1`
+| `` abs(`"abc"`) ``| |`<error: invalid-type>`
 
 ### avg
 
@@ -297,7 +299,7 @@ Returns the next highest integer value by rounding up if necessary.
 | ``ceil(`1.001`)`` | 2
 | ``ceil(`1.9`)`` | 2
 | ``ceil(`1`)`` | 1
-| ``ceil(`abc`)`` | `null`
+| ``ceil(`"abc"`)`` | `null`
 
 ### contains
 
@@ -318,14 +320,14 @@ the string contains the provided `$search` argument.
 
 |Given|Expression|Result
 |---|---|---
-| n/a | ``contains(`foobar`, `foo`)`` | `true`
-| n/a | ``contains(`foobar`, `not`)`` | `false`
-| n/a | ``contains(`foobar`, `bar`)`` | `true`
-| n/a | ``contains(`false`, `bar`)`` | `<error: invalid-type>`
-| n/a | ``contains(`foobar`, 123)`` | `false`
-| `["a", "b"]` | ``contains(@, `a`)`` | `true`
-| `["a"]` | ``contains(@, `a`)`` | `true`
-| `["a"]` | ``contains(@, `b`)`` | `false`
+| n/a | ``contains(`"foobar"`, `"foo"`)`` | `true`
+| n/a | ``contains(`"foobar"`, `"not"`)`` | `false`
+| n/a | ``contains(`"foobar"`, `"bar"`)`` | `true`
+| n/a | ``contains(`false`, `"bar"`)`` | `<error: invalid-type>`
+| n/a | ``contains(`"foobar"`, `123`)`` | `false`
+| `["a", "b"]` | ``contains(@, `"a"`)`` | `true`
+| `["a"]` | ``contains(@, `"a"`)`` | `true`
+| `["a"]` | ``contains(@, `"b"`)`` | `false`
 
 ### floor
 
@@ -356,10 +358,10 @@ together using the `$glue` argument as a separator between each.
 
 | Given | Expression | Result
 |---|---|---
-| `["a", "b"]` | ``join(`, `, @)`` | "a, b"
-| `["a", "b"]` | ```join(``, @) ``` | "ab"
-| `["a", false, "b"]` | ``join(`, `, @)`` | `<error: invalid-type>`
-| `[false]` | ``join(`, `, @)`` | `<error: invalid-type>`
+| `["a", "b"]` | ``join(`", "`, @)`` | "a, b"
+| `["a", "b"]` | ```join(`""`, @) ``` | "ab"
+| `["a", false, "b"]` | ``join(`", "`, @)`` | `<error: invalid-type>`
+| `[false]` | ``join(`", "`, @)`` | `<error: invalid-type>`
 
 ### keys
 
@@ -399,7 +401,7 @@ Returns the length of the given argument using the following types rules:
 
 | Given | Expression | Result
 |---|---|---
-| n/a | ``length(`abc`)`` | 3
+| n/a | ``length(`"abc"`)`` | 3
 | "current" | `length(@)` | 7
 | "current" | `length(not_there)` | `<error: invalid-type>`
 | `["a", "b", "c"]` | `length(@)` | 3

jep-006-improved-identifiers.md

@@ -16,6 +16,8 @@ identifier grammar rules will be fixed, along with an improved grammar for
 specifying unicode identifiers in a way that is consistent with JSON
 strings.
 
+**Note**: this document uses [JEP-12 JSON Literals](https://github.com/jmespath-community/jmespath.spec/blob/main/jep-012-raw-string-literals.md#abnf) such as strings like `` `"foo"` `` and numbers like `` `-1` ``.
+
 ## Motivation
 
 There are two ways to currently specify an identifier, the unquoted rule:
@@ -172,8 +174,8 @@ this is just a suggested syntax, not a formal proposal), given the data:
 You can now have the following JMESPath expressions:
 
 ```
-foo[?"✓" = `✓`]
-foo[?"\u2713" = `\u2713`]
+foo[?"✓" = `"✓"`]
+foo[?"\u2713" = `"\u2713"`]
 ```
 
 As a general property, any supported JSON string is now a supported quoted

jep-011-let-function.md

@@ -17,6 +17,8 @@ JMESPath to introduce scoping, but provides useful functionality such as being
 able to refer to elements defined outside of the current scope used to evaluate
 an expression.
 
+**Note**: this document uses [JEP-12 JSON Literals](https://github.com/jmespath-community/jmespath.spec/blob/main/jep-012-raw-string-literals.md#abnf) such as strings like `` `"foo"` `` and numbers like `` `-1` ``.
+
 ## Motivation
 
 As a JMESPath expression is being evaluated, the current element, which can be
@@ -34,7 +36,7 @@ to a parent element.
 
 For example, suppose we had this data:
 
-```
+```json
 {"first_choice": "WA",
  "states": [
    {"name": "WA", "cities": ["Seattle", "Bellevue", "Olympia"]},
@@ -50,7 +52,7 @@ unique in the `states` list.  This is currently not possible with JMESPath.
 In this example we can hard code the state `WA`:
 
 ```
-states[?name==`WA`].cities[]
+states[?name==`"WA"`].cities[]
 ```
 
 but it is not possible to base this on a value of `first_choice`, which
@@ -136,7 +138,7 @@ examine the case where the identifier can be resolved from the
 current evaluation context:
 
 ```
-search(let({a: `x`}, &b), {"b": "y"}) -> "y"
+search(let({a: `"x"`}, &b), {"b": "y"}) -> "y"
 ```
 
 In this scenario, we are evaluating the expression `b`, with the
@@ -147,7 +149,7 @@ Now let’s look at an example where an identifier is resolved from
 a scope object provided via `let()`:
 
 ```
-search(let({a: `x`}, &a), {"b": "y"}) -> "x"
+search(let({a: `"x"`}, &a), {"b": "y"}) -> "x"
 ```
 
 Here, we’re trying to resolve the `a` identifier.  The current
@@ -167,15 +169,15 @@ Finally, let’s look at an example of parent scopes.  Consider the
 following expression:
 
 ```
-search(let({a: `x`}, &let({b: `y`}, &{a: a, b: b, c: c})),
+search(let({a: `"x"`}, &let({b: `"y"`}, &{a: a, b: b, c: c})),
        {"c": "z"}) -> {"a": "x", "b": "y", "c": "z"}
 ```
 
 Here we have nested let calls, and the expression we are trying to
 evaluate is the multiselect hash `{a: a, b: b, c: c}`.  The
 `c` identifier comes from the evaluation context `{"c": "z"}`.
 The `b` identifier comes from the scope object in the second `let`
-call: ``{b: `y`}``.  And finally, here’s the lookup process for the
+call: ``{b: `"y"`}``.  And finally, here’s the lookup process for the
 `a` identifier:
 
 
@@ -188,7 +190,7 @@ call: ``{b: `y`}``.  And finally, here’s the lookup process for the
 * Is there a parent scope?  Yes
 
 
-* Does the parent scope, ``{a: `x`}``, define `a`?  Yes, `a` has
+* Does the parent scope, ``{a: `"x"`}``, define `a`?  Yes, `a` has
 the value of `"x"`, so `a` is resolved as the string `"x"`.
 
 ### Current Node Evaluation
@@ -198,7 +200,7 @@ it is worth explicitly calling out how this works with the `let()` function
 and expression references.  Consider the following expression:
 
 ```
-a.let({x: `x`}, &b.let({y: `y`}, &c))
+a.let({x: `"x"`}, &b.let({y: `"y"`}, &c))
 ```
 
 Given the input data: