►
From YouTube: IETF-JSONPATH-20220118-1000
Description
JSONPATH meeting session at IETF
2022/01/18 1000
https://datatracker.ietf.org/meeting//proceedings/
A
B
B
D
So
sorry
about
that.
I
got
to
do
my
usual
boilerplate,
so
let
me
just
crack
on
with
it.
This
is
an
official
ietf
meeting.
So
please
know
well
the
usual
times
all
right.
You,
you
guys
are
familiar
with
this,
but
I
have
to
say
it
just
the
australia.
Are
we
gonna
do
what
we
usually
do,
which
is
try
to
take
links
as
best
as
we
can
and
I'll
edit
them
afterwards
and
send
them.
D
Okay,
I
can
do
that-
and
I
can
make
some
time
later
in
the
week
to
edit
them
up
once
available,
because
this
is
such
a
last
minute
booking
I'll,
try
to
make
sure
that
the
body
is
available
if
there,
if
it
isn't
I'll
chase
me,
don't
go
about
that
blue
sheets.
We
don't
have
to
do
because
this
is
a
meat
echo
thing
jabba
scribe.
D
E
D
E
So
yeah,
I
think
you
know
which
day
it
is.
I
mean
quickly
summarize
the
status.
Yesterday
morning
we
had
37
open
issues.
Yesterday
evening
we
had
12
open
issues,
and
this
is
because
I
closed
25
of
them,
so
some
of
them
had
long
been
marked.
As
can
we
close
this
now
or
something
like
that
and
some
well,
I
tried
to
summarize
them
for,
for
this
slide
set
and
it
turned
out.
We
had
kind
of
done
them
or
they
were
about
a
part
of
jsonpath.
E
So
I
marked
those
with
with
another
tag
which
was
like
revisit
afterbase
or
something
like
that.
But
anyway
I
closed
25
because
they
are
not
relevant
to
the
current
state
of
the
document.
So
there
are
now
12
open
issues
and
some
of
them
are
marked
tasks,
and
these
just
need
to
be
done.
I
mean
somebody
has
to
check
all
the
the
abnf
and
and
all
that,
so
we
probably
don't
have
to
discuss
it.
E
E
B
E
E
It
means
that
we,
we
have
a
much
more
manageable
set
of
items
before
us
and,
of
course
it
doesn't
mean
that
we
won't
come
up
with
new
issues
or
that
that
we
maybe
even
will
find
things
in
the
issues.
I
close
that
that
do
need
to
be
done,
but
I
think
in
general
the
cash
is
a
little
bit
more
manageable.
G
Question
my
personal
feelings
on
closing
the
issues
is
that
we
shouldn't
if
they
are
not
done.
I
recognize
that
these
are
these
issues.
Many
of
these
issues
are
not
done
because
we
are
explicitly
not
including
them
in
what
you're
calling
the
base
document
or
the
the
I
guess,
the
first
draft
of
or
whatever
this
is,
and
I
I
just
feel
that
the
the
issues
should
remain
open,
put
the
label
on
them
sure,
but
if
they're
not
done,
I
believe
the
issue
should
stay
open.
E
G
E
E
G
G
G
E
I
E
G
G
G
G
E
So
absent
equals
absent.
That
was
one
of
the
the
items
where
we
ended
the
last
discussion
with
discuss
this
on
the
list.
Unfortunately,
not
much
discussion
has
happened
on
the
list,
so
the
question
is:
when
we
compare
empty
node
lists
in
comparison.
Are
these
equal?
Are
these
not
equal?
So
do
we
do
something
that
we
can
imagine
as
converting
them
to
undefined,
or
do
we
something
that
we
can
imagine
as
converting
them
to
not
a
and
yeah?
C
Paths
in
there,
so
I
think
this
I
think
this
issue
is
reasonably
well
understood.
We
understand
what
we're
disagreeing
about
here
and
I
might
you
know
last
time
we
discussed
this
some
of
us
some
of
us
thought.
Well,
obviously,
it's
like
not
a
number,
and
some
of
us
thought.
Obviously
it's
like
absent,
and
so
the
idea
was
we
get
some
use
cases
and
help
us
help
and
see.
If
that
changed
anybody's
point
of
view,.
E
C
G
B
E
G
B
B
G
E
E
C
C
Say
two
things.
First
of
all,
just
to
me
it
seems
crazy
if
I
write
a
test
saying
you
know
if
a
equals
b
and
there
isn't
an
a
and
there
isn't
a
b
and
it
comes
back
saying
equal.
You
know
that
that
just
seems
deeply
wrong
to
me.
Having
said
that,
I've
I've
never
actually
done
anything
like
this
or
felt
the
need
to
do
anything
like
this
or
encountered
a
situation.
So
I
shouldn't
put
too
much
weight
on
my
own
opinion.
B
C
G
B
E
So
most
use
cases
that
really
can
use
the
the
first
line
of
one
are
cases
in
which
properties
of
an
object
default,
and
so
you
essentially
don't
have
it
if
it
has
its
default
value.
So
if
you
compare
to
two
objects
with
respect
to
this
value,
both
will
be
undefined
and
they
will
compare
the
same,
which
is
exactly
what
what's
right,
but
again,
there
are
tons
of
other
cases,
but
the
the
absence
means
default
case
is
actually
covered
nicely
by
one.
G
C
G
I
E
D
C
C
C
C
B
E
E
The
the
first
question
that
came
up
was:
do
we
want
to
have
the
parsing
flavor
of
regular
expressions
that
that
originally
came
from
the
ed
editor,
where
regular
expressions
were
used
for
searching
on
a
line
or
do
we
want
to
use
matching
regular
expressions?
And
it
seems
to
me
that
the
prominent
example
for
parsing
regular
expression
is
ecmascript
and
a
prominent
example
for
a
matching.
Regular
expression
is
w3c
xsd,
regular
expression.
E
E
G
E
G
G
B
C
C
This
document
is
that
if
somebody
builds
a
json
path
according
strictly
to
this
document,
they
have
a
maximum
hope
of
interoperability
and
and
for
all
of
those
reasons.
My
path
forward
at
this
point
preferred
would
be
to
to
to
develop
the
irex
document.
We
should
clearly
do
it
separately
because
other
people
will
probably
use
it
and
and
when
we
are
discussing
things
in
iregas,
we
should
have
a
prejudice
to
throw
it
out
if,
if
it's
difficult
or
complex
or
is
apt
to
be
a
source
of
interoperability
problems.
C
E
D
E
G
B
C
That's
fair,
you
know,
I'm
I've
been
in
this
seat.
I
have
a
strong
so
back
about
three
or
four
years
ago
now
we
were
building
a
product
called
step
functions
over
at
aws,
which
has
become
quite
popular
and
familiar.
We
didn't
think
about
this.
You
know
we
just
said:
oh
we'll
use,
jsonpath
right
and,
and
then
it
turns
out
that
it
just
depends.
C
C
C
I
I
I
like
keeping
it
separate,
but
my
main
concern
is:
will
we
get
the
right
constituency
of
people
interested?
You
know
if
we,
as
jason
path
working
group,
start
this
red
xp
thing?
Will
it
emit
certain
other
interesting
parties?
You
know
how
do
we,
how
do
we
socialize
it?
How
do
we
draw
people
in
who
would
have
a
good
input
to
it.
D
A
G
Yeah
you
have
to
reference
the
rfc
in
in
the
jsonpath
dock.
I
would
probably
be
willing
to
say
that
the
the
jason
schema
folks
would
be
willing
to
also
or
would
be
happy
to
also
include
such
a
document
into
jason's
schema.
We've
been
having
some
discussions
on
what
specific
versions
of
of
regex.
We
should
be
supporting
with
the
upcoming
drafts,
because
what
we're
using
is
quite
old.
C
D
C
E
E
Then,
if,
if
we
actually
go
for
a
separate
document,
then
right
now
we
have
a
hole
and
we
could
fill
this
hole
by
writing
a
new
document
or
we
could
fill
this
whole
by
adopting
an
existing
document
as
a
working
group
document.
Obviously
I
have
a
slight
preference
here,
but
that's
procedurally,
that's
the
decision
we
have
to
make
at
some
point
then.
C
I
I
I
E
C
E
C
E
C
I
absolutely
agree,
I
don't
think
I
think
it's
totally
unacceptable
for
the
iatf
to
do
anything
that
is
ascii
limited.
I
would.
I
would
hope
that
the
iasg
would
would
kick,
which
is
such
a
draft,
I'm
a
little
bit
out
of
touch
with
what
the
implementations
do
do
they
have
good
general
coverage
of
like
the
unicode
character
classes
and
so
on.
E
C
E
Well,
the
the
only
two
the
current
draft
is
very
explicit
for
with
respect
to
what
you
can
put
in
a
back
hp,
and
I
think
that,
what's
in
there
is,
is
universally
supported
by
backslash
p
implementations
because
as
an
implementer,
essentially
at
some
point,
you
have
to
decide.
Oh,
oh,
my
god,
I
have
to
pull
in
the
unicode
character
table
and
once
you
have
that
character
table
it's
kind
of
trivial
to
do
all
the
things.
C
C
C
E
Okay,
so
this
has
been
said
a
few
times,
we
need
those
examples
and
there
is
an
open
issue
for
that
labeled
as
task-
and
this
is
just
a
reminder
that,
yes,
we
should
make
that
appendix
and
it
would
really
be
great
if
people
were
contributing
examples
we
can
put
in
there.
We
still
need
to
find
a
structure
for
that
appendix
so
I'm
not
necessarily
suggesting
that
you
put
them
in
as
a
pull
request,
but
sending
a
simple
message
to
the
mailing
list.
E
C
B
G
G
E
C
Yeah,
I
think
I'd
like
to
just
emphasize
this.
That
would
really
appeal
to
working
group
members
to
put
a
little
bit
of
work
into
this.
Go
find
some
things
that,
because,
for
two
reasons,
first
of
all,
I
believe
strongly
that
the
value
of
a
spec
is
is
greatly
increased
by
having
good
examples
in
it,
and,
secondly,
doing
this
often
reveals
disagreements
where
we
thought
we
had
agreement.
G
G
C
E
Along
yeah,
speaking
of
json
pointer,
we
still
have
to
do
in
the
document
right
there
that
we
need
to
explain
what
the
difference
from
jsonpointer
is.
This
again
is
something
that
just
needs
to
be
done,
and
this
is
just
a
reminder
that
that
we
need
to
do
that.
I'm
not
aware
of
anything
controversial
about
that,
but
maybe,
after
writing
the
text
I
will
be.
G
I
C
E
G
C
C
E
C
C
G
D
6901
seems
to
bring
reference
to
null
character,
unico
characters
and
that
implementer
should
handle
those
and
trying
to
summarize
the
other,
the
top
one
in
691,
basically
saying
that
dead,
end
pointers
and
the
implementers
should
anticipate
those.
But
I
think
that
we've
largely
covered
both
of
those
points
already
correct.
D
C
G
C
Well,
I
noticed
that
in
in
json
itself
in
8259-
and
this
has
always
been
true
way
back
to
the
very
first
specification.
It's
always
said
that
implementations
may
impose
limits
on
sizes
and
number
ranges,
and-
and
things
like
that-
and
you
know,
as
greg
said,
you
know,
deeply
nested
queries
or
something
like
that.
It
was
perfectly
reasonable
for
implementations
to
defend
themselves.
G
One
to
look
at
would
be
graphql.
They
have
very
because
you
can
very
easily
do
loops
referential
loops
in
graphql
and
make
absurdly
long
queries
that
are
perfectly
valid.
So
what
they've
done
is
in
the
spec
they've
actually
said
that
implementations
need
to
support
like
a
max
depth
and
they
have
various
calculations
and
stuff
for
that.
But
their
security
considerations
are
fairly
robust
and
might
be
some
reference
material.
C
D
C
C
C
I
F
C
Once
you've
accepted
the
jsonpath
as
being
syntactically,
okay,
that's
a
really
good
point
glenn,
because
we
should,
in
fact,
if
we
are
going
to
allow
implementations,
to
express
these
kind
of
limits,
we
could
say
that
they
can
only
express
limits
that
can
be
detected
at
compile
time.
Basically,
so.
C
C
E
C
G
If
I'm
processing
that
object
once
I've
processed
that
value,
I
shouldn't
have
to
process
that
value
again.
I
can
handle
that
internally
in
my
implementation,
by
saying:
oh,
here's
a
here's,
the
hash
for
that
object,
and
I
don't
have
to
I
don't-
have
to
process
that
object
again.
I
just
go
fetch
its
results
and
insert
it
in
in
here.
If
we
want
duplication
or
if
we
want
to
filter
out
the
duplicates,
then
I
can
know
to
do
that,
but.
H
G
I
mean
it
depends,
do
they
want,
you
know
what
do
they
want?
Do
they
just
want
the
values
in
which
case,
or
do
they
just
want
the
resulting
values,
in
which
case
duplicates
don't
really
help
them?
Do
they
want
the
duplic?
Do
they
want
nodes,
in
which
case
duplicate
nodes,
don't
help
them,
but
duplicate
values
could
or
do
they
want,
like
the
raw
selection
set
of
of
the
query
which
do
showing
the
duplicates
would
give.
E
B
B
B
C
C
I
G
A
G
I
I
think
the
optimization
you
suggested
greg
of
having
a
kind
of
memento
pattern
and
and
saying
I've
already
computed
the
answer
to
this
I'll
reuse.
The
result
it's
perfect
because
it's
it
conforms
to
the
the
spec
without
complicating
the
spec,
and
it
gives
the
kind
of
performance
that
maybe
your
users
are
looking
for.
It's
internal.
C
G
C
D
B
C
C
G
B
C
E
B
G
D
G
C
C
B
C
C
E
C
B
G
E
G
G
D
G
G
E
G
G
C
E
G
F
E
Yeah,
the
the
disadvantage
of
of
the
current
selected
terminology
is
that
the
thing
that
is
in
front
of
the
term
selector
sometimes
describes
the
result
and
sometimes
describes
the
form
of
the
selector.
So
a
filter
selector
doesn't
give
you
a
filter
at
the
end,
it
gives
you
it
employs
a
filter
and
similarly
a
list
selector
doesn't
give
you
a
list.
Well,
it
actually
does,
but
this
is
not
the
one
that
the
selector
is
about.
It
employs
a
list
to
to
create
the
selector.
E
C
B
E
C
E
E
So
my
timeline-
I
I
didn't-
I
usually
use
a
rose
colored
slide
for
timelines
because
I
need
to
wear
my
rose
colored
glasses
to
to
do
timelines.
My
timeline
would
be
that
we
get
this
written
up
within
about
three
weeks
and
then
we
have
a
document
where
we
do
the
sanity
checks.
Maybe
we
need
to
re-spin
this
once
more,
but
we
should
do
the
wrecking
blocks
call
within
february
and
and
preferably
early
february,.
C
C
I
C
E
D
C
D
D
D
D
F
C
You
know
the
ihf
is
our
hosting
organization
and
when
you
sign
up
to
do
a
working
group,
there's
sort
of
an
implicit
commitment
to
give
people
who
are
attending
iitf
a
chance
to
wander
in
and
hear
what's
going
on
so
so
now
we
had
the
unfortunate
experience
of
the
where
we
tried
to
do
one
and
it
was
on
north
american
time
and
basically
nobody
showed
up.
But
this
is
going
to
be
on
european
time.
E
Yeah
there
are
working
groups
that
never
go
to
itf
meetings
and
that
only
do
interims
like
the
seller
working
group.
So
this
is
this
is
not
unheard
of.
The
advantage
of
going
to
an
itf
meeting
is
that
it
might
be
easier
to
get
other
people
pulled
in,
but
also
there
might
be
a
conflict
in
this
slot,
but
which
makes
it
much
harder
to
pull
other
people
in
and
the
the
advantage
of
going
outside.