Hi Linda
Thanks for your review. Detailed responses inline.
As for the need for a standard, I think the WG Charter makes that clear:
"JSONPath was originally described by Stefan Goessner [...] but has never had an official specification of any kind, and the 39+
implementations, while mostly compatible, differ in certain behaviors."
implementations, while mostly compatible, differ in certain behaviors."
Regards,
Glyn
On Thu, 10 Aug 2023 at 19:19, Linda Dunbar via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Linda Dunbar
Review result: Not Ready
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.
Document: draft-ietf-jsonpath-base-17
Reviewer: Linda Dunbar
Review Date: 2023-08-10
IETF LC End Date: 2023-08-09
IESG Telechat date: Not scheduled for a telechat
Summary:
The document specifies a method to parse the JSON objects to get values and
specifies the syntax to retrieve a list of values. The document reads well.
Actually, the document does not specify how JSON documents are parsed, in the sense of producing a syntax tree from a JSON document.
However, like any software programs, errors can be encountered at run time even
after careful review.
Section 2.1 of the document acknowledges that run time errors can occur, e.g. because of resource depletion. As for bugs in implementations: those need not concern the specification.
Major issues:
The major issue is that this document should not be “Standard Track” because:
1. Existing parsers for JSON data don’t need to change to comply with the
syntax specified in this document.
I don't understand this point. JSONPath is query support strictly layered on top of JSON parsing.
2. Like SQL, this document specified
syntax may change as more ways being developed by implementers to parse the
JSON objects.
I don't understand this point either as it addresses JSON parsing rather than a query layer.
3. It is not clear why IANA registration is needed.
Because, as we have seen in the WG, the five function extensions defined by the document will need to be augmented. It is normal in such situations to use IANA registration.
Minor issues:
Nits/editorial comments:
Thanks, Linda Dunbar
--
JSONpath mailing list
JSONpath@xxxxxxxx
https://www.ietf.org/mailman/listinfo/jsonpath
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
