ietf-wg-jsonpath / draft-ietf-jsonpath-base

Development of a JSONPath internet draft
https://ietf-wg-jsonpath.github.io/draft-ietf-jsonpath-base/
Other
59 stars 20 forks source link

String literals escaping rules #463

Closed f3ath closed 1 year ago

f3ath commented 1 year ago

I was not able to find where the spec defines the rules for string literals in function arguments. The spec requires certain character to be escaped (and treated accordingly) in name selectors, but are there similar requirements for function arguments?

E.g. if I want to define a new test in the CTS, what's the correct way:

Option 1. String literals do NOT require escaping backslash, so I only need to escape it in JSON:

{
    "selector": "$[?search(@, '\\p{Lu}')]",
    "document": ["a", "A", "1", true, [], {}],
    "result": ["A"]
{

Option 2. String literals DO require escaping backslashes, so I need to account for that:

{
    "selector": "$[?search(@, '\\\\p{Lu}')]",
    "document": ["a", "A", "1", true, [], {}],
    "result": ["A"]
{
cabo commented 1 year ago

If you store a JSONPath query in a JSON text, you have to apply JSON rules, including escaping of backslashes. That is not governed by JSONPath, but by your usage of JSON.

Within a JSONPath string literal, you will need to escape backslashes. String literals are one of the ways of supplying arguments to a function.

So the combination of your use of JSON to store JSONPath queries and the JSONPath rules for string literals make me believe that Option 2 is what you want.

cabo commented 1 year ago

No further discussion; I gather this issue is addressed.