►
From YouTube: IETF-JSONPATH-20210615-0900
Description
JSONPATH interim meeting
2021/06/15 0900
C
C
B
C
E
C
C
F
C
C
B
G
G
G
A
G
B
Yeah,
marco,
that's
right,
we
marco,
has
has
resigned
his
editorship
now,
as
we
know.
In
fact,
all
the
editorial
work
has
been
done
by
carsten
and
glenn,
and
stefan
we
thank
them.
For
that.
That's
great.
We
really
appreciate
the
support
james
and
I
haven't
had
a
chance
to
talk
this
over
yet
we'll
figure
it
out,
but
but
marco
will
no
longer
be
with
us
in
that
capacity.
B
A
H
B
B
A
I
C
A
E
A
Finish
the
current
full
request,
because
that
already
has
pushed
us
aside,
everything
else.
So
we
can
finish
that
now
and
and
I'm
dreaming
that
we
can
merge
it
today,
so
we
can
then
start
creating
little
pull
requests
on
specific
issues,
because
I'm
already
dying
to
to
make
a
few
of
those.
But
I'm
not
going
to
muddy
the
water
further
by
by
doing
this
right
now.
So.
J
A
I
think
I
I
have
covered
everything
that
came
in
until
eight
time,
but
yeah.
There
are
lots
of
comments
in
there
that
really
need
to
lead
to
further
pull
requests.
So
we
cannot
simply
take
these
off.
All
three
98
99
and
102
have
comments
that
we
still
have
to
act
on,
but
that's
just
not
productive
to
try
to
tweak
the
the
big
per
request
we
we
have
to
act
on
these
things
in
small
pull
requests.
A
Yeah,
that's
good,
okay,
yeah!
So
let's
talk
about
the
the
one
thing
that's
remaining
of
97
and
the
that's
the
the
definition
of
of
the
term
string,
and
I
think
the
the
underlying
problem
is
that
we
are
basing
our
terminology
on
that
of
82
59,
which
really
has
been
written
to
define
what
adjacent
text
is
so
it's.
A
A
So
it's
important
to
keep
in
our
mind
whether
we
are
talking
about
a
literal
or
we
are
talking
about
the
the
number.
That
is
the
data
behind
that
literal
and
that
becomes
important
now,
because
we
we
are
defining
string
literals
that
actually
are
different
from
those
of
json
all
other
literals.
It
seems
I
don't
know
if
that's
actually
true,
but
to
me
it
seems
all
other
literals.
J
Good,
the
the
discussion
that
we
had
last
time
was
that
we
wanted
to
use
values
and
that's
what
this
pr
does.
This
part
pr
uses
the
term
values
we
never
considered
using
the
word
literals
any
time
with
until
you
brought
it
up
like
a
few
days
ago,
and
no
discussion
has
been
around
the
word
literal
until
you
brought
it
up,
and
so
my
question
is:
can
we
take
the
pr
as
it
is
for
what
we
discussed
and
then
use
another
pr
to
change
it
for
these
literals.
B
A
So,
that's
why
I
think
we
really
have
to
to
separate
these
two
aspects.
Clearly,
I
think
so
far
it
didn't
really
matter,
but
as
soon
as
we
actually
have
specific
literal
syntax
in
jsonpath
that
that
differs
from
the
one
we
import
from
h259.
We
have
to
be
careful
here
and
I'm
not
not
wedded
to
the
term
literal.
That
has
just
been
the
the
term
that
has
been
used
for
for
the
last
45
years
or
so,
but
we
can
also
say
notation
or
something
else.
J
J
J
J
J
B
J
So
it
sounds
like
for
the
purposes
of
expressions
we
want
to
make
a
distinction
between
how
it's
represented,
which
is
the
literal
and
the
value
behind
it,
which
is
what's
actually
going
to
be
used
in
the
expressions
and
maybe
that
can
be
extended
to
indexes,
for
example,
where
we
use
the
square
brackets
with
a
quotation
or
with
a
string.
Literal
quotations
as
well.
A
A
A
J
A
J
A
So
we
can
import
that,
like
we
import,
number
and
array
and
object
and
then
of
course,
at
some
point
in
the
text,
there's
a
b
and
f
for
how
we
actually
notate
strings,
and
I
I
also
have
a
suggestion
how
to
change
that.
But
that's
not
the
subject
right
now,
but
I
think
we
can
simply
lose
this
particular
pull
request.
B
C
A
Yeah
again,
let's
merge
one
or
two
first,
but
I
think
one
of
the
next
projects
will
be
separating
separating
out
the
expression
language
from
the
way
it
is
used
in
in
the
various
selectors
and
part
of
that,
of
course,
will
be
defining
the
literal
aspect
of
the
expression,
language,
okay,
so
there's
lots
of
other
syntax.
That
needs
to
be
defined,
and
we
can
define
this
the
literal
syntax
with
that,
so
that
the
selectors
can
really
focus
on
on
just
saying
how
you
line
up
the
selectors
and
and
what
the
individual
kinds
of
selectors
actually
mean.
A
But
again,
this
is
about
the
definition
section:
it's
not
about
the
the
sections
that
actually
specify
things.
It's
just
the
definition
and
again
my
my
proposal
is
to
import
string
with
the
other
8259
terms
and
do
not
do
what
this
pull
request.
But
the
remaining
parts
of
this
pull
request
are
proposing.
I
mean
tons
of
stuff
has
been
merged,
so
we're
mostly
done
with
this
pull
request,
but
that's
the
one
thing
that
couldn't
be.
J
J
A
J
A
J
A
J
J
A
B
C
A
I
haven't
checked
everything
else,
so
I
think
we
at
some
point.
We
need
to
actually
look
at
implementations,
for
instance,
if
there
is
a
backslash
eggs
in
in
a
string
literal,
what
two
implementations
do
there,
so
the
the
the
ecmascript
string
literals
are
even
more
permissive,
so
they
would
actually
have
a
definition
of
what
the
backslash
x
means.
Why
jason
simply
rejects
the
the
backslash
x
because
it's
not
defined,
and
we
have
to
find
our
position
on
that
continuum.
B
J
B
C
C
A
A
To
have
this
this
discussion
here,
but
I
think
we
need
to
actually
attack
it
from
different
angles.
So
with
that,
let's
talk
about
98,
which
is
stefan's
giant
pr
and
that
actually
comes
in
three
flavors
98
99,
which
was
a
fix
so
that
it
actually
builds
and
then
102,
which
is
a
rebase
on
the
the
101
which
came
out
of
97..
A
A
So
that's
something
I'm
raising
the
issues
I
have
slides
for
for
the
individual
issues
later
and
the
the
third
one
was.
Can
we
actually
juggle
with
structured
values
so
that
the
term
that
8259
uses
for
containers
is
structured
values
and
the
term
it
uses
for
the
atomic
values
is
primitive
values?
And
again
I
would
propose
to
using
the
8259
terms,
even
if
I'm
not,
I
wouldn't
have
chosen
them,
but
that's
what
they
have.
What
we
have
structured
values.
E
E
B
A
A
We
have
to
be
very
specific.
What
what
we
mean
by
this
so,
for
instance,
comparison.
If
anybody
here
thinks
that
comparison
is
simple,
think
about
unicode
normalization.
Think
about
floating
point
comparison.
There's
lots
of
booby
traps
there
already
so
arithmetic
kind
of
seems
like
a
slam
dunk
compared
to
that,
but
I
think
we
can
keep
that
open.
Maybe
that's
not
something
we
have
to
define
right
now,
but
of
course,
where
we
have
examples
that
already
use,
arithmetic
or
or
structured
values,
and
so
on.
A
C
My
question
about
some
of
these
features
is:
do
they
pull
their
ways?
You
know
I
can
see
that
they
have
use
cases
and
we
can
invent
use
cases
if
we
want
to,
but
are
they
really
generally
useful
compared
to
the
amount
of
complexity
that
they
introduce
both
for
the
implementer
and
for
the
user?
You
know
the
reader
of
the
the
spec.
B
B
C
B
A
It
has
taken
a
while
before
people
started
to
understand
that
so
so
originally
people
were
slapping
nfc
on
everything
whenever
they
had
a
data
value
in
the
hand
they
just
normalized
that
as
a
matter
of
course,
and
that
has
turned
out
to
be
the
wrong
way
of
doing
it.
So
the
only
place
where
you
actually
want
to
have
normalization
around
is
in
comparison.
E
Okay,
it
was
not
my
intention
to
say
that
comparison
is
easy
and
then
arithmetic
is
is
complex,
but
jsonpath
is
for
selecting
things
out
of
the
json
text,
and
and
for
this
you
need
comparison
for
the
first
place.
You
ask
for
a
special
path,
and
maybe
you
can
compare
a
value
with
a
given
value
for
selecting,
and
this
is
what
we
need
for
filters
just
comparison
on
the
first
place
in
the
first.
J
J
H
E
A
The
idea
behind
an
extension
point
is
that
when
you
pass
a
json
path
expression,
you
can
find
out
whether
an
extension
point
has
been
used
and
look
up
with
whether
your
implementation
supports
that
extension
point
and
then
then
apply
the
implementation.
So
it's
a
framework
in
which
extensions
can
be
put
in
without
destroying
the
the
rest
and
arithmetic,
of
course,
can
can
could
be
added
in
a
functional
notation.
A
Then
it
would
be
easy
to
just
make
the
whole
functional,
notation
and
extension
point
that
that's
actually
what
we
did
in
ctdl,
where
we
have
the
the
control
operator
concept
and-
and
so
we
made
it
a
functional
extension,
and
that
would
be
one
way
of
doing
it.
I'm
not
saying
that.
I
prefer
that
or
I
dislike
that,
but
that's
certainly
one
approach.
B
E
B
E
E
E
B
E
At
dot
key
has
the
value
false
the
boolean
value
false.
You
must
explicitly
have
a
way
to
test
it
for
false.
You
can
do
it
by
equal
equal
false,
but
you
can
also
use
the
negation
operator
and
there
is
a
table
that
complies
mostly
to
javascript
how
the
not
operator
works
with
strings.
Empty
string
is
false.
B
B
A
B
A
A
J
Yeah-
and
this
particular
operator
is
actually
quite
unique
from
say,
the
equality
operator
in
that
the
the
left
side
takes
a
single
value
and
the
right
side
contains
it.
It
must
be
a
container
or
an
array
yeah.
It
doesn't
make
sense
to
have
it
the
other
way
around,
whereas
equality,
a
equals
b,
then
b
equals
a.
J
G
B
We
have
two
paths
forward:
one
is
to
adopt
basically
the
whole
screen
full
of
stuff,
simply
because
that
allows
the
the
you
know
the
emerge
to
proceed,
and
we
get
a
you
know,
a
single
document
that
we
can
work
on.
The
other
is
to
drop
a
few
of
these
things.
Now
I
am
not
particularly
religious
on
either
path
forward.
E
A
E
J
A
Different
procedure
in
mind:
okay,
so
I
don't
think
we
always
have
to
work
below
the
water
line,
so
we
we
might
have
things
in
our
document
that,
where
we
don't
quite
know
how
it
works,
but
we
still
say
how
it
works
together
with
everything
else,
one
once
we
have
defined
how
it
works
and
if,
if
we
always
cut
away
everything
that
is
not
defined,
then
we
have
an
essentially
empty
document
most
of
the
time,
because
there's
always
one
detail
that
isn't
defined
yet.
Okay,.
C
G
G
B
A
E
E
C
Just
looking
at
the
logical
operators,
we
don't
seem
to
have
any
they've
got
syntax
wrong,
but
I
can't
see
a
way
of
grouping
together,
disjuncts
with
inside
brackets
or
maybe
defining.
Maybe
maybe
we
need
to
define
the
precedence
of
abandon
or
but
ignoring
that
for
the
moment,
if
you
want
to
have
explicit
brackets,
I
don't
think
there's
a
syntax
for
that.
C
C
A
A
C
B
A
A
B
J
A
Okay,
then
we
had
the
discussion
about
selecting
a
value
versus
selecting
a
node.
That's
one,
one
more
terminology
problem
that
we
haven't
fully
understood
yet,
and
the
the
text
currently
mostly
talks
about
selecting
a
value,
but
I
think
it
actually
should
be
saying
we
are
selecting
nodes
because
we
are
not
selecting
not
just
selecting
the
value.
We
are
also
selecting
the
position
in
the.
E
A
I
E
A
B
J
B
C
E
If
you
do
not
have
your
egg,
of
course,
you
can
apply
the
the
query
again,
but
you
cannot
tell
if
you
have
the
number
five
from
where
exactly
in
the
document
it
is.
But
if
you
have
the
the
path,
the
normalized
path,
you
can
do
it.
This
is
only
possible
using
nodes,
and
this
is
what
we
need
to
explain
carefully.
Yes,.
A
B
A
A
B
So
so
this
is
so
if
we,
if
we,
if
we
were
to
assert
that
a
dot
member
name
cannot
start
with
a
digit,
you
could
you're
stepping
on
a
slippery
slope.
You
could
say:
okay
well,
it
has
to
match
the
ecmascript
name,
production
which,
which
we
actually
did
in
in
an
implementation
where
we
were
sanity,
checking
json
scripts
jsonpass
before
we
applied
them
and
we
rejected
those
that
did
not
match
the
ecmascript
name,
production
which
actually
worked
pretty
well.
B
E
D
A
E
J
E
If
we,
if
we,
if
we
disallow
the
descendant
selector,
we
restrict
the
union
selector
on
one
level
of
object
or
array
level.
Is
this
correct,
so
the
wildcard
selects
all
so
the
wildcard
doesn't
need
to
be
inside
of
the
brackets
and
it
doesn't
need
to
be
combined
with
other
selectors
logically,
so
the
next
question
would
be.
Should
we
disallow
it
explicitly
for
this
logical
reason
or
keep
it
inside
for
stupid
users?
I
don't
know
from
yeah.
J
C
I
think
I
agree
with
what's
being
said.
I
think
the
only
reason
for
keeping
wildcard
in
there
is
for
uniformity
so
that
you
can
say
you
can
make
general
statements
about
unions
being
like
single
values.
If
you,
if
you
allow
square
brackets
with
a
wild
card
inside
then,
is
that
a
degenerative
degenerate
form
of
a
union
without
a
comma
yeah.
So
it's
a
uniformity
thing
for
me
yeah.
I
don't
feel
strong,
particularly.
C
C
E
C
E
E
J
I
I
A
C
E
J
E
J
J
I
E
E
A
H
A
J
C
A
C
J
I
feel
this
may
be
maybe
not
a
release
two,
but
like
an
enhancement
on
jason
path.
After
we
release,
it
could
be
something
like
that
kind
of
like
we
have
versions
of
c
sharp
or
versions
of
c
that
come
out
like
carson.
You
were
saying
that
c
eventually
stopped
requiring
those
in
a
later
version
of
the
language.
J
E
C
B
E
A
Actually,
I'm
not
sure
about
that.
I
I
haven't
sat
down
and
and
pushed
the
abn
f
into
a
puzzle
generator.
So
there
might
even
be
some
technical
benefits
and-
and
I
think
I
will
do
that
when,
when
things
have
stabilized
enough
for
for
that
to
be
a
worthwhile
exercise,
so
kirsten
do
you
mean
a
syntactical
benefit
of
of.
I
E
J
A
Okay,
we
have
13
minutes
and
three
more
slides.
So
let's
try
to
get
through
those
the
white
space
issue,
the
the
abn
f,
needs
to
tell
you
where
white
space
is
allowed
and
that's
yeah,
not
fun,
but
that's
a
feature
of
abn
f
abnf
is
not
a
two
level:
parser
scanner
combination.
It's
a
single
level
specification.
A
A
J
I
think
it
makes
sense
inside
operations,
flight
or
inside
operators
of
a
union
like
around
the
brackets
and
commas
and
stuff
like
that.
Just
to
kind
of
increase
readability
inside
expressions
around
operators
would
be
fine.
I
would
not
necess
well,
you
could
do
it
between
selectors,
possibly
one
person.
E
B
Is
the
general
feeling
that
that
they
should
be
allowed
where
it
doesn't
screw
up
the
grammar,
or
that
we
should
be
generous
with
white
space
or
stingy
with
white
space?
I
mean
generous.
There's
there's
no
doubt
that
once
things
get
complicated,
white
space
can
dramatically
improve
readability,
but
is
that
going
to
screw
up
any
other
aspects
of
expressions.
B
A
C
J
A
J
J
A
A
H
E
A
Well,
I
find
it
nice
if
I
can
write
test
cases
without
having
to
do
special
gymnastics
for
for
sorting
things
before
I
compare
them
so
right
now,
I'm
I'm
one
example
where
I'm
fighting
with
is:
when
python
puts
out
xml
it
randomly
puts
out
the
attributes
in
any
order.
That
depends
on
a
seed
that
that
is
fed
into
a
random
generator.
When
python
starts,
so
you
can
be
sure
that
you
run
it
twice,
it's
very
likely
that
they
will
be
different
and
that
really.
B
J
J
B
J
J
A
B
Yeah
but
then
then,
if
he
changes
the
the
underlying
server
all
his
tests
break,
if
he
hasn't
been
careful
about
doing
equals,
testing,
and
so
on
I
mean
I,
I
think
it
I
think
the
te
I
think
the
spec
needs
to
be
clear,
that
this
is
not
a
thing
that
is
part
of
the
just
the
jason
path
landscape.
You
know
it's
a
good
idea,
recommend
it
put
a
shirt
in,
but.
C
I
guess
another
comment
is
that
when
you're
actually
coding
the
implementation
of
the
descendant
selector,
you
have
to
make
a
decision,
it's
hard
to
see
how
you
would.
I
personally
don't
see
how
you
would
just
end
up
with
a
non-deterministic
implementation.
So
you
have
to
make
a
decision
and
it's
fairly
arbitrary.
So
you
can.