With JEP-12, raw-string literals where introduced and json-value was tighten to more strictly adhere to the JSON specification.
As a result, syntax like `foo` was being deprecated in favor of `"foo`".
As JMESPath Community intends to fully deprecate legacy syntax, a few changes will be made.
Please, consider documenting legacy syntax, clarifying its deprecation policy.
Please, consider adding notes about supporting legacy syntax and its relationship with regards to standards compliance.
Implementations were free to support legacy syntax after JEP-12 was introduced. This may mean that expressions like `foo` were still successfully parsed automatically. The deprecation process SHOULD discourage automatic parsing and qualify that as non-compliant behaviour. Additionally, the deprecation process SHOULD promote explicit opt-in to the legacy syntax if at all desirable for an implementation.
With JEP-12,
raw-stringliterals where introduced andjson-valuewas tighten to more strictly adhere to the JSON specification.As a result, syntax like
`foo`was being deprecated in favor of`"foo`".As JMESPath Community intends to fully deprecate legacy syntax, a few changes will be made.
Please, consider documenting legacy syntax, clarifying its deprecation policy.
Please, consider adding notes about supporting legacy syntax and its relationship with regards to standards compliance.
Implementations were free to support legacy syntax after JEP-12 was introduced. This may mean that expressions like
`foo`were still successfully parsed automatically. The deprecation process SHOULD discourage automatic parsing and qualify that as non-compliant behaviour. Additionally, the deprecation process SHOULD promote explicit opt-in to the legacy syntax if at all desirable for an implementation.