Re: [Last-Call] [Jsonpath] Opsdir last call review of draft-ietf-jsonpath-base-16

"Joe Clarke \(jclarke\)" <jclarke=40cisco.com@xxxxxxxxxxxxxx> · Thu, 3 Aug 2023 18:15:38 +0000

I also liked how the authors addressed the origin of JSONPath and the rationale

for creating a standard and why the standard might deviate from other usages. 

That said, I expected to see a more thorough comparison of the original

unofficial JSONPath specification and what is being standardized.  For example,

I like 
https://cburgmer.github.io/json-path-comparison/ as a means to know how

JSONPath is implemented in each language.  I'm not saying this draft needs such

an extensive comparison of all languages, but perhaps specific instances where

it deviates from its direct and explicit ancestor would be helpful.

I have a couple of hesitations. Firstly, I'm not sure it would be particularly helpful to pick one of the many existing variants of JSONPath for comparison (even if it was the original).
 Secondly, one of the reasons for standardising JSONPath was the lack of formality, completeness, etc. in Gössner's rather brief article. So I feel the comparison would end up being rather shallow unless we attempted to compare Gössner two implementations which
 would be an open-ended exercise.

I'm sure migration guides will arise naturally as implementations of the JSONPath standard become more common. These can be written from the perspective of a particular language implementation
 and how to migrate from an older implementation to an implementation of the standard. I feel these would be much more useful than a brief "diff" in the spec.

JMC: I’m sure they will (as has happened to tools like jq).  I thought that those that implemented Gössner’s JSONPath today might like a quick guide to aid them in porting their implementation to the standard.

I had two comments otherwise:

* In Section 1.5, two of your examples use parentheses whereas in Section 1.4.3

the book example filter does not.  I didn't find clear guidance on when to use

the paren-_expression_ and when not to.

When writing a JSONPath query that needs to work with both standard and non-standard implementations, parentheses would be necessary. However, I think we might suffer from scope creep
 if the spec was to discuss how to support non-standard implementations. Other than that, using or omitting the parentheses is a matter of taste and not something I would say the spec needs to provide guidance on. I guess we could strip out the parentheses
 in 1.5 for consistency.

JMC: Or at least explain when/where paren might be needed.  You have ABNF syntax for it, but I never found clear guidance on when to use it.  I may have missed that in the read, though.

* In Section 2.3.5.2, sentence, "Applied

to primitive values, it selects nothing." my gut was perhaps an additional,

"and MUST NOT raise and error" should be added to be explicit that in this case

an empty nodelist is expected and not an error.  Moreover, as I read further

and "Nothing" is called out as a special type, I felt some explicit text that

an empty nodelist is returned would add clarity.

The overview in 2.1.2 states "A syntactically valid segment
MUST NOT produce errors when executing the query." This principle applies throughout and I'd like to avoid repeating this in specific sections.

The confusion between an empty nodelist and "Nothing" is a concern and may need more wording to sort out, but again I'd prefer not to scatter this throughout the spec.

JMC: I honestly didn’t feel it needed to be anywhere else but here.

Joe

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call