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.
After reading through the spec, all the examples use lower-case for the paths. The spec does say for name selectors that:
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.