Skip to main content

Last Call Review of draft-ietf-jsonpath-base-16
review-ietf-jsonpath-base-16-opsdir-lc-clarke-2023-08-02-00

Request Review of draft-ietf-jsonpath-base
Requested revision No specific revision (document currently at 21)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2023-08-09
Requested 2023-07-26
Authors Stefan Gössner , Glyn Normington , Carsten Bormann
I-D last updated 2023-08-02
Completed reviews Secdir Last Call review of -17 by Dan Harkins (diff)
Artart Last Call review of -16 by Darrel Miller (diff)
Genart Last Call review of -17 by Linda Dunbar (diff)
Opsdir Last Call review of -16 by Joe Clarke (diff)
Assignment Reviewer Joe Clarke
State Completed
Request Last Call review on draft-ietf-jsonpath-base by Ops Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/op9ySdEyouCoQspXyqP_x4acMbQ
Reviewed revision 16 (document currently at 21)
Result Ready
Completed 2023-08-02
review-ietf-jsonpath-base-16-opsdir-lc-clarke-2023-08-02-00
I have been tasked to review this draft on behalf of OPS DIR.  When I got the
assignment I thought, "64 pages of JSONPath...this is going to hurt."  But I
found this document very well-written and informative.  All in all, it was an
easy and enjoyable read.  I like that examples were both frequent and addressed
positive and negative cases.

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 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. * 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.