►
From YouTube: IETF-JSONPATH-20221122-0800
Description
JSONPATH meeting session at IETF
2022/11/22 0800
https://datatracker.ietf.org/meeting//proceedings/
B
C
B
D
C
B
E
B
E
B
D
B
B
Blue
sheets
are
automatic,
because
medeco
I'll
keep
an
eye
out
on
the
chat,
because
there's
only
a
handful
of
us
in
terms
of
the
agenda
bashing,
we
more
or
less
stick
to
the
same
thing
that
we've
been
doing
for
the
previous
meetings,
where
we'll
go
through
a
bit
of
a
status
update
on
the
draft
I
Rejects
and
then
cut
through
any
issues.
Is
there
anything
particular
that
anybody
else
wants
to
bring
up
or
discuss.
B
B
Okay,
then
we
should
probably
just
actually
if
there's
one
thing:
I
want
to
start
with
it's
I
regex,
because
in
the
previous
meeting
we
put
out
a
call
for
adoption.
Sorry,
the
working
group
last
call
wow,
forgive
me
so
the
working
group
law
school
went
out
and
for
a
couple
of
reasons,
I've
I've
stole
it.
Normally
it
would
be
a
two-week
out
there
just
for
a
fortnight
and
then
you'd
have
enough
response
to
get
a
consensus.
B
A
Yeah
so
I
think
the
the
way
we
we
are
going
to
handle
this
regex
issue
is
by
by
putting
the
the
additional
functionality
we
want
for
Json
path
into
the
function
extension
mechanism.
So
if
you
have
seen
the
the
pull
request,
I
put
in
yesterday
number
280
the
updates
to
the
pull
request
I
put
in
yesterday.
We
now
have
a
match
and
as
such
function,
and
that
should
address
the
the
main
issue
here,
so
that
that's
my
status.
Essentially,
we
don't
have
working
Roblox
calls
on
on
irigafs.
B
That's
that's
what
I
wanted
to
clear
out
was.
Does
this?
Does
this
still
working
group
last
call
or
not,
and
if
the
answer
is
you've
put
sorry
I've
missed
I
missed
that
one
when
looking
through
the
pilot
thing,
a
pile
of
issues
in
GitHub,
Etc
Okay,
so
in
terms
of
this
will
obviously
mean
you're
cutting
a
new
you
don't
need
to
cut
out
a
new
version
of
iraj
x.
Is
that
correct.
B
A
E
So,
in
regard
to
that
that
issue
that
I
raised
with
with
I
regex
being
based
in
the
the
XML
version
of
of
regex,
the
larger
question
was
not.
How
are
we
using
it
in
Json
path?
I,
think
the
solution
of
having
two
functions
rather
than
just
the
single
operator
does
address
the
issue
with
that
addresses
that
issue
in
the
context
of
Jason
path.
E
But
my
understanding
from
our
meeting
months
ago,
when
we
originally
talked
about
creating
another
regex
standard,
was
that
we
wanted
something
that
was
an
intersection
of
popular
and
common
syntaxes.
That
would
be
that
would
act
as
kind
of
interoperable
base
and
the
arguments
that
I
put
forth
in
that
issue
are
that
the
the
XML
regex
is
not
does
is
not
representative
of
the
larger
usage
of
regex
and
I've
listed.
Several
I've
listed
multiple
websites
that
that
don't
have
the
implicit
anchoring
which
the
XML
regex
does.
A
Yeah,
so
the
the
approach
we
we
took
with
iranx
was
to
actually
create
exactly
that
interoperable
intersection
and
there's
no
way
to
do
an
internal
intersection
with
anchors,
because
anchors
are
not
interoperable
so
that
that's
one
of
the
reasons
we
we
took
that
out,
but
also
because
we
we
are
seeing
that
regular
expressions
are
used
in
in
various
places
where
you
don't
need
them
to
be
searching
regular
Expressions.
So
we
have
okay.
E
A
E
E
I
saw
those
instructions,
but
there's
no
evidence,
there's
no
evidence
to
say
why
we
should
prefer
implicit
anchoring
over
over
non-implicit
anchoring
over
explicit
anchoring
there
there's.
No.
You
have
presented
no
evidence
as
to
why
you
chose
the
XML
version
over
the
many
common,
many
more
common
and
popular
syntaxes
that
are
in
use
today.
A
E
C
E
Okay,
then
I
would
like
to
see
a
survey
of
how
they're
different
between
the
different
implementations,
because
that's
what
I
haven't
seen
and
the
other
person
who
has
commented
on
this
is
one
of
my
fellows
from
Jason
schema
Henry
Andrews.
He
also
has
not
seen
evidence
to
that,
and
this
is
the
primary
reason
Henry
got
involved
was
because
I
proposed
to
Jason
schema
that
we
use
this
supposed
interoperable
regex
as
a
replacement
for
Pure
ecmascript,
which
is
not
Universal.
A
Yeah
so
I
understand
that
that
Json
schema
cannot
make
this
change,
because
the
the
way
that
the
the
pattern
keyword
is
used
right
now
is
based
on
on
explicit
anchors,
so
that
that's
certainly
interesting
and
one
interesting
thing
one
could
do
is-
is
Define
a
way
to
deal
with
those
explicit
anchors
as
we
find
them
in
in
Json
schema
documents
today,
but
that's
not
work.
I
said
how
to
do
so.
A
E
E
E
A
E
A
Greg
I
just
told
you
why
I
think
this
is
the
right
thing
to
do
now.
The
the
reason
I
can
give
for
people
who
don't
share
the
the
view
of
the
world
is
that
there
is
no
interoperable
subset,
no
inter
intersection
that
we
can
work
on
and
I'm
having
a
hard
time
doing
anything
more
than
writing
these
sections
in
iraqs,
because
it's
obvious
from
them.
So
I
really
wouldn't
know
what
what.
A
B
E
C
E
C
E
B
E
B
B
B
A
B
B
Okay,
then,
let's
do
that.
It
would
be
good
if
we
get
some
emails
to
the
list
of
endorsement
for
it
or
non-endorsement,
typically
in
other
working
groups,
and
this
is
more
further
than
not
casting
people
in
the
call.
It's
usually
when
a
working
group
last
call
is
issued.
Folks
will
reply
to
the
email
saying
yes,
this
is
ready
or
no
it's
not
and
here's.
B
B
C
A
A
I
have
made
three
headlines
here
for
what
what
we
actually
need
to
work
to
finish
this
or
what
I
understand
what
we
need
to
work
on
to
finish
this,
so
it
may
be
other
things
but
I
think
it's
it's
pretty
clear
that
we
we
have
to
work
on
this
node
list
versus
where
you
think.
As
Glenn
pointed
out,
we
don't
have.
We
don't
actually
have
a
way
to
put
a
generalized
node
list
into
a
function
like
count
at
the
moment.
A
A
A
So
that's
the
the
second
item-
and
the
third
item
is
that
there
are
still
a
lot
of
editorial
issues.
We
could
say
say
things
in
in
a
way
that
is
easier
to
understand,
but
I
think
we
can
do
these
editorial
issues
after
merging
to
AG,
unless
they
are
really
egregious.
Just
like
we
have
been
doing,
Glenn
actually
has
been
doing
editorial
fixes
on
the
document
and
in
the
last
few
weeks,
so
I
think
we
can
keep
working
on
the
editorial
issues
even
when
280
is
merged.
A
D
D
D
D
D
A
Yeah
that
definitely
can
be
argued,
so
I'm
I'm,
seeing
one
value
there.
So
for
me,
it's
one
but
yeah.
Handing
a
non-container
non-string
to
a
length
function
is
is
exactly
the
the
kind
of
problem
that
we
have
to
deal
with,
so
that
in
programming
languages
we
could
throw
errors.
Now
we
currently
the
the
idea
is
that
we
don't
throw
errors
at
runtime.
We
throw
errors
at
compile
time,
so
we
can
look
at
jasonpath
query
and
say
whether
that's
a
very
or
not
without
looking
at
the
data.
A
Think
we
have
things
like
like
false
or
undefined,
or
something
that
that
are
closer
to
the
situation
where
Jason
doesn't
have
undefined.
So
we
would
have
to
extend
the
the
the
view
space
essentially
most
modern
programming
languages
have
have
a
construct
that
that
is
called
option,
or
maybe
these
are
two
popular
names
for
the
feature
where
you
can
say
you
have
data
or
you
don't
have
data,
and
that
would
be
the
right
thing
to
do
if
we
were
designing
a
programming
language,
but
we're
not
doing
that.
D
D
For
an
very
useful
function
would
be
the
name
of
or
index
of
something
like
that
to
address
the
the
member
name
or
looking
for
for
values
with
the
specific
member
name
this
what
he
came
up
several
times
in
issues-
and
this
would
be
a
very
useful
extension
point-
also
you
edit
some
others
I
think
they
are
useful.
We
come
to
the
regex.
The
two
reg
X
functions
soon.
C
D
A
So
far,
the
the
examples
that
I
have
seen
actually
are
trying
to
use
filter
expressions
in
a
place
where
actually,
we
have
other
Json
pass
mechanisms
that
that
would
be
better
to
use
in,
in
this
case,
so
I'm
not
seeing
a
particular
compelling
use
case
for
something
like
like
name
of
yet.
The
reason
we
haven't
done.
Anything
in
this
space
is
that
we
wanted
to
avoid
looking
up
in
in
the
structure
of
of
the
Json
value
that
is
put
into
the
query.
A
D
Yeah
sure
we
don't
want
to
look
up
the
the
tree
of
course,
but
if
you
are
iterating
over
the
member
values
you
you
get
the
name
the
member
name,
and
if
you
ask
for
the
value
with
the
member
name
Foo
and
you
get
it,
you
have
a
metric,
it's
very
easy
to
implement.
So
many
people
don't
understand
why
this
isn't
possible,
with
the
good
chasing
past,
to
ask
for
a
member
with
a
specific
name.
A
D
A
The
the
way
that
the
filter
expressions
are
set
up,
it's
currently
relatively
hard
to
make
use
of
that,
because
the
filter
expression
in
the
end
only
gives
you
a
Boolean
value.
So
you,
you
cannot
really
do
much
with
a
collection
of
of
members
that
you
select
based
on
some
criteria,
so
I
think
that
such
an
extension
would
become
more
useful
if
we
had
more
functionality
where
we
actually
can
use
the
Expression
language.
If
we
had
the
way
for
the.
A
D
A
B
D
A
Yeah
so
on
the
first
item,
the
Syntax
for
node
list
versus
value,
I
I,
propose
to
split
function,
argument
into
a
node
list
argument
in
the
value
argument
that
that's
bit
is
inconsequential
at
the
end,
because
a
functional
argument
will
be
a
choice
between
the
two,
but
it
allows
us
to
actually
talk
about
which
Things
Are
allowed
where
and
we
would
actually
have
a
way
of
checking
without
data.
Whether.
A
C
E
A
C
A
D
C
D
I
think
I
do
have
an
a
question
with
length
and
and
count
I
got
the
argument
from
Carson.
That
length
does
not
work
with
a
note
list,
because,
if
note
list
ER
has
only
one,
it
would
automatically
take
the
value
of
that
note
in
that
list.
So
this
was
the
argument.
I
I
can
follow
this
argument
to
should
take
two
functions,
count
and
length,
but
if
we
consider
the
discussion
about
note
lists
and
how
they
are
presented
in
in
in
Json,
it's,
it
would
be
an
array.
So
what
if
we.
A
D
A
My
response
to
that
would
be
having
some
something
smart
in
the
language
that
detects
what
the
writer
of
the
query
was
intending
to
do
is
always
inferior
to
the
writer
of
degree,
actually
saying
what
they
were
trying
to
do,
where
they're
trying
to
be
counting
notes
or
were
they
trying
to
count
elements
of
an
array
and
I'm
I'm,
really
much
in
favor
of
keeping
things
simple.
Do
not
put
any
any
smart
rules
in
there
and
just
have
the
the
specifier
say
what
they
actually
are
trying
to
count.
D
D
B
D
B
E
A
E
A
B
D
D
D
Or
the
value,
so,
if
we
are
talking
about
notes,
I
have
in
mind
okay,
it's
a
pair
of
a
value
and
its
location,
the
normalized
path,
pointing
through
it.
So
a
note
list
should
hold
pairs
of
values
and
the
the
normalized
path,
but
it
does
not
nodeless.
It
only
holds
the
normalized
path,
it's
enough.
So
this
is
one
of
the
click
in
my
head.
Where
I
don't
know
how
to
argue,
if
someone
would
ask
me,
please
tell
me
what
exactly
is
a
note
in
your
speaker
to
you
you,
you
must
help
me
yeah.
C
D
C
Yeah
I
added
a
a
paragraph
in
the
in
one
of
the
other,
pull
requests
to
try
and
clarify
this
and
I
described
it
as
nodes
and
modeled,
using
as
a
value
in
a
location
and
nerd
lists
are
modeled.
So
it's
essentially
nodes
and
node
lists
are
extract,
abstractions
that
we
use
to
model
the
behavior
of
Json
path
and
then
the
question
is
how
are
those
abstractions
represented?
C
So
a
nodalist
can
be
represented
as
a
an
array
of
normalized
paths,
but
it's
it's
more
than
just
an
array
of
normalized
paths.
You
know
it's
just
a
particular
representation
which
actually
loses
some
information.
It
loses
the
values,
but
it's
it's
it's
kind
of
sufficient
because
you
can
always
take
the
normalized
pass
and
use
them
to
look
up
the
values
in
the
argument.
D
C
Well,
the
representation
is
that
you
have
to
look
up
the
values
using
the
normalized
paths.
So
there's
a
there's,
a
mapping
between
the
like
the
concrete
array
of
normalized
paths
and
the
nodalist
and
the
way
the
mapping
works
is
that
you
can
take
the
normalized
path
to
deduce
the
locations
and
you
can
apply
the
normalized
pass
to
the
argument
to
deduce
the
values.
D
C
D
C
Have
here
so
the
I
think
Caster
may
be
about
to
speak,
but
let
me
continue
speaking
briefly.
I
think
the
points
you
were
making
in
the
in
the
issue
was
that
we're
aiming
here
at
Jason,
so
we're
looking
at
Json
values.
You
know
we're
limiting
the
spec
to
be
able
to
return
Json
values
rather
than
members
which
are
not
Json
values,
for
example,.
A
So
the
location
is
the
actual
abstraction
that
we
so
far
have
have
mostly
avoided.
To
actually
talk
about
and
the
normalized
path
is
a
way
to
represent
a
location
that
is
useful
because
you
you
actually
could
represent
that
in
in
a
Json
structure,
because
it
can
be
represented
in
a
Json
string
so
that
that's
what
makes
normalized
paths
useful,
but
normalized
paths
are
not
the
concept
that
we
are
talking
about
when
we
are
talking
about
the
location
of
a
node.
So
let's,
let's
try
to
separate
Concepts
and
their
representations.
A
A
So
in
a
general
graph
you
really
have
to
separate
the
edge
and
and
the
node
or
the
edge
and
the
vertex
to
avoid
the
node
at
the
moment
notice.
Just
a
synonym
for
vertex,
because
you
can
have
multiple
edges
leading
into
a
vertex
in
a
tree.
There
is
only
one
Edge
leading
into
a
vertex,
and
then
you
have
zero
more.
It
is
leading
out,
so
you
can
talk
about
the
edge
of
a
vertex.
A
Okay!
I
only
do
that
in
a
tree.
You
cannot
do
that
in
in
a
graph
in
in
general,
and
that,
of
course
makes
it
somewhat
attractive
to
actually
keep
the
edge
that
that
leads
into
a
Vertex
together
with
the
vertex
and
that's
what
what
we
call
member
in
in
the
the
object
and
what
we
haven't
been
calling
by
by
any
name
yet
for
arrays
but
which,
which
Stefan
has
shown
us.
We
could
be
doing
so
that
that's
a
very
different
way
to
look
at
that
tree.
A
Note
that
the
edges
are
still
not
locations
in
the
complete
sense,
because
they
are
not
describing
the
whole
path.
They
are
just
describing
the
singular
Edge.
So
if
we
talk
about
the
location,
we
still
have
to
follow
multiple
edges,
but
keeping
the
edge
with
the
vertex
actually
can
can
simplify
things
and
then
suddenly
things
like
name
off
and
and
so
on
become
much
more
obvious
because
well,
if
you
kept
the
edge
with
the
vertex,
the
name
of
vertex
is
very
well
defined
thing.
So
I
understand
the
attractiveness
of
that.
A
On
the
other
hand,
we
also
try
to
stay
in
the
Json
data
model
as
much
as
possible
and
possibly
Beyond,
where
we
actually
need
to
stay
there.
There
I
mean
we
obviously
need
to
stay
there
when
we
actually
return
a
value
from
a
query
that
needs
to
be
representable
in
in
Json.
You
cannot
represent
in
Json
a
Vertex
with
its
Edge.
A
Actually,
if
you
look
into
documentation,
you
often
see
people
trying
to
do
that,
so
they
have
a
a
member
that
where
they
write
a
string,
a
colon
and
and
then
a
value
without
braces
around
that.
That's
not
very
Json,
but
it's
so
natural
to
talk
about
that
that
people
think
they
are
writing
Json
if
if
they
just
give
a
member
name,
a
colon
and
and
they
so
that's
that's
a
bit
of
a
yeah,
interesting
property
of
Jason
that
we
can't
really
talk
about
those
members
or
Edge
vertex
combinations
in
in
general.
D
C
A
Well,
we
can
talk
about
the
way
we
want
to
use.
We
don't
have
to
to
emulate
the
way
other
implementations
talk
about
their
abstract
Concepts,
so
we
we
could
do
that
I'm,
just
not
sure
that
that
the
the
confusion
we
generate
from
that
is
worth
the
the
win
of
of
always
having
the
the
edge
with
the
vertex.
D
Get
into
vertices
and
and
and
edges
I.
If
you
tell
it's
very
unusual,
to
combine
an
etch
and
vertex,
which
exactly
is
what
what
a
member
is,
if
I
understood
correctly,
and
the
only
note
which
is
a
vertex
is
the
value
okay,
but
we
do
not
tell
we
do
not
talk
about
nodes,
they
are
purely
the
values
so
edges
in
the
tree.
No,
yes,
H
is
a
no
no
vertices
in
the
tree
should
be
values,
but
are
not
the
notes.
D
A
D
A
C
A
D
D
A
D
C
D
C
B
C
B
B
C
C
It
was
a
draft,
a
PR
for
a
while,
because
it
wasn't
clear
whether
we
could
improve
the
language
in
the
spec,
but
I
think
the
pr
now
does
improve
it
and
I'm
particularly
pleased
with
that
paragraph
that
I
mentioned,
because
it
strips
out
a
lot
of
the
nonsense.
If
you
like
from
the
definitions
of
the
terms
and
and
puts
it
in
the
central
place
where
it
can,
we
can
discuss
the
tree
and
the
nodes
and
the
fact
that
members
are
not
nodes.
C
B
B
A
A
D
B
Both
of
these
documents
will
likely
go
through
more
revisions
once
both
gone
off,
because
we'll
get
feedback
from
all
of
the
different
reviews
and
ads
and
all
the
rest,
all
the
way
up
to
Fourth
48,
which
is
the
basically
the
last
stop
before
RFC
editor,
so
I
think
yeah
that
the
the
dependency
isn't
in
theory,
a
problem
here
we
can
have
both
submitted
off
I.
Think
for
as
long
as
we
ensure
that
we
make
it
clear
that
there's
that
dependency
there.
A
We
wanted
to
finish
the
the
integration
of
regex
in
in
280,
which
is
as
far
as
I
know,
pretty
much
done
what
we
should
check
that
and
then,
by
about
December
5,
we
would
have
a
new
version
of
the
iranx
document,
which
would
close
the
working
group
last
call
I
mean
formally
we
are.
We
are
ahead
of
of
the
base
document
so
formally
there
should
be
no
problem
at
all
and
there
hasn't
been
a
need
to
to
change
anything
in
in
Iraq's.
A
B
B
B
C
Yeah
I
just
wanted
to
ask
this:
is
the
only
working
group
I've
been
a
member
of
and
I
haven't
been
through
any
other
ietf
specs?
So
what
you
know
what
what
should
I
expect
in
terms
of
the
the
sequel
after
working
group
last
call?
Is
it
kind
of
all
hell
breaks
loose
and
we
have
to
rewrite
the
thing
10
times
or
does
it?
Is
it
fairly
smooth
typically
or
what
happens?
Yes,
if.
A
It
depends
on
how
well
we
do
our
work
so
so
part
of
the
the
working
work,
of
course,
is
to
create
a
good
specification,
but
the
other
part
is
to
rate
a
specification
that
will
pass
isg
and,
of
course,
I
I
have
been
trying
to
to
keep
an
eye
on
that,
but
in
the
working
glass
Hall
we
we
definitely
want
to
increase
our
attention
to
that.
And
then
you
never
know
I
mean
it's
not
not
plannable.
A
The
the
the
whole
point
about
the
isg
is
that
they
bring
perspectives
on
this
that
the
working
group
doesn't
have,
because
it's
pretty
much
focused
on
on
the
subject
matter,
why
the
isg
is
a
very
diverse
body,
so
maybe
Warren
Kumari
has
some
operational
concerns
that
we
haven't
addressed
yet
I
think
we
have
but
he's
smarter
than
I,
so
he
he
will.
He
might
be
bringing
up
something
and
so
on.
So
we
just
have
to
go
into
the
the
isg
phase.
A
First
of
all,
we
have
to
make
sure
that
our
ad
is
Happy.
What
with
what
we
are
doing.
That's
the
the
first
part
of
that
phase,
and
then
we
have
the
IHF.
Last
call
and
the
isg
ballot,
and
there
we
might
get
some
some
pushback
on
on
some
detail-
that
we
haven't
done
right
or
we
might
get
pushback
on
some
something
much
more
fundamental
and
we
don't
know.
D
C
B
Yeah
it
I
mean
we
will
have
the
support
of
our
ID
and
of
document
shepherding
and
and
the
likes
so
you're
not
going
to
get
taken
out
from
a
blind
side
on
this
and
before
stuff
to
rewrite
everything.
It's
been
considerable
amount
of
work
put
into
it.
You
know,
caveating
all
the
things
that
cast
and
raise
so:
okay,
yeah.
Okay,
if
there's
no
other
business,
then
I
think
we
can
close.
This
and
I
can
try
to
get
to
get
together.