Time: 9:00 - 11:00 UTC
Chair: Tim Bray
Chair: James Gruessing
Area Director: Francesca Palombini
Glyn: Nodelist passed as individual nodes to the selector
Stefan: Beyond slide 5:
* existence test
Stefan: Good to restrict the RHS of comparisons to simple [primitive] values
(We think Greg has been pushing for structured values in comparison)
Meeting consensus seems to be to stick with primitive values for comparisons
cabo: path-to-path comparison
Stefan: first reaction: disallow this
Glyn: Proposal A avoid multiple nodes by limiting the path on the $ side as well, only where they will yield a definite value
Tim: syntactic restriction?
Glyn: single value may be an array, but is not multiple nodes...
Glyn: single value may be structured
Meeting consensus appears to be to limit comp-expr to the equivalent of https://github.com/cburgmer/json-path-comparison/blob/master/proposals/Proposal_A/selector.peg
Stefan: (1) But then there is the in-op
(2) allow existence test -- structured value does exist...
cabo: not spelled out -- only confusingly as "falsy" and "truthy"
See issues #120 and #122
11 of 4x implementations do that "right"
Function proposal ("exist()")?
Carsten: stick with exist-expr... use that for existence testing
Use comp-expr to find out whether an existing value is 17, "a", false, null, or true. (A non-existing value is not equal to any literal.
@.doesnotexist != 17 is true, as is
@.doesnotexist != false.)
@.doesnotexist != @.alsodoesnotexist, note that undefined is not equal to undefined in language X
$.foo == $.bar, user might expext that to be true if both members are missing.
$.foo && $.foo == $.bar could be used for the inverse case.
$.foo == $.bar || !$.foo && !$.bar would be needed otherwise.
> NaN == NaN false > NaN != NaN true > NaN < NaN false > NaN <= NaN false > NaN > NaN false > NaN >= NaN false
$.foo in \
is always false, as is
for any x
-> add examples to 188.8.131.52 (filter selector)
Tim: leave RE out, as trying to make this consistent will make people unhappy.
James: RE could be for extensions in the future.
Implementation: transform this common subset into the RE language at hand (surprisingly easy)
Glyn: One standard spawning another activity; actually quite general not limited to jsonpath
Tim: Once we allow regexp, we have to say what we mean.
Stefan: like to export the RE syntax to another specification
Stefan: What would be an extension point?
Carsten: Provide a well-defined place where extensions can be plugged in
Glyn: E.g., there could be a JSONPath over RE2?
Carsten: Separate issue: Policy for granting extensions
Tim: SGML declaration, had dozens of optional features, nightmare
Tim: Statement I'd like to be able to make: Any (conforming) JSONPath can be processed by any (conforming) JSONPath implementation
Emerging Consensus: If we allow regular expressions, we need to say exactly what they mean.
(A) No RE.
(B) Full spec of RE included.
James: There may be need for Extension Points for other things than RE.
James: Implementers may want to offer a different RE definition...
(Can't define common subset, but also need transformation...)
Tim: UTF-8 characters in RE should always work, classes more interesting
Consensus on options A or B above.
(X) Develop ideas about what could be viable extension point mechanisms
(Y) Examine iregexp
List of issues to discuss to be finalised later
Do schedule a 112 meeting
Not enough time.