Original text:
A function expression is correctly typed if all the following are true: <del> If it occurs as a "filter-path" in an existence test, the function </del>  is defined to have result type "OptionalNodes" or one of its subtypes, or to have result type "OptionalBoolean" or one of its subtypes.

Reviewer comments:
Add the necessary internal references.
Currently, the existence test description contradicts the intended use of OptionalBoolean functions. We need to be careful if we want to make a special case for OptionalBoolean functions and not open the door to any boolean value being treated similarly.
2023-01-10 Interim: Fix text to properly handle OptionalBoolean. Make sure to indicate that an existence test from a path never gets to the actual value.
Can this issue be elaborated? What is OptionalBoolean? How does this apply to functions? Examples would be great.
Base 09 explains what OptionalBoolean is and uses it in the match and search functions. The current issue will also add some text to explain the way OptionalBoolean functions behave in filter expressions.
E.g.,
I propose a slightly more compact naming of ABNF of - and -segment, which should be more consistent between them two. is well known from LaTeX and means or there.
above is wrong (and so it is in the current spec). It needs to read ... to not allow triple dot ( :-)
NAME Wouldn't dotdot-wildcard etc. be less cryptic?
Here are some quibbles with the current ABNF (prior to PR being merged) which we can sort out after The Great Renaming:
Yes, yes. See. Fixed in I like the way this looks like now. Maybe I don't understand; can you elaborate? Fixed this (and following) in Removed in To be fixed in overall overhaul, next Yes! To be fixed in overall overhaul, next To be fixed in overall overhaul, next Fixed in Discuss this in its own issue, I'd say. Fixed in It certainly does not -- it is the subset that is actually needed for normalized paths. To stay normalized, we don't allow random other ones.
Of course ... I'm quite dispassionate here.
Please see my proposal in
With merged, we still have the expression cleanup the separate issue (enhancement) whether should be allowed, to mean
My remaining points are covered by PRs , , and .
Shouldn't be named according to all other above ?
Yes, I agree. See URL
NAME Are we ready to close this issue now the PRs have been merged or did you have more expression cleanup in mind?
The only thing that comes to my mind is standardizing on the column where the is -- this is currently rather chaotic. But that can be a new issue.
Indentation of : number of lines such indented
(And it doesn't need to be consistent, just a bit less chaotic.)
Let's make the a new issue. (I haven't got a good feel for the optimal solution.)
Before we close this issue, URL slipped through the net in my earlier PRs.
Then could resolve to either or . We would introduce an ambiguity, we already found with Json Pointer () ...
OK, with the latest blank space realignments that are part of (5e2cc85), I think we are done with this.
Ok, let's refactor the ABNF later. ... or do we need two selectors here (Ch.2.61) child-longhand = "[" S selector 1(S "," S selector) S "]" given that '1' means 'at least one'.

Revised text:
A function expression is correctly typed if all the following are true:  <ins> If it occurs as a "filter-path" in a test expression, the function </ins> is defined to have result type "OptionalNodes" or one of its subtypes, or to have result type "OptionalBoolean" or one of its subtypes.