search

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

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

Path Normalization and Casing #518

Open agrittob opened 3 months ago

agrittob commented 3 months ago

After reading through the spec, all the examples use lower-case for the paths. The spec does say for name selectors that:

Two strings MUST be considered equal if and only if they are identical sequences of Unicode scalar values. In other words, normalization operations MUST NOT be applied to either the member name string M from the JSONPath or the member name strings in the JSON prior to comparison

There does not seem to be any other wording that I can find that covers the handling for casing. Most frameworks for processing JSON allow the ability to configure the serialization/deserializaiton to account for the fact that the data may be cased differently. Given the current JSONPath spec, it seems that the intention is the data will always be in a specific format.

Has any consideration been given to modifying the syntax for the name selector to provide a way to identify it as case-insensitive? I understand that with different implementations there are different performance implications to doing a case-insensitive match but providing a way in the spec to identify a name or path that should be normalized prior to matching would be useful.

gregsdennis commented 3 months ago

Most frameworks for processing JSON allow the ability to configure the serialization/deserializaiton to account for the fact that the data may be cased differently.

I haven't seen evidence that specifications do this, but rather it's the implementations (operating outside of the related specs) that provide this feature via a setting.