►
From YouTube: IETF-JSONPATH-20230207-0800
Description
JSONPATH meeting session at IETF
2023/02/07 0800
https://datatracker.ietf.org/meeting//proceedings/
B
E
E
A
D
E
A
Can
do
this
and
whatever
you'd
like
folks,
actually
Kirsten
Kirsten
is
right.
Sorry
I
should
have
I'm
in
the
middle
of
the
night
for
me
I'm
having
a
little
trouble
getting
swiped
in
here,
so
yeah
look
I
would
like
to
informally
see
if
we
can
set
some
goals.
I
think
that
we
are
very
near
the
Finish
Line
If.
You
find
the
Finish
Line
as
getting
the
sent
off
to
the
isg
and
starting
the
Fairly
lenses
set
of
steps
from
there
to
the
to
the
real
Finish
Line.
A
H
F
H
A
Right,
okay,
so
so
I,
so,
first
of
all,
you
know:
I
have
reviewed
Carson's
most
recent
update
to
to
the
reggae.
Thank
you
for
catching
those
Corner
cases
on
on
the
ecma
expressions
and
so
on.
I
think
it's
ready
to
go.
Does
anybody
want
to
do?
We
have
consensus
that
we
could
send
that
one
off
foreign
James?
You
have
your
your
Shepherd
document.
It
looked
like
in
reasonably
good
order.
Last
time,
I
looked
at
it.
E
A
F
A
G
F
F
That's
the
table:
yeah
there
you
go.
So
if
you
go
to
the
type
column
right
in
the
middle,
it
says
value
and
that's
the
type
in
our
type
system
and
then
also
in
abstract
instance
instances
you
have
value
with
parentheses
and
some
kind
of
parameter
there
and
I
think
that's
meant
to
stand
in
for
the
Json
value
of
some
sort
and
the
using
the
word
value
both
in
our
type
system
and
for
the
abstraction
of
of
what
that
means.
I
think
is
confusing.
F
Glenn
pointed
out
in
the
issue.
I
think
Glenn
pointed
out
in
the
issue
that
we
do
use
value
for
Json
value
throughout
the
document
and
so
I
think
that's
what
it
should
should
be.
But
that
means
I
think
that
we
need
to
rename
the
type
of
value,
because
I
think
it's
I
I
think
it's
a
little
bit
confusing.
F
F
F
G
A
G
D
A
A
H
B
H
H
D
A
F
D
I
think
the
important
observation
is
that
we
we
have
well-defined
semantics
with
the
type
system
we
have
and
anything
we
we
add
to
that
is
probably
going
to
be
very
specific
to
the
the
specific
extensions
that
are
being
defined.
So
it's
hard
to
come
up
with
a
general
type
system
in
the
the
base
document.
That
then,
will
be
useful
for
any
further
function.
Extension
that
people
will
be
coming
up
with
so
I
think
Greg's
approach
to
to
say
this.
D
This
is
something
that
an
implementation
can
do
as
a
quality
of
implementation
feature
is
useful,
and
my
comment
was
just
to
to
remind
people
that
this
is
not
changing
the
normative
semantics
so
that
that
will
stay
in
place.
But
it's
just
a
useful
service
station
implementation
you
can
offer
so
I,
don't
think
we
actually
need
to
change
any
texts
here.
D
A
Agree
yep,
in
fact
you
know
you
can
imagine
you
can
imagine
implementations
that
do
all
sorts
of
linting
somebody,
somebody
wrote
the
word
linta
and
and
be
super
smart
and
in
fact
you
can
even
imagine
things
that
are
that.
Are
you
know
in
systems
that
are
known
they
know
the
shape
of
the
of
the
of
the
Json
instances
that
they're
that
are
going
to
be
processed
and
can
be
even
even
smarter
on
that
so
I,
don't
think,
there's
anything
in
the
specs
that
constrains
implementations
from
being
super
aggressive
in
type
checking.
F
G
G
A
G
D
D
We
allow
a
node
to
be
cursed
into
a
value.
So
if,
if
a
function
requires
a
value
as
an
argument
and
gets
a
note,
then
the
the
value
will
be
extracted
from
the
node
and
that
only
works
for
optional,
because
everything,
but
so
this
is
something
that
that
I
have
been
called
calling
coercion
and
the
same
thing
happens
if
function
returns
a
node
and
that
is
used
in
a
comparison
environment
so
like
we.
D
We
handle
singular
paths
by
by
essentially
taking
out
the
the
node
to
to
affect
the
comparison,
the
value
of
the
node
to
affect
the
comparison.
We
would
take
out
the
the
value
of
the
node
returned
by
the
function,
so
we
have
some
coercions
that
are
essentially
already
implied
by
the
grammar.
We
have
the
the
coercion
in
the
function,
argument,
position
and
I
think
we.
We
only
differ
in
the
use
of
the
term
subtype,
where
I
consider
this
to
be
distinct
from
coercion.
G
D
H
G
D
H
F
E
G
Well,
yeah,
there's
two:
we
talk
about
a
well-formness
and
validity,
don't
we
in
terms
of
yes,
what
makes
it
correct,
Json
path
and
the
parser
I
think
will
be
doing
the
well-formness
check,
checking
that
the
Json
path
conforms
to
the
a
b
and
F,
and
then
on
top
of
that
there
is
a
set
of
validity
checks
to
do
with
I,
Json
values
and
and
function
types,
so
I
think
it
from.
From
my
perspective,
that's
kind
of
post
parsing,
but
it
still
gives
an
issue.
H
D
D
B
D
G
G
G
Then
the
second
bullet
in
262
says
the
function.
Expression
which
occurs
is
a
comparable
is
correctly
tough
if
it
occurs
as
a
comparable
in
a
comparison,
and
the
function
is
defined
to
have
result
type
option
loader
value
of
one
of
its
subtypes.
So
that's
that's
amplifying
the
the
comment
in
the
ABN
F.
If
you
like,.
D
G
H
G
A
C
F
C
Comparable
is
number
string,
literal,
true,
false
null
singular
paths
or
function
expression.
For
my
understanding,
the
result
of
a
function.
Expression
should
be
one
of
the
values
above,
but
if
function
expression
is
an
empty
note
list,
it
doesn't
fit
because
a
singular
path
in
my
understanding
cannot
be
an
empty
note.
List
am
I
right.
Yes,
yes,
a
singular
path.
D
H
C
F
F
G
D
Yeah
I
don't
have
a
solution
off
the
top
of
my
head.
I
I
would
prefer
the
the
parsing
to
enable
prioritize
choice,
so
this
can
be
implemented
using
a
positive
expression.
Hi
Grandma,
so
I
I
have
a
greater
aversion
against
the
grammar
and
ambiguity
than
than
most
of
you.
But
I
also
need
to
to
understand
whether
we
are
making
some
some
semantic
Assumption
of
lack
of
ambiguity
where
we
don't
have
it.
G
G
D
D
The
the
problem
really
is
just
that
when
we,
when
we
pass
this,
we
have
two
different
derivations
and
I'm,
not
sure
that
we
actually
account
for
this
possibility
in
all
of
our
thinking.
Okay.
So
if
you
look
at
the
comment
behind
function,
expert
right
at
the
top
of
the
screen,
this
essentially
is
telling
you
that
the
filter
path
accommodates
functional
Expressions
that
result
in
optional
nodes
or
subtype,
or
some
type
of
that
and
down
at
the
definition
of
comparable.
D
D
C
F
G
G
D
D
G
F
Okay,
so
Glenn
just
for
my
sanity
here
are
you.
It
seems
like
you're
making
the
distinction
between
the
parsing
and
a
compiling,
so
I
can
C,
sharp
I
can
say
true
equals
one
and
that
would
probably
parse
correctly
you'd
get
you
get
symbols
for
true
and
equals,
and
one,
but
then,
when
the
compiler
comes
through
and
checks
those
checks
that
syntax
tree
it
would
see
that
true
is
a
Boolean.
One
is
an
integer
and
it
would
say
you're
not
allowed
to
do
that.
G
But
into
the
way
it's
frozen
in
the
spec,
we
talk
about
well-formness
and
validity
and
I
think
they're.
Both
syntactic
issues,
but
wealth
formless,
is
determined
by
the
abnf
and
validity
is
determined
by
determined
by
some
extra
rules
that
we
layer
on
top
of
your
compilation
phase.
In
your
terms,
right.
B
F
G
G
D
Yeah,
so
the
the
true
validity
requires
that
we
have
is
that
the
integer
numbers
that
we
are
using
well
I,
don't
know
what
are
relevant
to
the
Json
processing
actually
means,
but
we
can
discuss
this,
but
the
integer
numbers
must
must
be
same
and
the
the
function.
Extensions
must
be
correctly
typed
and
that
that
is
then
delegated
to
section.
2.6
and
261
actually
has
the
the
text.
That
explains
that,
can
we
get
rid
of
these
unnamed
sections?
These
are
actually
driving
me
crazy.
D
D
C
H
D
G
G
G
A
E
D
D
F
D
F
Okay,
so
I've
got
some
issues
linked.
We
have
previously
decided
that
the
match
function
is
not
a
comparable.
It
is
not
allowed
to
be
compared
with
compared
using
the
equals
or
greater
than
or
whatever
functions
it
is.
It
returns
a
Boolean
and
that
was
decided
in
360
and
I
codified,
that
in
a
PR
in
365.
A
G
F
B
F
D
D
Yeah
but
you
you
are
now
trying
to
transfer
some
of
the
things
that
we're
doing
with
syntax
into
the
type
system,
and
that
is
neither
needed.
Nor
does
it
work,
because
one
equals
two
really
doesn't
have
a
type.
A
comparison
can
only
occur
in
in
certain
places
and
in
those
places
it
doesn't
have
a
function.
Extension
I.
F
D
A
H
F
Here's
my
thing:
if
the
second,
if
the
second
one
is
valid,
then
the
first
one
cannot
be
valid,
because
the
second
one
says
that
matches
returning
true
as
a
Json
as
a
Json,
comparable
value
and
then
the
first
one
says
that
it's
a
test
expression,
but
a
test
expression
cannot
have
a
comparable
value
in
it.
According
to
the
and
b
f.
D
D
F
G
Yeah
you
see
it,
my
recollection
is
that
we
we
want.
We
we
allow
the
equality
option,
the
second
option,
but
we
didn't
like
the
verbosity
of
it.
So
we
added
a
special
some
special
cases
so
that
you
could
write
the
match
without
the
equality.
Exactly
the
quality
is
incredible.
Correct
means
it's
not
needed.
F
D
G
F
G
D
Yeah,
so
you
essentially
are
saying
that
that
the
Boolean
value
that
match
returns
is
not
a
Json,
true
or
false,
but
is
is
a
different
category
of
things
like
nothing?
Nothing
is
already
one
value
that
we
allow.
That
is
not
among
the
set
of
Json
values,
and
we
would
have
a
function
true
and
the
function,
Falls
or
gesture
test
walls.
Whatever.
F
H
F
A
I'd
like
to
Crow
on
the
sentiment
of
people
looking
at
the
screen
right
now
that
last
one
that
currently
is
declared
to
be
invalid
are
people.
What
do
people
think
about
that?
It
looks
gross
to
me,
like
the
the
literal
truth.
Just
feels
like
a
different
flavor
of
thing
than
what
comes
out
of
a
test
test
expression.
But
what
do
other
people
think.
F
F
D
D
B
F
G
F
F
So
in
implementing
all
of
this,
which
I
have
gone
in
through
and
done
implemented
all
of
this
in
order
to
support
the
test
cases
that
I'm
writing
I
had
to
make
this
distinction
in
order
to
check
syntax
I
had
to
come
up
with,
because
I'm
an
object,
oriented
I
had
to
come
up
with
classes
and
everything
that
represent
the
the
test.
Boolean
and
a
value
I
had
to
come
up
with
all
these
things
in
order
to
get
this
to
work
properly,
but
it
only
works
properly
if
it
only
works
properly
with
all
those
syntax
checks.
F
F
In
terms
of
where
it
can
appear
in
the
the
expression,
those
are
the
only
two
options
for
syntax
checking.
You
only
occur.
You
only
care
where
it
appear
where
it
can
appear
in
the
options
or
in
the
expression.
You
don't
care
if
it
can
return
nothing
or
if
it
can
return
a
node
list,
is
it
valid
in
a
comparable
or
is
it
valid
being
being
operated
on
by
the
and
by
one
of
the
logical
operators?
D
F
G
D
F
G
Yeah
I
mean
I,
think
I
think
what
you're
saying
Greg
is
that
the
philosophy
was
that
that
direction
for
literals
and
we've
chosen
a
different
Philosophy
for
the
function.
Expressions,
correct,
yeah
and
I
agree
and
I
did
point
that
out
when
we
went
when
we
put
in
that
shorthand
and
said
this
will
cause
issues
to
come
out
of
the
woodwork,
because
it's
a
different
philosophy,
I
didn't
use
those
words,
but
you
know
see
this
was
coming,
but
nevertheless
it's
what
we've
got
is
consistent,
even
though
it's
you
know
sorry,
it's
not
consistent.
D
F
D
A
F
F
G
G
D
Yeah
they're
also
almost
no
tools
that
can
do
that
so
yeah
generally,
you,
you
fix
the
the
syntax
at
the
BNF
level
and
then
then
do
all
the
the
consistency
processing
at
this
first
semantics
level.
That
is
sometimes
also
called
syntax,
and
that's
what
tools
do
so
I
I,
don't
think
we
can
have
the
a
b
and
F
changed
dynamically
with
new
function,
extensions.
D
A
H
A
H
A
A
F
A
D
F
F
G
A
chance
to
flash
this
out
a
bit
in
the
function,
extension
section
the
type
system
and
talk
about
the
representation
yeah
there
in
the
notes
there
I'll
talk
about
optional
node
is
an
abstraction
of
a
singular
path
and
optional.
Node
of
value
is
an
abstraction
of
a
comparable.
So
the
philosophy
was
to
try
and
make
functions
returning
those
types,
optional
load
of
value
fit
anywhere
in
the
syntax,
where
comparables
fit
and
same
for
singular
path,
and
that
was
what
was
behind
us
comments
in
the
ABN
f.
F
F
D
D
A
H
F
A
D
G
D
H
D
D
A
C
F
C
D
D
H
D
C
C
D
D
D
So
we
we
I
think
we
we
do
have
agreement,
even
even
though
we
didn't
state
that
explicitly
that
we
do
not
want
to
make
this
step
at
this
point
in
time.
Yes,
we
agree.
So
this
this
would
be
significant
Innovation,
although
there
are
other
people
who
have
something
like
the
tilde
operator
and
all
that,
putting
that
in
a
way
that
it
fits
into
our
current
framework
would
be
a
significant
step
so
back
to
the
filter.
D
Expression
case
I
think
that
there
aren't
that
many
convincing
use
cases,
because,
generally
you
can
just
restructure
your
your
expression
in
such
a
way
that
that
you
use
selectors
to
go
there
again.
The
problem
is
that
you
only
can
filter
on
the
things
so
in
in
the
end,
you
will
have
a
Boolean
value
and
and
the
question
whether
a
path
with
some
selectors
in
it
returns,
a
value,
is
usually
as
good
as
going
through
an
index
function
in
a
function
extension.
D
So
you
would
need
to
to
construct
a
pretty
elaborate
example
that
that
has
that
doesn't
have
that
property,
so
I
also
defined
how
we
could
add
something
like
indexing
to
index
access
to
the
functional
extension
framework,
because
essentially
the
the
index
function
gives
you
the
last
segment
of
the
normalized
path,
representation
of
the
node
that
you
are
looking
at.
Yes,.
D
If,
if
you,
if
you
agree
to
the
fact
that
a
function
should
have
access
to
the
normalized
path,
well,
it
already
has
access
to
to
the
node
itself,
but
right
now
we
essentially
don't
have
in
our
model
that
the
function
can
get
at
the
normalized
path
of
of
this.
No
that
node,
and
that
would
be
a
new
thing.
D
C
C
Getting
a
value
you
will,
the
implementation
will
build
successfully
the
normalized
Parts
internally,
because
it's
Unique
to
get
to
that
value
and
the
last
step
before
getting
the
value
will
be
to
get
the
key
the
index,
the
name,
because
that's
the
key
to
get
the
value.
So
you
you
you
have
it
without
formally
being
allowed
to
access
or
build
the
normalized
path.
You
you
you
did
it
already
so.
F
The
the
use
case
in
that
last
comment,
there
I
think,
is
very
compelling
where
the
person
who
wants
to
be
able
to
write
a
path
that
does
this
doesn't
actually
have
access
to
the
processing
lot
to
the
logic,
that's
processing
the
Json
path
they
own.
They
are
interacting
with
an
API
that
says
all
right.
F
C
C
F
C
C
A
C
E
No
I'm
not
I'm,
not
advocating
we,
we
do
it,
but
I'm
just
sort
of
wanting
to
get
a
sense
of
where
to
go
now,
because
if
we
think
that
this
is
these
are
the
last
outstanding
issues,
the
ones
that
were
these.
These
issues
that
we'll
talk
through
today,
then,
actually,
we
probably
don't
need
an
a
Cadence
Spectrum
meetings,
provided
that
we
can
get
these
addressed
in
a
timely
manner.