Selectors reworked ... #98

goessner · 2021-06-10T17:11:17Z

... Filter selectors added

glyn

It's wonderful to see a PR covering filters and descendants. Well done @goessner!

The downside is that the PR is quite large and I ran out of steam in my initial sitting. In other words, I'll probably have more detailed comments next time I look.

I would have preferred a separate PR for descendants and then a series of PRs gradually filling out filter expressions, so that detailed review is more feasible. Once we get two or three people's comments on this PR, it's likely to become unmanageable.

draft-ietf-jsonpath-base.md

glyn · 2021-06-11T01:11:41Z

draft-ietf-jsonpath-base.md

+* 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.
+* Implicite type conversions during comparisons are not performed. So `"13 == '13'"` selects nothing.
+* A member or element value by itself is *falsy* only, if it does not exist. Otherwise it is *truthy*, resulting in its value. To be more specific explicite comparisons are necessary. This existence test &ndash; as an exception of the general rule &ndash; also works with complex values.


Please define the terms truthy and falsy.

Perhaps instead simply drop "truthy" and "falsy" in favor of just saying that a rel-path-value by itself select the item if the relative path can be resolved (or some such language).

Having "truthy" and "falsy" at all contradicts the "explicit comparisons are necessary" statement since these terms are typically used in systems with loose comparisons.

Instead define it, dropping is better.

draft-ietf-jsonpath-base.md

glyn · 2021-06-11T01:13:41Z

draft-ietf-jsonpath-base.md

+* Regular expression tests can be applied to `string` values only.
+* Containment tests work with arrays and objects.
+* Explicite boolean type conversion is done by the not operator `neg-op`.
+* The behaviour of operators is consistent with the 'C'-family of programming languages.


This statement seems out of place in the syntax section. Do we need an "Informal Semantics" section?

will be moved. Not sure when to move to semantic or informal semantics section.

@goessner wrote:

will be moved. Not sure when to move to semantic or informal semantics section.

If by "when" you meant "whether", I think the statement should be moved to a new informal semantics section.

It should perhaps read better:

Syntax and behaviour of operators is consistent with the 'C'-family of programming languages.

Otherwise we might need to add a table of operator precedence ... which would be no problem though.

FYI: Have a look at how RFC 8949 solves that problem:
https://www.rfc-editor.org/rfc/rfc8949.html#section-1.2-6

The IESG will insist on a reference to the C standard, I can tell you this much :-)

@glyn: By "when" I mean "whenever" in comparable situations, should it goto

syntax

semantics

informal semantics

Are there specific rules especially to allocate to the last two.

@glyn: By "when" I mean "whenever" in comparable situations, should it goto

* syntax * semantics * informal semantics

Are there specific rules especially to allocate to the last two.

No rules, but the idea with array slices was to introduce the semantics gently in the (informative) informal semantics section and then spell out the (normative) semantics, possibly more indigestibly, in the semantics section. But I am not wedded to this convention so long as we don't confuse normative and informative text.

glyn · 2021-06-11T01:15:21Z

draft-ietf-jsonpath-base.md

+
+rel-path-val = "@" *(dot-selector / index-selector) 
+calc_val     = func "(" [rel-path-val / json-path] ")"
+func         = "index"


Please define the semantics of index in the semantics section.

cabo · 2021-06-11T05:02:05Z

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

goessner · 2021-06-11T05:16:59Z

hmm .. so we generally prefer readable characters over their unicode representation ? I will change that (back). Am 11.06.2021 um 07:02 schrieb cabo:

…

This PR (actually PR #98 <#98>) appears to revert all the fixes in 9be270d <9be270d> Is this intentional? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#98 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABFM6WVPPRVPUGQNFCNXCNTTSGKFVANCNFSM46O5XMJQ>. <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-11T05:21:17Z

Indeed, I do prefer readable documents over unreadable ones :-)

We can discuss this, but my question really was about undoing a change that I thought we had agreed to make.

cabo · 2021-06-11T05:24:32Z

