Closed glyn closed 1 year ago
I think we should keep our member name definition and provide conversion logic (as we're doing now) since we support strings with single quotes. If we keep the JSON concept of including the quotes, then we have to consider another way to allow (prefer?) single quotes.
I'm not sure how this will affect the dot-member syntax.
(To be clear, I'm for making the adjustment to the language.)
One solution is to strip the double quotes from the member name, like this:
Applying the
name-selector
to an object node selects a member value whose name, with the surrounding double quotes removed, equals the member name M, [...]
I like that. Let's see what others say.
The definition of Objects in the JSON spec states that the name in a name/value pair inside an Object is a string. The definition of strings says "A string begins and ends with quotation marks.". This seems to imply that a name includes the surrounding double quotes.
The JSONPath spec adopts this definition in its terminology section.
What? This needs to be fixed.
JSONPath does not operate on JSON texts, but on JSON values. It never sees those quotes. Any leakage of the confusion between JSON text and JSON value RFC 8259 exhibits here needs to be stamped out.
The definition of strings says "A string begins and ends with quotation marks.".
Oh, and this is quoting out of context. RFC 8259 says:
The representation of strings is similar to conventions used in the C family of programming languages. A string begins and ends with quotation marks.
Clearly, the "A string" here is supposed to repeat "The representation of strings".
Anyway, we need to say how the JSONPath representation of strings needs to be parsed (all of double-quoted, single-quoted, and bare as in .name
), but need to make sure there is no confusion with the JSON representation of strings.
Thanks for pointing out how I was misreading the JSON spec. I suspect I won't be the only one, so some clarification is in order. I'll submit a PR.
PR #300 was reworked as a series of PRs which I believe address this issue. Specifically, there is now an introductory section 1.3 on JSON values.
The definition of Objects in the JSON spec states that the name in a name/value pair inside an Object is a string. The definition of strings says "A string begins and ends with quotation marks.". This seems to imply that a name includes the surrounding double quotes.
The JSONPath spec adopts this definition in its terminology section. Later, the name selector section says:
and
The spec needs to be clarified so it is clear that M is compared to the name without its surrounding double quotes. We may need to change our definition of (member) name to achieve this.