Subject: [Jsonpath] Regarding the draft of "JSONPath: Query expressions for JSON"

From: Ross Bundy <[email-masked]>
Date: Wed, 20 Oct 2021 12:51:48 -0500

To Whom It May Concern,

Re: https://www.ietf.org/archive/id/draft-ietf-jsonpath-base-01.html

I'm glad that this is becoming an RFC!

A few comments regarding the draft...

In one of the examples, is given the expression:
$..book[(@.length-1)]
which is intended to mean the last book in the list.

The use of ".length" is confusing and perhaps limiting.

It seems obvious that ".length" refers to metadata about the current
element, @, and not to a child element of @, but in all other contexts,
".<name>" refers to a child element. The context about how to interpret the
".<name>" as metadata is provided by the surrounding expression engine
characters, "(" and ")", which looks very similar to the filter expression
characters, "?(" and ")", which allows to references to child elements, as
shown in a later example:
 $..book[?(@.price<10)]

The syntax between the expression engine and the filter expression, and the
specification of child element references and metadata references, are too
similar and, thus, visually confusing.

Further, some future expansion of JSONPath might want to use an element
name in the expression engine, but this creates a potential conflict if the
JSON element is named "length". For example, given the structure:
dimensions: {
    "length": 5,
    "width": 10,
    "height": 15
}
does "(...@.length...)" refer to the "length" element or to the "length"
metadata?

Finally, the meaning of "length" as a metadata attribute of an element, and
a description of what other metadata attributes which may be available, are
not documented in the draft.

I hope this helps.

I'm excited to see this become and RFC.

Regards,
--Ross

-- 
Ross E. Bundy
Sr. Manager, Engineering
  1800 South Oak St, Ste 209, Champaign, IL 61820* *
  [email-masked]* *
 <https://www.linkedin.com/in/rossbundy/>
<https://event.webcasts.com/starthere.jsp?ei=1503062&tp_key=7b940df644&sti=amobee>

---

From: Greg Dennis <[email-masked]>
Date: Fri, 29 Oct 2021 19:50:26 +0000 (UTC)

Hey there, Ross.
Your sentient is certainly shared with those involved with the spec creation.
Please feel free to read and comment on this GitHub issue.  It's the most recent place where we're discussing this.
https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/issues/64
Thanks for the input!
Greg

  On Sat, 30 Oct 2021 at 4:26 am, Ross Bundy<[email-masked]> wrote:   To Whom It May Concern,

Re: https://www.ietf.org/archive/id/draft-ietf-jsonpath-base-01.html
I'm glad that this is becoming an RFC!
A few comments regarding the draft...
In one of the examples, is given the expression:
$..book[(@.length-1)]which is intended to mean the last book in the list.
The use of ".length" is confusing and perhaps limiting.
It seems obvious that ".length" refers to metadata about the current element, @, and not to a child element of @, but in all other contexts, ".<name>" refers to a child element. The context about how to interpret the ".<name>" as metadata is provided by the surrounding expression engine characters, "(" and ")", which looks very similar to the filter expression characters, "?(" and ")", which allows to references to child elements, as shown in a later example: $..book[?(@.price<10)] 
The syntax between the expression engine and the filter expression, and the specification of child element references and metadata references, are too similar and, thus, visually confusing.
Further, some future expansion of JSONPath might want to use an element name in the expression engine, but this creates a potential conflict if the JSON element is named "length". For example, given the structure:dimensions: {    "length": 5,    "width": 10,    "height": 15
}
does "(...@.length...)" refer to the "length" element or to the "length" metadata?

Finally, the meaning of "length" as a metadata attribute of an element, and a description of what other metadata attributes which may be available, are not documented in the draft.
I hope this helps.
I'm excited to see this become and RFC.
Regards,--Ross

-- 

|  |
|  |
| 
| 

 |
|  
|  
|  
|  Ross E. Bundy Sr. Manager, Engineering   |

  |
|  
|    |
|    1800 South Oak St, Ste 209, Champaign, IL 61820 
   [email-masked]   |
| 
|  |

 |

  |

  |

 |
| 
|     |

 |

 |
|  |

-- 
Jsonpath mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jsonpath

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 30 Oct 2021 10:07:16 +0200

> https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/issues/64

That’s a scary issue for a newcomer to look at :-)

It’s meandering all over the place.
This meandering is great for mailing list discussions to make sure that all issue are uncovered, but our GitHub issues need to get more focused than that so they stay actionable.

Not sure #64 has resolved on anything re .length.

BTW, the editors will step quickly through a sequence of PRs so we have an updated draft by Nov 7 (when the I-D archive opens again).
Tim’s list [1] is the most actionable input we have at this time, but of course other reviews are welcome.

You can see generated renderings, as well as various diffs, of the main branch as well as recent PRs at [2].

Grüße, Carsten

[1]: https://mailarchive.ietf.org/arch/msg/jsonpath/aaZpGsUIZD5fKZS2KMQjQEizDcA
[2]: https://ietf-wg-jsonpath.github.io/draft-ietf-jsonpath-base/