I will change that (back).

Please use the branch pr-98 or merge it, before generating more changes.

(My tools have a hard time juggling multiple branches that are called main, hence I created that branch to make my fixes.)

gregsdennis

I agree that these sets of changes (the selectors and defining the filters) could have been better served in two PRs, but this looks like a good start.

gregsdennis · 2021-06-11T04:08:16Z

draft-ietf-jsonpath-base.md


 #### Semantics
+The Argument &mdash; the root JSON value &ndash; is anonymous by nature. By getting assigned the universal name `'$'` it becomes the root node. 


This is interesting. You're claiming the thing that's named "Argument" is anonymous, but once referenced with $ it suddenly has a name? I'm not sure this provides any benefit over just saying that the Argument is the root node and can be referenced with $.

gregsdennis · 2021-06-11T04:09:44Z

draft-ietf-jsonpath-base.md

+dot-selector    = "." dot-member-name
+dot-member-name = 1*(
+                      DIGIT /
+                      ALPHA /
+                      "_"   /           ; _
+                      %x80-10FFFF       ; any non-ASCII Unicode character
+                    )
+DIGIT           =  %x30-39              ; 0-9
+ALPHA           =  %x41-5A / %x61-7A    ; A-Z / a-z


This definition also resolves #16 (and duplicate #94). 👍

I still needs to be discussed, if a dot-member-name is allowed to start with a DIGIT.

What does applying .1 to [1, 2, 3] mean?

draft-ietf-jsonpath-base.md

gregsdennis · 2021-06-11T04:18:55Z

draft-ietf-jsonpath-base.md

+The behaviour of an implementation is undefined for member names which do
+not encode Unicode characters.


Good use of "undefined behavior" 👍

Cannot happen.

gregsdennis · 2021-06-11T04:21:56Z

draft-ietf-jsonpath-base.md

+quoted-member-name  =  %x22 *double-quoted %x22 /       ; "string"
+                       %x27 *single-quoted %x27         ; 'string'


What is the * for in *double-quoted? The other components (e.g. ESC and unescaped) don't have them.

' simply means multiple ...

This should point to the string literal syntax that we are using for comparisons as well.

gregsdennis · 2021-06-11T05:30:34Z

draft-ietf-jsonpath-base.md

+               json-path                            ; any value
+
+rel-path-val = "@" *(dot-selector / index-selector) 
+calc_val     = func "(" [rel-path-val / json-path] ")"


I'm not sure we have a precedence or decision on functions/calculated values yet (index() or otherwise). It's probably best to leave this out until we can identify a family of functions that we'd like to include so that we can decide on a format that works for everything.

in fact i am quite reluctant here. It's a proposal needing discussion ... will most certainly result in an issue..

gregsdennis · 2021-06-11T05:31:51Z

draft-ietf-jsonpath-base.md

+comp-expr    = (rel-path-val /
+                calc-val) [(comp-op comparable /  ; comparison
+                            regex-op regex     /  ; RegEx test
+                            in-op container )]    ; containment test


container needs a definition

yes ... or more simply

in-op (array / object)

array and object don't have a definition either.
Do you mean expressions that return an array or object?
Or maybe just literals of these types?

both ...

