I'm also quite puzzled by this review.
On Thu, Aug 10, 2023 at 11:18 AM Linda Dunbar via Datatracker <noreply@xxxxxxxx> wrote:
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 claim. If I'm parsing it correctly, since this document doesn't demand changes to JSON parsers, this is not worthy of standardization. Is that correct?
JSON is a syntax used to describe (serialize) a certain class of objects. Those objects are trees whose nodes are numbers, strings, nulls, booleans, lists of nodes, or key-value pairs of nodes. This specification presents a syntax for describing a path to follow from the root of such a tree to a node in that tree and returning what's there. It is appropriate for standardization so that producers and consumers of JSON paths can agree on what exactly they mean and how they are to be interpreted.
If we used something else to serialize the tree, rather than JSON, we would still have trees we want to walk through to get values. I would argue that JSONpath would still be valuable -- though by some other name, probably -- even if JSON didn't exist. So I don't understand the assertion being made here.
2. Like SQL, this document specified
syntax may change as more ways being developed by implementers to parse the
JSON objects.
I'm unclear on this as well. The presence of possible future syntaxes, or changes to this one, doesn't render this unworthy of standardization, especially given the well-established nature of this work and its need for interoperability outside of private environments.
3. It is not clear why IANA registration is needed.
From the abstract of RFC 8126:
Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper.
Seems like a bullseye to me.
-MSK
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
