►
From YouTube: IETF-JSONPATH-20220927-0800
Description
JSONPATH meeting session at IETF
2022/09/27 0800
https://datatracker.ietf.org/meeting//proceedings/
C
F
D
Cool
sorry,
good
morning,
good
evening,
good
afternoon,
this
is
the
Jason
path,
September
2022
interim,
because
this
is
an
official
iatf
meeting.
The
usual
disclaimer
of
sorry
I'm
having
a
room
but
I
have
not
had
my
second
coffee
yet
no
well.
So
all
the
all
the
usual
rules
and
stipulations
of
the
ietf
apply
to
this
meeting,
as
they
do
sort
of
a
lot
of
variety
of
meetings.
Please
vote
well
note.
Takers,
I'm,
terribly
sorry
that
I
haven't
got
around
to
note
taking
the
last
meeting
Glenn.
D
Thank
you
for
sending
the
action
points
over
immediately
after
I
was
on
Wells
and
find
a
big
chunk.
Blue
sheets
are
are
automatic.
We
don't
have
to
worry
about
that.
I'll
keep
an
eye
out
on
the
chat
in
case.
Anybody
else
shows
up
or
willing
to
do
it
through
that
in
terms
of
the
agenda,
I
see,
we've
put
a.
C
F
E
C
F
F
D
A
G
F
G
D
F
E
E
The
syntax
makes
it
much
easier
to
do
an
implementation
with
a
similar
syntax
input
to
a
parser
generator,
for
example,
and
that's
that's
all
in
place
in
the
pr
and
really
the
rest
is
about
the
way
the
semantics
are
described.
Clearly,
we
want
to
keep
the
semantics
the
same
overall
but
they're
a
different
options
for
describing
the
semantics
and
we've
looked
at
some
of
those
and
I've
got
something
on
the
agenda
to
discuss
that
again
and
also
the
the
naming
and
the
document
structure.
E
I,
don't
find
it
quite
as
readable
as
the
current
back
currently,
but
that's
my
personal
position
so
I,
you
know
Greg
and
I
are
both
looking
to
other
people
to
review
it
to
see
what
you
know,
what
other
perspectives
are
and
I've
requested
some
changes
to
actually
finalize
the
terms,
because
I
think
you
know
the
wheels
might
come
off
when
we
finalize
the
terms.
You
know
we'll
see.
F
Okay,
I
put
my
hand
up
and
let
me
say
a
couple
of
things
speaking
I
I
buy
and
so
early
on.
It
seemed
clear
to
me
that
nobody
wanted
to
change
the
semantics
of
Jason
path,
and
this
was
primarily
an
editorial
discussion,
a
large
one,
a
complicated
one,
but
but
primarily
editorial
and
so
I
I
decided
to
to
stand
back.
So
yesterday,
I
I
read
the
draft.
Thank
you
for
somebody,
whoever
it
was
that
formatted
a
copy,
so
that
I
could
do
that.
F
F
B
B
B
G
I'd
just
like
to
say
that
the
the
structure
was
the
important
thing
to
me.
As
far
as
naming
I'm
going
to
leave
that
to
everybody
else,
I
I
really
have
no
opinion
on
what
things
are
named
so
long
as
the
the
the
structure
of
the
things
are
somewhat
sensible
to
me
this.
The
way
this
is
structured
in
the
draft
that
I
put
together
makes
more
sense
than
the
the
current
document,
because
it
is
as
as
Stefan
said,
it's
adamite
it's.
C
A
Then
we
should
quickly
deal
with
the
shortcut
appenders,
which
are
just
syntactic
sugar,
on
the
two
bracketed
pandas,
the
child
and
The
Descendant
a
Pender,
and
we
shouldn't
even
try
to
to
use
a
common
name
for
starters
and
appenders,
because
they
are
really
different
things.
They
share
a
right
hand,
side
interface
and
outgoing
interface,
which
is
the
node
list
which
we
can
we
come
to
next.
But
this
frees
up
the
drum
selector
and
we
might
actually
want
to
use
the
term
selector
for
what's
called
picker
in.
In
my
preliminary
terminology,.
A
A
A
This
really
is
about
describing
interfaces
between
the
components,
the
components
that
leave
node
lists
and
the
components
that
pick
up
node
lists
are
a
singular
node
and
and
deliver
node
lists
and
how
these
node
lists
are
integrated
for
components
that
pick
up
a
node
list
and
return
a
node
list.
So
that's
number
three,
and
that
is
entirely
a
technical
issue,
but
I
think
one
where
we
mostly
have
consensus
and
just
have
to
make
sure
we
find
the
right
right
words
to
to
describe
the
consensus.
G
G
A
Are
less
important
for
for
our
process?
Then
then,
maybe
in
the
process
that
you
are
used
to
so
I
I
wouldn't
mind
mixing
this
stuff
up.
It's
a
little
bit
of
busy
work
to
to
do
a
technical,
only
PR
that
that
enables
the
the
white
card
picker
in
those
places
that
will
be
enabled
once
once
we
simplify
the
current
draft,
so
my
preference
would
be
to
do
it
in
1pl.
G
Yeah,
it's
simple
enough
for
me
to
take
the
take.
What
I
have
currently
and
just
take
the
two
I
guess:
it's
a
descendant
wild
card
and
the
Wild
Card
selector
and
then
move
those
I
guess,
combine
them
into
a
single
picker
and
put
that
up
in
the
bigger
section.
So
it
means
it's
trivial
for
me
to
do
that.
I.
Just
like
the
idea
of
the
the
current
document
and
in
this
PR
just
being
an
editorial
an
editorial
thing,
would
you
consider
this
still
an
editorial,
or
is
this
a
technical
change.
E
E
Secondly,
I
think
the
the
terminology
that's
been
proposed
is
good,
the
starter
and
the
Pender
and
I
think.
Possibly
we
could
go
for
selector
as
the
name
for
start.
Picker
I
think
that
works,
but
it
will
need
a
kind
of
editorial
pass
of
the
whole
document
after
that
to
make
sure
that
we're
not
using
I'm
not
misusing
the
term
selector.
Subsequently.
E
F
G
The
way
that
I
would
do
this
and
I
would
prefer
to
do
this
in
this
PR
I
would
I,
would
Define
starter
and
then
change
over
everywhere.
Selector
appears
to
appender,
so
that
selector
doesn't
appear
in
the
document
anymore.
I'd
commit
that
and
then
I
would
also
have
a
secondary
commit
of
changing
picker
to
selector.
B
C
F
F
E
I
think
we
still
have
actually
three
options.
It
turns
out
for
how
to
describe
the
semantics
of
Pickers
and
I'd
just
like
us
to
spend
five
minutes
on
this
call
looking
at
the
options
so
that
we
we're
sure
we're
going
in
the
right
direction.
You
know
I
think
it's
acceptable.
The
way
it
is
which
is
option
one
here
where
the
Picker
is
essentially
a
selector,
because
it
it's
given
a
value
and
it
selects
zero
or
more
children
of
that
value
and
returns
them
in
a
node
list.
E
E
Another
option
which
Greg
and
I
discussed
early
on
which
Greg
didn't
like
and
I
favored,
was
that
the
Picker
should
be
really
a
predicate
and
that
it
determines
whether
any
given
child
of
the
value
is
to
be
selected.
Then
the
selector
would
say
you
know
all
the
children
selected
by
the
Picker
are.
You
know
for
all
the
children
which
are,
of
course
the
Picker
is
true,
appear
in
the
node
list
in
the
order
blah
blah
blah.
E
You
know,
so
that
would
be
more
of
a
in
my
terms,
a
less
implementation,
bias,
kind
of
approach
and
it's
actually
got
a
narrower
interface,
because
the
pickers
then
don't
get
to
choose
the
order
of
the
node
list
and
they
can't
see
the
parents
of
the
children.
So
it's
much
a
much
tighter
description.
E
The
third
option,
which
I
you
know
we,
which
we
moved
away
from
fairly
early
on,
but
I,
think
we
need
to
just
revisit
so
we've
got
the
the
broad
set
of
options
is
to
not
actually
give
Pickers
semantics
on
their
own,
but
only
to
give
Pickers
semantics
in
the
context
of
a
selector,
so
essentially
to
say.
Each
picker
behaves
like
this
when
it's
in
the
child
selector
and
then
to
infer
the
semantics
of
a
child
selector
from
that.
E
E
B
B
Those
are
only
indicating
to
the
items
in
question
rather
than
actively
picking
which
is
selecting,
and
this
is
from
my
point
of
view,
the
discrepance
between
those
terms
are
they
can
you
exchange
them,
picking
the
Picker
and
selector,
and
this
is
the
current
discussion.
We
we,
we
change
the
meaning-
and
we
already
have
the
term
index
in
the
spec
index-
is
a
non-negative
integer
that
identifies
a
specific
element
in
an
array.
B
Note
that
the
term
indexing
is
also
used
for
accessing
elements
using
negative
integers
and
for
accessing
member
values
in
an
object
using
their
member
name.
This
is
read
from
our
spec,
so
we
already
relaxed
the
meaning
of
index,
and
so
why
not
think
further
and
relax
this
term
more
because
the
new
term,
a
single
item
within
a
bracketed
child
selector
that
matches
the
values
which
are
to
be
selected
so.
B
G
B
Changed
ticker
to
selector,
so
I
start
with.
The
second
object,
which
reads
now
and
index
is
a
predicate
which
determines
given
child
of
a
value.
A
child
selector
selects
those
children
of
its
input,
value
for
which
an
index
is
a
match.
I
I
changed
the
wording
somewhat
the
first
option:
a
selector
presents
a
single
value
to
an
index.
The
index
selects
zero
or
more
children
of
a
value,
and
the
resultant
note
list
is
used
in
constructing
the
selectors
note
list.
This
simply
makes
no
sense.
A
Yeah
I
think
what
Stefan
just
said
is
really
a
prime
demonstration.
Why
you
shouldn't
mix
up
discussion
of
terms
with
discussion
of
the
technical
Concepts
behind
that,
because
in
the
end,
we
we
have
to
get
the
technical
Concepts
right
and
we
will
find
terms
for
those.
So,
let's
stick
with
the
working
terms
for
now,
and
so
I
I
talked
about
the
appendix
and
and
Pickers
and
to
Glenn
the
fact
that
a
description
technique
is
also
directly
implementable,
does
not
make
it
less
desirable
as
a
description
technique.
A
E
E
A
We
can
we
can.
We
can
add
some
some
verbiage,
that
that
says
that
this
is
really
all
just
description
technique
and
there
are
better
ways
to
to
implement
this,
but
I
think
that
doesn't
have
to
stop
at
us
using
a
really
useful,
really
highly
understandable
description
technique,
just
because
it
also
could
be
used
by
an
implementation.
E
C
A
E
G
E
A
And
the
the
answer
in
my
option
of
whatever
its
number
is,
is
that
an
appendile
presents
one
node
for
the
child,
a
panda
and
a
tree
of
nodes
for
The
Descendants
appendo,
which
are
not
the
child
and
not
The
Descendants,
which
is
why
the
term
is
a
little
bit
confusing.
But
again
we
are
going
to
get
to
terms
later
and
then
it's
the
job
of
the
Picker.
To
actually
take
that
note
apart-
and
there
are
several
good
reasons
and
the
main
reason
to
do
it.
A
C
G
G
G
Secondly,
Carson
kind
of
touched
on
this
as
well.
If
I
have
an
array
of
a
thousand
items
with
just
an
index,
picker
of
three,
then
I
want
the
fourth
item.
I,
don't
need
to
I,
don't
need
the
appender
to
present
all
1000
items
to
the
the
index
picker
of
three
in
order
to
just
get
the
fourth
item.
If
you
pre,
if
the
appender
instead
presents
the
parent
to
the
index
picker
the
index
picker
says:
oh
there's.
The
fourth
item.
I'll
give
give
that
back.
C
E
G
F
So
since,
since
this
is
the
point,
I
wanted
to
address,
I'll
butt
in
so
I
disagree
strongly.
I
think
that
the
most
single
most
important
thing
about
the
language
in
the
spec
is
that
it'd
be
clear
about
the
semantics.
The
result
to
be
achieved
if,
if
the
best
way
to
achieve
that,
Clarity
is
to
describe
an
inefficient
implementation,
I'm
totally.
Okay,
with
that,
what
my
original
reason
for
putting
up
my
hand,
was
to
to
Echo
what
Carson
said
a
couple
of
seconds
ago,
which
is
it's
perfectly
okay
to
use?
F
You
know
an
iterative
pseudocodish
description
of
how
it's
done
to
establish
semantics.
That's
not
that's!
Not
radical
or
new,
however,
I
think
if
you
do
that,
it's
absolutely
necessary
to
have
language
saying
that
you
know
this.
This
algorithm
is
provided
only
for
explanatory
Clarity
and
there
is
no
requirement
whatsoever
that
it
actually
be
used,
which,
which
means
it's
perfectly
okay,
to
do
that.
As
long
as
you
give
that
language,
sorry,
that's
all
Kirsten.
G
A
Difference
between
the
two
approaches
is
essentially
where,
in
in
the
abstract
definition,
We,
Run,
The,
enumerator
and
running
the
enumerator
in
the
appenda
means
that
we
have
to
to
supply
everything
the
the
enumerator
find
to
the
the
pickup.
So
the
the
Picker
interface
is
not
a
nodeless
based
interface,
but
it's
an
interface
that
Associates
the
nodes
with
attributes
such
as
array
index
and
and
member
name,
so
that
that
makes
things
slightly
more
complicated
for
me
because
and
I
no
longer
can
think
in
terms
of
notice.
E
A
C
G
E
G
A
C
A
That's
fair
enough,
thank
you
so
my
view,
but
my
current
mental
image
of
option.
One
means
that
descendants
append
a
presents
the
current
node,
as
well
as
all
structured
descendant
nodes
to
the
Picker
individually,
so
the
Picker
doesn't
get
to
to
operate
on
the
relationship
between
the
descendant
notes,
so
that
that
would
essentially
be
very,
very
simple.
E
That's
that's
true,
but
I
think
the
the
way
the
spec
is
currently
structured
and
the
way
the
pr
is
structured
means
that
the
descendant
selectors
are
actually
defined
in
terms
of
the
child
selector.
So
essentially
we
we
enumerate
a
list
of
descendants
and
then
we
run
the
child
selector
against
each
one.
So
it's
a
kind
of
it
doesn't
really
matter.
You
know,
because
we
end
up
with
the
semantics
of
the
child,
selector
really
driving
things.
E
B
B
B
Yes,
I
prefer
number
two
I
prefer
number
two
in
here
in
your
comment,
which
is
shown
here.
Yes,
definitely
definitely
number
two
I
I'm
I.
It's
very
unusual
for
me
to
to
see
a
picker
as
an
actively
working
acting
element
or
a
function
or
an
algorithm
which
selects
parts
of
a
node
list
or
a
note
list
except
the
filter
picker.
The
filter
picker
in
fact,
has.
B
G
I
would
I
would
agree
with
the
the
idea
that
it's
a
a
passive
like
the
a
member
name
on
its
own
is
passive,
but
I
wouldn't
necessarily
apply
that
passivity
to
all
of
the
pickers.
For
instance,
the
the
filter
picture
is
actually
a
delegate.
It
is
actually
iterating
through
all
the
children
and
and
identifying
which
ones
are
selected.
E
C
E
A
G
G
E
Yeah
so
I
raised
this
issue
kind
of
separately
from
the
current
descript
discussion.
You
know
the
pr
discussion,
because
I
noticed
that
our
current
spec
current
rap
was
overly
deterministic
such
that
it
would
even
exclude
some
existing
implementations,
so
I
thought
we
needed
to
loosen
it
up
a
bit.
Add
more
non-determinism.
A
C
G
A
No,
the
the
there
is
no
problem
with
the
object
members
here.
It's
just
that
the
the
the
yeah
that
it's
just
that
this
is
a
breadth
first
result
and
I
just
wanted
to
make
sure
that
this
is
what
we
want.
I,
don't
have
a
specific
opinion
here,
but
allowing
breadth
first.
So
it's
a
little
bit
unintuitive
to
me,
but
we
can
certainly
opt
that
we
want
to
do
that.
F
E
E
E
But
that's
not
the
case
because
for
for
example,
in
in
golang,
the
iteration
order
can
change
from
one
iteration
to
the
next,
so
I
wanted
to
allow
for
that,
and
that
example
shows
a
possibility.
You
know
that
the
iteration
order
could
could
be
for
that
list.
Selector.
In
current
terms,
two
Pickers,
if
you
like,
could
produce
different
orderings
could
iterate
the
object
in
different
different
orders.
C
E
A
A
Well,
I
think
in
in
the
end,
this
is,
to
a
large
extent
about
what
the
descendants,
the
panda
does
to
the
various
note
lists.
It
gets
from
the
various
speakers
at
talks
to
so
for
the
the
child.
A
panda,
the
the
comma
into
the
Pender,
gives
an
ordering
gives
a
partial
ordering
for
the
The
Descendants
selector.
A
We
just
said
we
we
are
allowing
bread
first,
so
that
is
going
to
be
interesting
and
when
the
the
results
of
the
various
Pickers
are
being
put
together,
which
part
of
the
ordering
is
maintained
and
and
which
part
is
is
not
so,
can
you
given
that
that?
Well,
if
you
have
a
a
contains
one,
two
comma
B
contains
three
four
situation:
can
you
have
something
like
A1,
B,
3,
2,
4
and
so
on?
E
A
E
G
C
A
G
Of
this
is
going
to
be
the
test
Suite
or,
however,
we
manage
testing
of
this
yeah.
Having
listing
out
every
possible
permutation
of
acceptable.
Orderings
is
probably
not
ideal,
so
we
would
want
a
better
way
to
do
that,
but
I
don't
know
what
I'm
not
sure
what
that
is
in
particular,
but
we
we
definitely
need
to
nail
this
down
in
order
to
implement
some
sort
of
test.
Suite.
C
B
G
F
Many
many
programming
languages
have
a
you
know,
a
Content
addressable
array,
you
know
mechanism,
we
do
call
it
a
map
or
a
hash
map
or
whatever
and
I
I
I
believe
it
is.
It
is
occasionally
the
case
that
there
is
some
Randomness
and
and
many
many
languages
which
which
provide
this
facility
are
clear,
that
they
do
not
guarantee
the
ordering
and,
and
there
may
be
actual
Randomness
in
the
generation
of
hash
sizes,
hash
table
sizes-
and
you
know,
test
chaining
into.
A
Well,
the
main
reason
why
you
want
this
is
that
hash
tables
have
anomalies
when
you
sort
all
items
into
one
bin
or
the
majority
of
the
items
into
one
bin,
and
you
don't
want
to
and
to
put
an
attacker
in
a
situation
that
it
can
predict
which
bins
are
things
put
in.
So
you
add
some
Randomness
to
to
your
your
the
hash
function
and
some
implementations
add
that
Randomness
per
run
of
of
the
the
language
and
one
added
per
iterator,
and
if
you
do
it
per
per
iterator,
then
it
becomes
interesting.
F
G
A
F
A
A
E
C
A
A
Okay,
yeah
I
mean
it's
a
little
bit
of
a
black
thing,
the
the
of
course
it's
better
to
have
a
simpler
spec
and
and
only
allow
singular
paths
at
all.
But
it's
also
weird
to
have
an
existence
expression
that
cannot
be
applied
in
places
where
you
might
have
multiple
images
so
that
that's
just
my
general
consideration
here.
Maybe
we
should
have
another
look
at
the
the
implementation
consensus
to
to
find
out
whether
we
even.
G
G
And
my
personal
thoughts
on
this
is
that
I
think
it's
fine
for
the
exists
expression,
but
not
within
filter
expressions,
for
example,
I
think
I
think
having,
but
then
at
the
same
time
having
it
having
like
a
a
wild
card
in
an
exist
expression,
but
not
being
able
to
support
that
in
a
filter.
Expression
feels
weird
well.
B
C
E
E
E
C
C
D
F
A
Well,
there
isn't
a
proposal
right
now,
but
the
internet
draft
deadline
is
on
October
24th,
so
we
we
have
about
four
weeks
to
get
our
act
together.
If
we
want
to
to
make
that
deadline,
then
we
would
still
have
two
weeks
for
working
with
last
call
before
the
igf,
so
this
is
kind
of
the
most
optimistic
thing.
Can
we
fix
the
remaining
issues
in
four
weeks.