Updated Pr 98 (selectors reworked) #99

cabo · 2021-06-10T18:20:24Z

mit Fix für den YAML-nit

gregsdennis · 2021-06-11T03:42:16Z

@cabo/@goessner can you rename the PR to better reflect what it's trying to do, please? Also a summary of changes would be kind.

cabo · 2021-06-11T05:00:27Z

This PR (actually PR #98) reverts all the fixes in 9be270d
Is this intentional?

goessner · 2021-06-11T05:21:31Z

I understood that multiple small PR's are preferrable, which was not so easy with the complete rewrite of selectors. I can do that from now on. Am 11.06.2021 um 05:42 schrieb Greg Dennis:

…

@goessner <https://github.com/goessner> can you rename the PR to better reflect what it's trying to do, please? Also a summary of changes would be kind. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#99 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABFM6WUCDKLUZXFSHFSYTHTTSGA2JANCNFSM46PBITVQ>. <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virenfrei. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

glyn · 2021-06-11T05:27:29Z

I understood that multiple small PR's are preferrable, which was not so easy with the complete rewrite of selectors. I can do that from now on.

@goessner Do you mean you will now break this PR into multiple small PRs? (That would be great!)

glyn · 2021-06-11T05:34:06Z

draft-ietf-jsonpath-base.md

+Notes:
+
+* Parenthesis can be used with `boolean-expr` for grouping. So filter selection syntax in the original proposal `'[?(<expr)]'` is naturally contained in the current lean syntax `'[?<expr]'` as a special case.
+* Comparisons are restricted to primitive values `number`, `string`, `true`, `false`, `null`. Comparisons with complex values will fail, i.e. no selection occurs.


Rather than fail silently, another option would be to avoid this situation in the syntax. Then failures will produce a syntax error, which is much clearer to the user. Have you checked for consensus of current implementations? This issue comment is relevant.

I would actually like to be able to say @.foo == [1,2]. I think this is a valid use case.

So it appears we need a new issue.

Comparison with structured values

Should comparison with structured values (e.g., @.foo == [1, 2]) be supported?

If it is not supported, should this silently fail or the attempt cause a syntax error (in Updated Pr 98 (selectors reworked) #99, it causes a syntax error, but then the text says something else).

cabo

A few initial impressions.

cabo · 2021-06-11T08:13:30Z

draft-ietf-jsonpath-base.md

@@ -97,6 +97,13 @@ informative:
    seriesinfo:
      ISO/IEC 22537:2006
    date: 2006
+  E4X-overview:


I don't think we need this -- this seems to be a remnant from an older revision.

There are several such remnants, which make it hard to review this PR.

draft-ietf-jsonpath-base.md

cabo · 2021-06-11T08:15:05Z

draft-ietf-jsonpath-base.md

-It also selects all the elements of any array node.
-It selects no nodes from
-number, string, or literal nodes.
+The Argument &mdash; the root JSON value &ndash; is anonymous by nature. By getting assigned the universal name `'$'` it becomes the root node.


Writing the actual characters instead of HTML entity references is preferred.

The same dashes should be used at the start and at the end of an interjection.

draft-ietf-jsonpath-base.md

cabo · 2021-06-11T08:18:19Z

draft-ietf-jsonpath-base.md

-HEXDIG =  DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
-                              ; case insensitive hex digit
+~~~~ abnf
+quoted-member-name  =  %x22 *double-quoted %x22 /       ; "string"


I think we should have a separate set of definitions for literals. This is particular important because JSONPath literals have a more permissive syntax than that of JSON. (Should they?)
Literals should never be confused with the data themselves (i.e., we never should say "string" when we mean "string literal").

Literals should never be confused with the data themselves (i.e., we never should say "string" when we mean "string literal").

What? When was this discussed? Do we now have to say "boolean literal" or "numeric literal?" Where does JSON Path ever use strings that AREN'T a string literal?

Literals should never be confused with the data themselves (i.e., we never should say "string" when we mean "string literal").

What? When was this discussed?

I wasn't there. Must have been before 1972, but I'm pretty sure after 1960.

Do we now have to say "boolean literal" or "numeric literal?"

If we mean the literal, yes. If we mean the value, no.
The important part is to make the distinction.

Where does JSON Path ever use strings that AREN'T a string literal?

The strings in the argument are no longer literals at the time we get them.
Also, as soon as a string literal in the query is parsed, it is the resulting value that is then used; different literals for the same value are not distinguishable for the purposes of the language.

Of course, all this can be done differently, but that is the way it has been done in language design for approximately half a century.

goessner · 2021-06-11T09:22:20Z

------------------------------------------------------------------------ In draft-ietf-jsonpath-base.md <#99 (comment)>: > @@ -97,6 +97,13 @@ informative: seriesinfo: ISO/IEC 22537:2006 date: 2006 + E4X-overview: I don't think we need this -- this seems to be a remnant from an older revision. There are several such remnants, which make it hard to review this PR.

oops ... should have been ES4 overview http://archives.ecma-international.org/2007/misc/overview.pdf Here array slice is documented the first time (pg.34) ... that's all. We can leave it out.

> #### Semantics {: numbered="false" toc="exclude"} -A dot child name which is not a single asterisk (`*`) is considered to -have a member name. -It selects the value corresponding to the name from any object node. -It selects -no nodes from a node which is not a object. - -The member name of a dot child name is the sequence of Unicode characters contained -in that name. - -A dot child name consisting of a single asterisk is a wild card. It selects -all the values of any object node. -It also selects all the elements of any array node. -It selects no nodes from -number, string, or literal nodes. +The Argument — the root JSON value – is anonymous by nature. By getting assigned the universal name `'$'` it becomes the root node. Writing the actual characters instead of HTML entity references is preferred.

– is not accessible per keyboard.

The same dashes should be used at the start and at the end of an interjection.

yes .. typo ..

goessner · 2021-06-11T09:23:30Z

yes .. we need a new issue here .. let's discuss. Am 11.06.2021 um 10:12 schrieb cabo:

…

***@***.**** commented on this pull request. ------------------------------------------------------------------------ In draft-ietf-jsonpath-base.md <#99 (comment)>: > +in-op = " in " ; in operator +comparable = number / quoted-string / ; primitive ... + true / false / null / ; values only + rel-path-val / ; descendant value + calc_val / ; calculated value + json-path ; any value + +rel-path-val = "@" *(dot-selector / index-selector) +calc_val = func "(" [rel-path-val / json-path] ")" +func = "index" +~~~~ + +Notes: + +* Parenthesis can be used with `boolean-expr` for grouping. So filter selection syntax in the original proposal `'[?(<expr)]'` is naturally contained in the current lean syntax `'[?<expr]'` as a special case. +* Comparisons are restricted to primitive values `number`, `string`, `true`, `false`, `null`. Comparisons with complex values will fail, i.e. no selection occurs. So it appears we need a new issue. * Comparison with structured values * Should comparison with structured values (e.g., ***@***.*** == [1, 2]|) be supported? * If it is not supported, should this silently fail or the attempt cause a syntax error (in #99 <#99>, it causes a syntax error, but then the text says something else). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#99 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABFM6WUPIASBBK4FBC2V2EDTSHAQNANCNFSM46PBITVQ>. <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virenfrei. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

cabo · 2021-06-11T09:35:24Z

> + E4X-overview: oops ... should have been ES4 overview http://archives.ecma-international.org/2007/misc/overview.pdf Here array slice is documented the first time (pg.34) ... that's all. We can leave it out.

I don’t have a strong opinion here, but I think we are better off referencing the current state in ES2020 (also applies to {{SLICE}}). (The bibliography entry `E4X-overview` turned up in my quick glance at the PR because it is not currently being used. So we need to add a citation or remove the entry. This is all housekeeping… Let’s try to extract the technical discussion points first.) Grüße, Carsten

cabo · 2021-06-14T08:06:57Z

– is not accessible per keyboard.

It sure is.
This probably should be an —, however.

If you are using Windows:
https://softwareaccountant.com/em-dash-in-word/

goessner · 2021-06-14T08:28:16Z

ahh ... learning something new .. only*alt+0151 *on numeric keyboard works for me.** Am 14.06.2021 um 10:07 schrieb cabo:

…

– is not accessible per keyboard. It sure is. This probably should be an |—|, however. If you are using Windows: https://softwareaccountant.com/em-dash-in-word/ <https://softwareaccountant.com/em-dash-in-word/> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#99 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABFM6WX7H6MN745JDHKUEKTTSW2DBANCNFSM46PBITVQ>. <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virenfrei. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

cabo · 2021-06-14T08:32:35Z

On 2021-06-14, at 10:28, Stefan Goessner ***@***.***> wrote: ahh ... learning something new .. only*alt+0151 *on numeric keyboard works for me.**

… and I think this is even easier to type than — … (Shift-Option-minus on the Mac. On the iPad or iPhone, long-press the minus and swipe to the character you want.) Grüße, Carsten

glyn · 2021-06-14T09:50:22Z

@cabo please rebase

cabo · 2021-06-16T10:48:12Z

Covered by #102 now.

goessner and others added 3 commits June 10, 2021 18:57

Selectors reworked ...

2be1afe

Fix YAML nit

c6fe205

Fix syntax nits

31ee9bc

glyn reviewed Jun 11, 2021

View reviewed changes

cabo commented Jun 11, 2021

View reviewed changes

cabo changed the title ~~Pr 98~~ Updated Pr 98 (selectors reworked) Jun 14, 2021

cabo mentioned this pull request Jun 14, 2021

Selectors reworked ... #102

Merged

cabo closed this Jun 16, 2021

cabo deleted the pr-98 branch March 16, 2023 20:58

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Updated Pr 98 (selectors reworked) #99

Updated Pr 98 (selectors reworked) #99

cabo commented Jun 10, 2021

gregsdennis commented Jun 11, 2021 •

edited

Loading

cabo commented Jun 11, 2021

goessner commented Jun 11, 2021 via email

glyn commented Jun 11, 2021 •

edited

Loading

glyn Jun 11, 2021

gregsdennis Jun 11, 2021

cabo Jun 11, 2021

cabo left a comment

cabo Jun 11, 2021

cabo Jun 11, 2021

cabo Jun 11, 2021

gregsdennis Jun 11, 2021

cabo Jun 11, 2021

goessner commented Jun 11, 2021 via email

goessner commented Jun 11, 2021 via email

cabo commented Jun 11, 2021 via email

cabo commented Jun 14, 2021 •

edited

Loading

goessner commented Jun 14, 2021 via email

cabo commented Jun 14, 2021 via email

glyn commented Jun 14, 2021

cabo commented Jun 16, 2021

Updated Pr 98 (selectors reworked) #99

Updated Pr 98 (selectors reworked) #99

Conversation

cabo commented Jun 10, 2021

gregsdennis commented Jun 11, 2021 • edited Loading

cabo commented Jun 11, 2021

goessner commented Jun 11, 2021 via email

glyn commented Jun 11, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cabo left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

goessner commented Jun 11, 2021 via email

goessner commented Jun 11, 2021 via email

cabo commented Jun 11, 2021 via email

cabo commented Jun 14, 2021 • edited Loading

goessner commented Jun 14, 2021 via email

cabo commented Jun 14, 2021 via email

glyn commented Jun 14, 2021

cabo commented Jun 16, 2021

gregsdennis commented Jun 11, 2021 •

edited

Loading

glyn commented Jun 11, 2021 •

edited

Loading

cabo commented Jun 14, 2021 •

edited

Loading