[[email protected] in ['red,'green','blue']]

or

[[email protected] in $.validColors]

gregsdennis · 2021-06-11T05:45:47Z

draft-ietf-jsonpath-base.md

+
+If the result is `true`, the current item, represented by `'@'`, is selected. In case of a `false` result, it is not.
+
+~~~~ abnf


Did we decide against arithmetic operations? These are widely supported and should (perhaps eventually) be supported.

gregsdennis · 2021-06-11T05:54:01Z

draft-ietf-jsonpath-base.md

+* 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.
+* Implicite type conversions during comparisons are not performed. So `"13 == '13'"` selects nothing.
+* A member or element value by itself is *falsy* only, if it does not exist. Otherwise it is *truthy*, resulting in its value. To be more specific explicite comparisons are necessary. This existence test &ndash; as an exception of the general rule &ndash; also works with complex values.


Perhaps instead simply drop "truthy" and "falsy" in favor of just saying that a rel-path-value by itself select the item if the relative path can be resolved (or some such language).

Having "truthy" and "falsy" at all contradicts the "explicit comparisons are necessary" statement since these terms are typically used in systems with loose comparisons.

gregsdennis · 2021-06-11T05:59:43Z

draft-ietf-jsonpath-base.md

+               calc_val /                           ; calculated value
+               json-path                            ; any value
+
+rel-path-val = "@" *(dot-selector / index-selector) 


I would suggest support for any selector except another filter selector (but it may be supported later). This would allow further support for things like $[?(@..foo contains 42)] which would return true for any item that contains a foo property with a value of 42 at any descended level.

goessner · 2021-06-11T09:12:24Z

I would like to thank all for those valuable comments and requested changes. I will accept most changes without further comments. Can return to here tomorrow at the earliest.

…

-- sg

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

@goessner please rebase

goessner · 2021-06-14T15:12:06Z

... had problems rebasing ... made a fresh clone instead. -- sg Am 14.06.2021 um 11:51 schrieb Glyn Normington:

…

@goessner <https://github.com/goessner> please rebase — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#98 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABFM6WTKY3EABSEYK3DWZM3TSXGJHANCNFSM46O5XMJQ>. <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-14T15:38:58Z

... and I went ahead and did what I think is a full rebase, with all the changes, no conflicts, and a correct build. Now #102.

cabo · 2021-06-14T16:11:52Z

#102.

... and I put in a short review there as well.

As per #98 (comment)

#98 (comment)

As per #98 (comment)

Selectors reworked ...

2be1afe

glyn requested changes Jun 11, 2021

View reviewed changes

cabo mentioned this pull request Jun 11, 2021

Updated Pr 98 (selectors reworked) #99

Closed

gregsdennis requested changes Jun 11, 2021

View reviewed changes

Merge remote-tracking branch 'upstream/main' into main

1dfeb05

cabo added a commit that referenced this pull request Jun 15, 2021

(editorial) .* on primitive selects no value

7d0c18f

As per #98 (comment)

gregsdennis mentioned this pull request Jun 15, 2021

Selectors reworked ... #102

Merged

cabo added a commit that referenced this pull request Jun 15, 2021

(editorial) Fully act on:

13a7bed

#98 (comment)

cabo added a commit that referenced this pull request Jun 15, 2021

(editorial): simplify; another nothing/no value.

84e4abc

As per #98 (comment)

cabo added a commit that referenced this pull request Jun 15, 2021

(editorial): avoid "natural rule"

3eb8fbb

As per #98 (comment)

cabo closed this Jun 16, 2021


		#### Semantics
		The Argument — the root JSON value – is anonymous by nature. By getting assigned the universal name `'$'` it becomes the root node.

		The behaviour of an implementation is undefined for member names which do
		not encode Unicode characters.

		quoted-member-name = %x22 *double-quoted %x22 / ; "string"
		%x27 *single-quoted %x27 ; 'string'


		If the result is `true`, the current item, represented by `'@'`, is selected. In case of a `false` result, it is not.

		~~~~ abnf

Selectors reworked ... #98

Selectors reworked ... #98

Conversation

goessner commented Jun 10, 2021

glyn 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

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

cabo commented Jun 11, 2021

goessner commented Jun 11, 2021 via email

cabo commented Jun 11, 2021

cabo commented Jun 11, 2021

gregsdennis 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

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

Choose a reason for hiding this comment

goessner Jun 14, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

goessner Jun 15, 2021 • edited Loading

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

glyn commented Jun 14, 2021

goessner commented Jun 14, 2021 via email

cabo commented Jun 14, 2021

cabo commented Jun 14, 2021

goessner Jun 14, 2021 •

edited

Loading

goessner Jun 15, 2021 •

edited

Loading