►
From YouTube: IETF-JSONPATH-20210917-0900
Description
JSONPATH meeting session at IETF
2021/09/17 0900
https://datatracker.ietf.org/meeting//proceedings/
B
C
C
H
B
B
B
E
A
A
A
B
A
Okay,
so
when
I
tried
to
prepare
for
this
meeting,
I
I
was
a
bit
unsure.
Certainly
we
want
to
go
through
all
the
I
don't
know
how
many
they
are
at
the
moment,
a
large
two-digit
number
of
issues
at
some
point,
but
it
seems
we
are
always
stumbling
about
some
some
fundamentals
here
and
I
think
it
would
be
a
good
thing
to
discuss
these
fundamentals
briefly
before
we
go
into
the
issues.
A
So
in
the
interim
we
had
three
months
ago,
we
already
raised
the
question:
what
is
our
stance
on
implicit
conversions
and
at
the
time
I
made
the
slides
my
consensus,
my
sense
of
the
emerging
consensus
was
we
were
not
going
to
want
implicit
conversions,
so
that's,
maybe
a
an
extreme
that
we
are
not
completely
doing,
but,
on
the
other
hand,
embracing
implicit
conversions
as
much
as
php
or
javascript
have
done.
That
may
may
not
be
the
right
thing
to
do
and
then,
of
course,
the
the
question
came
up.
A
Yes,
one
second,
we
also
have
the
inverse
problem
that
we
do
not
necessarily
have
to
carry
the
entirety
of
the
json
type
system
into
the
expression
language.
So
what
my
my
presumption
here
is
that
we
will
have
an
expression
language
type
system,
that
is
a
super
subset
of
the
json
type
system.
So
now
please
go
ahead.
F
I
A
F
A
A
So
that's
nice
because
the
result
is,
is
a
node
list
of
zero
or
one
node
and
for
a
node
list
of
one
node.
We
actually
have
an
easy
way
to
convert
this
into
a
json
value,
because
a
node
contains
a
json
value
so
that
that's
the
simple
case,
but
we
also
have
dollar
based
queries
and
these
actually
provide
node
lists
so
either
we
need
to
get
rid
of
the
dollar
based
queries
or
only
allow
database
queries
that
produce
a
single
node
or
yeah.
A
A
A
In
the
current
grammar,
which
is
the
right
hand,
side
of
a
comparison
expression
and
there
we
could
essentially
to
translate
this
to
a
union
type
that
the
type
contains
all
json
values,
because
that's
what
we
will
find
at
that
node,
but
also
something
like
like
undefined
yeah,
and
we
have
to
work
with
the
fact
that
there
may
be
several
nodes
in
there.
So
I
don't
have
a
full
proposal
here.
A
A
Yeah,
so
let
me
just
quickly
go
forward,
so
my
my
conjecture
is
that
we,
if
we
continue
to
disallow
structured
values
in
the
grammar
for
the
expression
language,
then
we
have
a
subset
of
the
json
values
that
we
actually
can
compare
with
that
we
can
notate
as
literals.
Excuse
me
that
only
includes
primitive
values.
A
I
also
note
that
we
have
no
computation
in
the
expression
language
at
this
point
in
time,
so
we
cannot
add
things
or
divide
things
or
compute
modulos,
or
things
like
that,
which
sometimes
can
come
in
handy,
but
but
we
we
have
to
agree
whether
that's
something
we
want
to
have
or
not.
That
will
increase
the
complexity.
A
Yeah-
and
we
also
need
to
be
able
to
compare
query
results
because
we
we
have
path
as
as
a
potential
right-hand
side
of
the
comparison,
expression,
okay
and
then,
from
from
this
background,
we
can
start
discussing
the
slides
I
had
three
months
ago
with
respect
to
the
decisions,
the
the
decision
space
we
have
on
this
slide.
Glenn.
I
E
E
E
E
E
A
My
opinion,
if
you
ask
me,
is
that
we
have
a
result
from
the
comparison
project
which
shows
that
about
a
third
of
the
implementations,
don't
really
implement
anything
that
we
could
use
as
a
basis
for
this
decision
about.
A
third
is
providing
an
actual
existence
test
and
about
the
other.
Third,
not
quite
maybe
another
third
essentially
provides
half
a
dozen
different
ways
of
of
doing
the
truthiness
test.
A
D
I'm
looking
in
the
draft,
you
know
the
the.
What
I
think
is
is
probably
the
the
draft
and
there's
there's
really
very
very
little
in
there.
That
suggests
you
would
do
anything,
but
literal
single
literal
values
is,
is
somebody
put
in
a
proposal
because
I
don't
recall
seeing
it
for
for
changes
to
the
draft
to
talk
about
doing
comparison
against
structured
values.
A
Well,
people
are
carrying
around
examples
that
have
something
like
equals
bracket,
one
comma
two
bracket,
but
the
draft
currently
does
not
provide
that
in
the
syntax,
and
it
also
has
this
comment
in
in
the
notes
to
the
one
big
piece
of
syntax.
Comparisons
are
restricted
to
primitive
values,
such
as
number
string
through
false
null.
A
So
it
then
says:
comparisons
with
complex
values
will
fail,
but
we
can
cannot
even
notate
these
complex
values
at
the
moment.
So
that's
not
a
question
that
needs
to
be
raised
and
answered.
So
as
long
as
the
grammar
doesn't
provide
structured
values,
I
think
yes,
indeed,
the
draft
is
limited
to
simple
values:
primitive
values.
E
E
D
D
A
A
A
A
E
A
A
F
F
D
F
E
F
F
F
F
F
Yeah
and
once
you're
that
comparison
of
multiple
values,
there
is
some
strange
stuff
in
the
logic
as
well
that
I
pointed
out
before,
which
is
not
consistent
with
the
way
logic
is
normally
done.
I
think
I've
raised
that
in
an
issue
so,
but
you
know
there
are
certainly
downsides
of
allowing
comparisons
of
multiple
values.
D
E
E
A
A
H
E
A
A
A
A
E
E
F
D
E
E
E
F
E
D
Yeah,
I
don't
care
either
way.
I
think
we
should,
because
I
can
you
know
that
simplifies
code
generation,
if
I'm
generating
one
of
these
things,
I'm
just
going
to
say
you
know
for
anything.
I
want
to
match,
put
it
in
the
array.
If
there's
nothing,
you
get
an
empty
array
and
it
doesn't
match.
I
think
that's
yeah.
D
E
F
D
D
D
D
E
E
A
A
D
D
D
D
E
D
A
D
Well,
it's
certainly
an
expansion
of
the
semantics
of
the
current
draft,
because
you
know
the
current
draft
only
shows
numbers
and
strings
and
things
like
that
yeah
you're.
Just
in
all
things
I
tend
to
to
to
the
minimalist
and
in
general,
don't
want
to
make
the
draft
bigger
than
it
is
and
are
we
going
to
be
happy
writing
down?
A
A
Yes,
well
to
a
certain
extent,
so
it
depends
a
lot
on
on
the
the
trade-off
here
between
implementation
complexity.
On
one
end,
and
I
think
we
we
have
hit
something
that
that
is
actually
reason
reasonably
easy
to
implement
on
a
constraint
system
now
and
the
the
problem
that
in
json
you
sometimes
have
to
go
to
structured
videos
to
represent
non-trivial
data
and
so
put
putting
in
a
somewhat
artificial
limitation.
A
Here
would
then
lead
people
to
actually
representing
colors,
not
as
an
array
of
three
values,
but
as
a
string
of
three
decimal
integers
with
slashes
between
them
or
something
which
makes
life
very
much
harder
for
for
a
constrained
implementation.
So
I
think
there's
a
trade-off
here
and
I'm
I'm
not
entirely
decided
on
which
end
of
the
trade-off
I'm
I'm
at,
but
forcing
users
to
actually
do
who
do
weird
representation
decisions
just
because
the
tool
they
are
using
is
not
capable
of
of
handling
the
the
obvious
representation.
A
Yeah,
but
I'm
pretty
happy
with
what
what
is
on
on
this
issue
here
and
I
think
we
we
should
spend
a
little
bit
more
time,
thinking
about
122,
but
I
think
that
what
what
we
have
written
down
there
is
actually
a
reasonable
result
as
well,
but
I
I'm
sure
would
like
to
hear
from
the
working
group
what
they
think
about
this.
At
least
what
we
have
now.
E
E
Consider
a
member
of
an
object
named
answer,
given
maybe
in
the
test
or
something
and
the
given,
maybe
have
three
values
or
two
values
answer
given
is
true
answer
given
is
false
or
answer
or
no
answer
has
been
given,
so
the
answer
given
member
simply
does
not
exist.
So
I
think
this
is
an
example
where.
E
E
E
A
A
A
A
D
E
A
E
A
A
E
A
A
D
F
J
C
D
A
D
D
E
E
A
F
D
H
A
D
So
so
kirsten
in
in
theory,
I
can
see
the
argument,
but
in
terms
of
getting
a
library
and-
and
if
I'm
writing
just
you
know,
implementation
in
ruby
or
go
or
rust
or
whatever
is
there?
Is
there
a
way
in
the
standard,
regular
expression,
library
to
say
you
know,
only
accept
this
flavor
and
I
don't
know
how
to
do
that.
A
Well,
I
just
had
the
same
discussion
about
abnf
with
someone
and
the
the
result
of
that
discussion
was
that
it
actually
was
simpler
to
to
actually
implement
the
thing
than
to
to
continue
discussing
how
to
do
this,
because
abnf
is,
is
actually
surprisingly
easy
to
implement.
If
you
think
about
it.
So
my
approach
to
this
would
actually
be
to
define
a
subclass
of
regular
expressions.
A
That
is
actually
simple
enough
to
implement
that
everybody
can
do
that
and,
of
course,
you
implement
it
by
transforming
the
regular
expression
into
the
regular
expression,
syntax
that
you
already
have
and
yeah.
This
is
not
the
first
idea
you
get
when
thinking
about
this
problem,
but
after
a
lot
of
thinking,
I
I
think
that's
the
the
only
reasonable
way
to
handle
regular
expressions.
A
E
E
D
D
Something
like
that.
So
I
think
what
you're
saying
is
the
ideal
behavior
we
would
like
to
see
in
implementers
is
that
if
they
see
a
reg
x
they
they,
then
it
doesn't
match
the
grammar.
They
throw
it
out,
it's
a
syntax
error
and
if
it
does
match
the
grammar,
they
toss
it
to
the
to
the
nearest
nearest
reg,
f
library
and
with
the
expectation
that
they
should
get
interoperable
behavior.
A
D
E
E
A
Everybody
is
yeah,
so
yeah.
The
the
most
important
fight
that
has
happened
is
in
the
yang
community,
so
yang
opted
for
the
xsd.
The
the
xml
regular
expressions
and
about
half
of
the
community
is
using
those
and
the
other
half
of
the
community
is
completely
ignoring
the
fact
that
this
is
based
on
xml,
regular
expressions
I
and
are
instead
writing
some
perl
java,
javascript,
whatever
regular
expression
in
there
and
and
hoping
that
something
useful
will
happen
so
that
that's
definitely
an
unhappy
situation.
D
D
D
F
Yeah
yeah,
because
we
we've
narrowly
focused
on
interoperation
between
jsonpath
implementations,
but
there's
also
a
general
question
that
you
alluded
to
just
then
using
adjacent
regular
expression
in
adjacent
path
and
in
another
context
in
the
same
project,
and
it
might
be
quite
a
complex,
regular
expression,
you're
trying
to
maintain
them
both
so
you've
got
to
then
massage
it
into
the
the
new
standard
version
and
maintain
it.
Alongside
the
well-known
loved
programming
language
version
that
you're
using
separately,
it's
pretty
horrendous.
D
E
A
So
when,
when
an
implementation
encounters
one,
it
can
find
out
whether
it
actually
implements
that
extension
and
it's
it's
breaking
implementations
that
are
not
implementing
the
extension
in
a
more
defined
way
than
than
just
randomly
changing
the
syntax.
After
the
fact.
What
do
so?
That
can
really
help
both
implementers
and
users,
because
users
have
a
very
specific
things
they
can
can
ask.
Do
you
support
extension
eggs
and
there
is
a
boolean
answer
to
that,
and
so
so
you
know
whether
a
certain
extension
point
is
included
in
an
implementation
or
not.
F
F
Yeah,
what
I'm
saying
is
slightly
different,
I'm
thinking
from
the
implementer's
point
of
view.
If
there's
a
way
of
declaring
that
you
know
there,
there
isn't
a
an
ietf
standard
for
re2,
but
if
I
want
a
go
implementation
to
implement
to
interoperate
with
another
go
implementation,
then
rb2
is
the
way
to
go.
For
example,
it's
just
just
what's
there
and
go.
H
D
D
D
D
So
I
think
we
should
probably
go
go
back
and
get
the
sense
of
okay.
So,
broadly
speaking,
we
have
two
options:
one
is
no
json
path.
A
option
b
is
sorry,
no
regular
expression.
I
feel
like
a
option.
A
is
no
regular
expression.
Option
b
is
okay,
regular
expression,
but
with
the
full
abn
for
the
regular
expression
included.
B
B
C
A
A
A
D
D
I'm
actually
working
on
a
different
protocol
now
on
another
project,
where
somebody
proposed
using
emoji
as
field
separators
in
assertions-
and
I
thought
the
idea
was
crazy,
but
it
seems
to
just
work.
You
know
all
the
libraries
just
yeah
okay,
you
can
just
put
it
in
right
right
there
and
then
they
join
and
the
split.
And
then
it
just
works.