►
From YouTube: IETF112-JSONPATH-20211110-1200
Description
JSONPATH meeting session at IETF112
2021/11/10 1200
https://datatracker.ietf.org/meeting/112/proceedings/
E
C
F
D
E
You
so
where
is
it
okay.
A
Shall
we
start
now
and
I
I
presume
that
stefan
will
join
us
at
some
point.
A
Yeah
I
mean
we'll
spend
the
first
bit
of
that
just
getting
through
the
the
usual
administration,
yeah
cool,
okay,
so
I'll
do
the
I
can
do
the
formal
introduction,
as
I
always
do
so.
This
is
the
json
path
working
group
for
I
eat
ietf
112.
A
The
usual
disclaimer
as
this
is
an
ietf
meeting,
the
note2l
applies
and
all
the
bcps
and
guidance
that
you
see
stated
here
applies
to
this
meeting
as
well.
If
you
have
any
questions,
you
can
ask
the
ombuds
team,
or
you
can
also
ask
francesca
who
is
quietly
sitting
in
the
background
there,
probably
a
good
idea.
Carsten.
Are
you
able
to
take
notes
when
you're,
not
speaking
or
is
there
somebody
else
who
could
help
volunteer.
C
A
Okay,
that's
fine!
I
guess
what
we
can
do,
then,
is
what
we've
done
in
the
past,
which
is
I'll
crank
out
some
notes
from
from
the
vod,
when
it's
uploaded
a
little
bit
later,
the.
A
A
I
will
try
and
do
my
best
to
keep
keep
an
eye
on
the
chat
in
case
anybody
needs
to
pipe
up,
and
but
if
somebody
could
nudge
me,
that
would
be.
If
I
miss
anything
that
would
be
kind
of
helpful,
do
we
have
any
agenda
bashing
that
needs
to
be
done.
A
About
the
direction
yep
tim
and
I
had
discussed
that
as
a
as
a
potential
thing,
and
maybe
if
we
have
time
for
that
after
after
I
guess,
cast
carson's
gone
through
the
issues
we
can
include
it.
B
Yeah,
okay,
so
I
think
we
can
actually,
I
think,
let's
try
to
do
that,
because
I
think
I
think
that
that's
a
fairly
short
item
based
on
our
discussion
last
time
I
mean.
B
Well,
let
me
just
offer
the
following
sure:
if
people
don't
mind
can
take
a
minute,
is
that
at
our
last
get
together,
we
had
a
consensus
that
we
can't
really
have
json
pardon
me
or
reg
access
unless
we
describe
what
we
mean
by
reg
x's
and
there
at
that
time
was
nothing
very
concrete.
You
know
carson
had
scratched
out
a
proposal,
so
you
know,
as
things
stand
now,
we're
probably
not
going
to
have
rexes
and
filter
expressions
unless
somebody's
willing
to
do
a
bunch
of
work
that
I
haven't
heard
about.
B
Okay,
well,
let's
push
that
on
the
stack
then
and
dive
into
the
issues.
A
Okay,
so
I
guess
the
format
of
today's
meeting
is:
is
that
tim?
Did
you
want
to
cover
your
your
editorial
notes
and
the
things
you
the
the
various
sections
of
the
document,
only
on
list
and
go
through
those
to
start
with,
and
then
we
pick
up
carsten's
issues
cool.
Did
you
want
to
share
a
screen,
or
did
you
want
me
to
bring
up
the
email.
B
So,
anyhow,
having
read
the
draft,
I
came
away
actually
fairly
cheered
up,
because
the
draft
isn't
terrible.
You
know
the
the
the
important
parts
that
you
know
describe
the
syntax
and
the
semantics
are
mostly
pretty
okay,
with
with
editorial
notes
to
be
added,
and
then
a
huge
number
of
our
open
issues
are
all
stuck
down
in
section
four,
the
expression
language
karsten
you've
done
around
since
this
and
everybody's
looked
at
this.
I
think
what
in
here
needs
further
discussion
kirsten.
C
G
C
In
preparing
this
meeting,
I
actually
tried
to
tackle
the
big
things
here.
I
haven't
taken
all
the
small
things
because
yeah
they
are
in
the
end.
They
are
not
so
small
with
the
amount
of
editing
that
is
required,
but
I
think
some
of
these
should
probably
go
into
issues,
so
we
can
have
a
little
bit
more
discussion
about
them
and
some
of
them
are
really
editorial
and
and
we
need
another
editorial
round.
C
So
basically,
I
think
I
get
back
to
this
mail
after
this
meeting,
but
I
think
most
of
it
is
done
at
this
point.
B
Okay,
okay,
that's
good!
The
one
thing
I
wanted
to
raise
here
is
in
the
in
the
a
section
three
five.
B
I
was
hoping
we
would
have
examples.
Do
people
agree
with
that
in
spirit
that
for
each
of
the
selectors.
C
So
there
is
one
issue:
if
I
remember
correctly,
that
asks
for
an
appendix
with
examples,
and
I
think
that
that's
a
pretty
good
objective
to
have
an
exp
appendix
that
has
at
least
one
example
for
each
component
of
of
the
syntax
and
hopefully
of
the
semantics
by
that
as
well.
That's
right.
B
B
Particularly
under
dot
selector,
oh
yeah,
so
dot
selector
dot
wild
card.
All
these
things
in
3.5
right.
D
Yeah
I
mean
I
agree
with
that.
The
only
danger
in
putting
examples
in
early
is
it
sometimes
tricks
people
into
not
actually
defining
the
content
in
a
normative
way.
B
B
Okay,
so
having
said
that,
it
sounds
like
we
have.
We,
the
people
at
least
on
the
call
here,
have
a
somewhat
shared
view
of
the
state
of
the
spec
and
what
we
need
to
do
to
get
finished.
D
D
B
A
Yeah
sorry,
I've
just
been
struggling
to
to
share
the
screen
and
trying
to
triage
it
with
me
to
meet
echo.
I've
started
it
again:
yeah
we're
not
off
to
a
good
start
with
the
technology
this
time
around
I'll.
Let
cast
and
do
the
screen
driving
now
and
you
can
do
your
talking
carsten.
C
So
what
I
did
is
I
I
went
through
the
issues
newest
first
and
try
to
find
out
where
we
are
with
these
issues
that
has
turned
out
to
be
difficult
for
for
about
five
of
them,
because
they
they
are
really
just
streams
of
consciousness,
brain
dumps,
and
it's
not
even
clear
that
this
very
defined
issue
is
defined
there.
Let's
talk
about
them
at
the
end,
so
let
me
talk
about
the
ones
where,
where
I
think
I
understand
what
they
are
about
and
the
most
recent
one
was
127.
C
C
So
that's
maybe
one
thing
where,
where
we
can
think
about
whether
it
should
be
possible
to
search
for
true
or
false
in
a
containable
and
so
on,
so
that's
one
thing
we
would
need
to
fill
in
and
that
that's
not
entirely
trivial.
We
cannot
just
copy
the
json
syntax,
because
jsonpath
has
a
more
lenient
syntax,
so
we
at
least
have
to
patch
that
a
little
bit
and,
of
course,
an
interesting
question
once
you
actually
have
array
and
object
constructors
in
your
value
notation.
C
What
can
you
actually
construct
them
from?
Can
you
only
construct
them
from
literals
or,
but
can
you
also
construct
them
from
results
of
of
nested
queries
and
well,
I
would
say:
if,
if
we
do
all
this,
then
we
we
probably
also
should
allow
path
and
this,
but
maybe
we
should
first
find
out
whether
we
actually
want
to
do
this
on
the
comparison
semantics.
C
I
think
that's
pretty
obvious,
it's
not
the
semantics
defined
by
javascript,
but
it
would
be
a
deep
recursion
to
to
define
equality
and
yeah
in
in
120
or
in
the
interim
two
months
ago.
We
we
said
we
really
just
want
array
literals
composed
of
primitive
values,
so
the
existence
of
this
issue
seems
to
tell
me
that
we,
we
are
reconsidering
this
and
I'd
like
to
hear
where
we
should
go
with
this.
C
B
D
I'm
always
concerned
about
the
element
of
surprise
if
you
have
a
comparison
with
a
a
structured
value
path
on
the
left.
D
B
B
B
C
D
I
mean
my
the
last
comment
from
stefan
agrees
with
my
critique
of
that.
He
says
he
agrees
that
we
shouldn't
deal
with.
B
H
C
Well,
it's
false,
it
makes
sense,
but
it's
false
yeah
you're.
B
Correct
you're,
correct
and,
and
then
you
know,
there's
the
corner
cases
about
the
empty
arrays.
D
I
I
think,
I
think,
if
we
take
out
the
subset
part
of
the
semantics,
the
second
example
becomes
false
and
one
two
three
four.
The
fourth
example
becomes
false
and
the
first.
C
Thing
becomes
true,
yeah,
the
third
one's
true
as
well.
G
B
I
I
was
looking
in
the
the
big
comparison
and.
B
So
this
you
know
this.
This
does
actually
add
noticeable
complexity.
Unless
there
are
voices
saying
they
need
this,
my
instinct
is
to
say:
let's
just
leave
it
with
literals.
Only.
I
I
started
my
crew.
Do
you
hear
me
now.
I
Hello:
everybody
hiya.
Okay,
you
are
discussing
issue
120,
7,
127,
one,
no
27,
okay,.
A
Yep
sorry,
we've
got
daryl
in
the
queue.
J
Hey
just
going
I'm
just
going
through
some
of
the
examples
that
we
use
within
the
overlays
proposal
that
we've
been
working
on
for
open
api,
and
I
can't
think
of
any
scenario
where
we
would
want
to
do
in
with
a
structure.
J
We
do
have
scenarios
where
we
would
want
to
be
able
to
use
in
with
a
with
a
primitive
value.
So
I
I
think
allowing
in
with
primitive
is,
is
a
nice
compromise
and
I
do
see
lots
of
usage
of
queries
across
different
scenarios
with
just
in
of
a
primitive
because
in
with
ids
or
in
with
tags,
you're
looking
for
is
this
tag
in
this
list.
There's
this
id
in
this
list,
but
the
structured
one.
I
I'm
struggling
to
come
up
with
this
scenario
for.
B
Yeah,
my
feeling
is
that
the
literals
matching
literals
in
arrays
is
pretty
easy
to
specify
and
not
that
hard
to
implement.
So
I
would
lean
to
leaving
the
in
operator
in.
C
Yeah,
so
we
only
need
a
value
notation
for
raise
which
right
now
doesn't
exist.
Did
I
have
a
slide
on
that?
No,
oh!
I
I
did
so.
This
production
ray
literal
isn't
defined
at
this
point
in
time,
but
it
should
not
be
too
hard
to
define
it
so
that
that
would
be
the
action
from
this
issue.
D
So,
just
to
be
clear,
the
that
scenario
with
an
array
literal
on
the
right-hand
side
would
be
equivalent
to
a
disjunction.
Yes,
yeah,
okay,
it's
a
bit
more
compact.
C
D
I
mean
this:
isn't
the
precise
issue
we're
talking
about,
but
my
concern
with
the
in
operator
is
when
we
have
a
path
on
each
side
and
when
we
have
a
structured
path
to
a
structured
value
on
the
left-hand
side
and
a
path
to
an
array
containing
that
structured
value
on
the
right-hand
side.
And
then
I
think
it
violates
the
principle
of
least
surprise.
B
C
C
I
think
we
have
pretty
good
consensus
for
what
it
means
in
the
boolean
case,
but
we
haven't
really
discussed
what
it
means
in
a
comparison
case,
and
this
would
be
essentially
inheriting.
G
B
I
mean
sorry
primitives
only
yeah,
but
literals
literals.
Only
no,
no
paths
on
the
left
side.
C
The
the
more
interesting
question
is:
what
happens
if,
if
it's
on
the
right
side,
because
then
you
have
a
note
list
and
is
that
actually
the
same
as
an
array,
or
do
we
extract
arrays
from
these
nodes
that
that's
not
where
defined
and
on,
on
the
left
hand,
side?
Of
course,
if
the
path
is
a
note
list
with
more
than
one
element.
A
B
Json
stuff,
not
not
node
lists,
and
you
know
these
examples
here
and
from
stefan
are
presented
that
way
in
terms
of
json.
B
C
If
you
write
a
json
path,
you
might
might
have
in
in
your
mind
that
you
have
nailed
down
a
specific
node
with
the
path
expression
and
then,
of
course,
the
semantics
are
symbol,
just
extract
the
value
from
that
node
and
compare
it
as
as
we
would
compare
a
value
on
that
left
hand
side,
and
if
that
value
is
structured,
it
cannot
match
anything
on
the
right
hand
side,
because
we
only
have
simple
values
in
the
array.
Literally,
that
that's
easy,
but
if
the
path
actually
gives
you
several
candidates,
what
does
that
mean?
C
B
So
so
daryl,
what
would
the
shape
of
the
queries
you
might
like
to
do?
Look
like
would
would
it
would
you
know
you
would
you
say,
dollar
dot
a
dot
b
in
you
know:
dollar,
dot,
c
dot,
d
kind
of
thing.
J
We
use
it
this
particular
in
the
opposite
case,
so
we
have
a
notion
of.
I
want
to
apply
this
or
merge
this
change
if
this
literal
trait
exists
in
the
list
of
traits
associated
with
the
target,
so
the
the
path
is
querying
into
the
dark
for
an
array,
and
we
want
to
know
whether
a
particular
literal
is
in
that
list.
B
B
C
B
J
J
C
C
Okay,
but
we
already
can
do
that
with
a
filter
expression,
so
the
the
simple
case
where
we
just
want
to
know
whether
it's
there
or
not
doesn't
need
the
in
operation
that
can
be
done
with
the
filter
expression
and
if
the
filter
explosion
impression
is
empty,
then
you
don't
have
a
match
and
if
the
filter
expression
is
not.
C
I
I
think
I
didn't
cut
it
right.
Carson
your
example
at
color
in
dollar,
dot,
dot
allowed
color.
I
I
was
thinking
about
loud
colors,
so
returning
an
arrow,
an
array
of
arrays,
but
this
example
with
a
lot
of
fruits
and
note
lists
of
fruits
and
then
selecting
all
blue
fruits
is
a
nice
example
where
we
generally
are
generating
an
array
of
object
members
and
then
query
by
the
in
operator.
If
that
color
in
this
case
is
included
or
is
found
in
this
array,.
I
This
requires
to
to
turn
a
note
list
into
an
array,
and
this
is
the
only
one
in
the
spec
where
we
demand
this.
C
I
C
D
I
D
Go
ahead,
yeah.
Another
way
to
sidestep
this
issue
is
the
approach
I
pointed
to
before
in
proposal,
a
which,
rather
than
allowing
a
general
path
on
the
right-hand
side
of
in,
would
have
a
more
restrictive
path,
which
should
only
deliver
a
node
list
of
maximum
size.
One
so
we'd
have
to
be
an
empty
node
list
which
would
yield
the
value
of
the
result
false
or
it
would
be
no
less
than
a
single
value
and
then
we'll
be
testing
against
that
single
value.
D
J
J
So
it's
find
me
the
company
that
has
a
location
in
the
city
of
detroit,
so
there
I
mean
I
would
use
a
filter
and
in
the
filter
condition
I
would
have
an
in
and
I
would
want
to
do
in
and
I
would
want
to
have
a
path
on
the
right
hand,
side
of
the
n
that
digs
into
the
locations
and
pulls
out
the
cities
that
each
company
is
present
in,
and
there
may
be
multiple
cities
that
the
company
is
present
in.
B
B
So
if
you
had
a
city
field
in
your
objects,
you
could
do
it
with
an
existing
filter
expression.
Fine.
If
the
city
field
were
an
array,
oh.
J
C
C
I
B
Okay,
so
so
examples
would
be
helpful,
as
you
said
at
the
moment,
based
on
this
discussion,
I'm
I'm
having
difficulties
seeing
where
an
in
operator
with
just
an
array
lateral
on
the
right
is
interesting
and
valuable.
B
Yeah,
I
don't
have
a
strong
opinion
on
this.
I
never
having
used
this
construct
myself
in
jason
pass.
I
just
don't
have
a
strong
feeling
for
how
useful
it
really
is
and
whether
it's
worth
the
work
to
to
put
it
into
the
spec
it
sounds
like
you
know,
most
most
of
the
kinds
of
things
we're
talking
about
can
be
done
with
filters.
I
B
I
B
I
I
B
Right,
does
anybody
have
an
opinion
on
that?
That
strikes
me
as
as
requiring
us
to
define
object,
equality
have
we
we
haven't
done
that
yet
anywhere
else
have
we.
C
C
And
I
would
say
it
is
near
trivial
to
do
that,
that
there
are
way
more
complicated
parts
in,
for
instance,
equality
of
strings
than
inequality
of
arrays
and
objects,
but
yeah,
it
just
adds
one
additional
thing
you
have
to
think
about.
So
this
is
not
about
in
this
is
about
equals.
Equals
would
allow
values
on
on
both
sides
that
that
are
structured
and
then
the
next
question
is:
how
far
do
we
go
with
the
value
notation
for
these
values?
So
are
we
able
to
notate,
arrays
and
and
objects?
C
B
Sorry,
I
don't
really
have
guidance
to
offer
here.
I
I
I'm
in
favor
of
keeping
the
spec
as
simple
as
possible,
but
if
there-
but
you
know
it
does
sound
like
a
tractable
drafting
problem
to
to
define
what
the
literals
look
like
and
and
produce
surprise
free
results.
But
it's
a
substantial
piece
of
work.
So
I
think
I
what
glenn
said
I'd
want
to
see.
I'd
want
to
see
use
cases.
A
A
A
G
Yeah
yeah,
there
are
examples
pretty
much.
The
goal
of
that
draft
is,
I'm
not
sure
if
you're
familiar
with,
who
is
for
domain
names,
art
app
is
a
json
version
of
who
is
and
pretty
much.
The
need
is
to
be
able
to
explicitly
specify
what
data
has
been
redacted
for
privacy
reasons,
and
so
one
approach
that
was
being
discussed
wasn't
used
like
placeholder
text
and
that
sort
of
thing,
but
the
decision.
G
Was
within
the
working
group
was
to
create
an
extension
to
explicitly
specify
which
of
the
json
members
have
been
redacted,
so
you
can
tell
the
difference
between
it,
non-existence
and
redaction.
So
pretty
much.
There's
the
use
of
json
path
to
formally
define
what
members
have
been
redacted
now,
there's
a
combo
of
whether
or
not
there's
redaction,
of
object
numbers
or
of
arrays,
because
rdap
actually
includes
the
use
of.
G
The
name
of
it
already
fixed
length
arrays
that
include
contact
data
that
you
pretty,
you
can't
remove.
You
just
have
to
clear
it,
so
we
need
to
have
the
ability
to
specify
positions
within
an
array.
So
there
are
examples
within
the
draft
of
the
use
of
jsonpath.
So
if
you
review
it
and
take
a
look,
please
provide
any
feedback
related
to
any
changes
that
you're
thinking
that
you're
you're.
Considering
in
this
draft
and
whether
or
not
it
needs
to
be
fixed
in
the
rdap
redaction
act.
B
So
james,
I'm
looking
at
your
first
example
here,
just
above
section,
four,
okay
and
yeah,
I
need.
B
G
I
read
this
properly.
I
did
validate
the
the
json
path
which
which
application
used
to
validate
them,
but
they
they
were,
they
were
act.
They
were
correct
at
the
time
yeah.
B
You've
got
a
a
a
new
line,
a
return
in
the
middle
of
your.
B
G
B
G
Is
not
you
know,
honestly,
the
there
is
a
the
name
which
we're
going
to
be
setting
up
in
iana
registry
as
well,
to
enable
for
a
more
human,
readable
indication
of
what
the
redacted
member
is,
but
then
to
have
the
actual
expression
language
for
software
to
be
able
to
identify
elements.
G
G
That's
used
in
art,
app
to
express
contact
data,
and
so
that
uses
a
heavy
dose
of
fixed
length,
arrays
and
so
to
be
able
to
redact.
Let's
say
I
don't
know
a
telephone
number
in
j
card.
It's
not
removal,
it's
actually
blanking
out
or
having
to
be
a
null
string.
B
Got
it
these
examples
are
useful
thanks,
but
on
the
face
of
it
it
looks
to
me
like
they're
all
filters,
we're
not
really
using
the
n
operator.
G
B
D
It's
yeah,
I
agree
entirely,
but
others
are
pushing
for
this.
So
let
them
speak.
J
C
Would
use
the
filter
expression
you,
you
would
use
the
value
that
you're
looking
for
as
as
the
comparison
value
in
a
filter
expression.
So
you
you
just
filter
out
all
the
instances
that
have
that
value
and
if
that
list
of
instances
is
empty,
then
you
don't
have
a
match
and
if
it's
not
empty,
you
have
a
match.
J
C
Yeah,
so
then,
you
have
nested
filter
expressions.
You
have
a
inner
filter
expression
that
goes
through
the
array
and
gives
you
those
array
entries
that
actually
are
what
you're
looking
for
in
the
end,
you
either
have
a
match
or
you
don't
have
a
match
and
you
use
that
boolean
to
actually
control
an
outer
filter.
That
gives
you
the
objects
that
have
this
array
right
and
that's.
B
Okay,
I'm
starting
to
hear
that
we're
not
100.
We
are
not
at
the
moment
convinced
that
in
really
adds
value
as
anything
more
than
syntactic
sugar,
and
even
at
that
level,
there's
not
a
lot
of
huge
demand
for
it
carson
as
well.
One
of
us
should
should
write
that
query.
I'm
going
to
have
to
go
off
and
ready
to
convince
myself
if
it
works,
but
I'll
take
your
word
for
it.
B
B
C
I
C
B
Quite
a
bit
of
time
in
this,
shall
we
for
the
moment
declare
that
we
will
simply
not
use
this
operator,
and
you
know
note
that
it's
easy
to
add
back
in
if
real
demand
manifests.
G
C
We
only
have
about
36
left,
so
there
is
a
proposal
for
an
extension
that
that
kind
of
adds
x
include
to
the
jsonpath,
and
I
would
like
to
not
do
this.
C
A
Speaking
as
an
individual,
I
think
that
this
should
be
another
ex
part
of
whatever
we
do
in
the
extension
space.
E
C
Yeah,
actually,
the
main
problem
with
the
proposal
is
that
it
destroys
data
transparency,
so
you
no
longer
can
have
every
json
string
value
in
your
input
document,
because
some
of
these
string
values
suddenly
mean
something
else
and
that's
a
pretty
big
step.
A
Unfortunately,
the
both
greg
and
the
aforementioned
author's
name
is
not
here.
I
don't
think.
A
I
think
what
we
probably
should
do
is
comment
on
the
issue
with
with
sort
of
the
consensus
from
this
meeting,
that
I
think
we
should
include
this
in
the
base
rfc.
But
we
should
leave
it
open
that
it
should
be
possible
when
we,
if
we
support
extensions.
C
Yeah,
the
fun
part
is
that
this
can
be
framed
as
a
preparation
step
before
you
apply
the
actual
json
path
processing.
So
it
could
be
a
completely
diff
different
part
of
the
processing
model
and
wouldn't
influence
json
path
at
all.
That
doesn't
mean
you
would
implement
it
this
way,
but
it
would
be
defined
that
way.
B
Okay,
so
somebody
will
take
the
action
item
to
write
a
comment
on
the
issue
about
this,
who,
who
can
sign
up
to
do
that?
I
can
okay.
Thank
you
kirsten.
C
Thanks
oops,
what
happened?
Oh
yeah
number
123
is
absent
equal
to
absent,
so
we
are
now
in
the
the
realm
of
comparison
semantics
and
we
we
have
json
values
that
we
can
compare
with
currently
just
primitive
values,
and
we
have.
C
B
I
see
the
javascript
behavior
is
that
undefined
equals
undefined.
B
J
B
Well,
and
as
who
is
it
as
daniel
parker
writes
in
j
way,
you
would
it,
you
know
you
get
that
match,
can
never
work.
I
Converted
to
false
must
be
true,
but
I
think
we
need
to
distinguish
these
cases,
and
this
is
a
little
problem,
but
it's
no
problem
to
handle
these
two
undefined
comparisons
like
javascript,
not
a
number
where
we
are
not
a
number,
is
not
equal,
not
a
number
in
javascript.
It's
we.
I
think
we
we
are
free
to
define
it.
C
C
C
So
if,
if
I'm,
comparing
two
issues
and
and
one
issue
doesn't
have
a
pull
request
and
the
other
one
also
doesn't
have
a
pull
request,
why
why
shouldn't
that
be
the
same.
B
I
I
I'm
not
quite
sure
what
both
both
arguments
have
some
little
truth.
I
I
think
it's
a
definition
thing.
I
can't
remember
how
many
implementations
to
equal
and
how
to
unequal
yeah.
J
B
So
you
had
the
use
the
one
use
case
of
you
know:
what
was
it
with
prs
with?
No
something
or
other.
C
B
C
C
B
I
I
C
Yeah,
so
you
whatever
we
decide,
you
can
always
write
an
existence
test
that
inverts
what
we
decided.
So
the
question
really
is:
which
is
the
the
default?
What
happens
if
you
don't
further
specify
it
with
an
existence
test
and
yeah?
My
gut
feeling
is
that
that
undefined
is
the
right
thing
so
to
to
paths
that
create
no
nodes.
B
B
C
Yes,
I
think
we
just
successfully
got
rid
of
this
problem.
C
Yeah
here
the
we
don't
have
an
in-operator
anymore
and
we
have
we
haven't
defined.
What
a
ray
x
operator
is.
So
maybe
we
can
skip
this
one
as
well.
C
C
I
think
it's
it's
pretty
clear
that
we
fetch
the
value
that
is
at
that
place
and
we
we
still
have
to
find
out
what
we
do
if
there
is
no
such
value,
but
this
is
the
undefined
versus
nan
problem,
but
for
a
boolean
context,
we
had
some
discussion
on
whether
we
go
with
one
of
those
truthiness
things
or
turn
at
fu
in
a
boolean
contest
context
to
a
pure
existence
test,
and
my
proposal
is:
yes,
it's
an
existence
test,
and
there
are
two
reasons
for
that.
C
One
is
we
don't
have
any
other
way
to
do
an
existence
test,
and
this
is
the
best
and
shortest
way
to
do
it,
and
second,
it
gets
rid
of
the
truthiness
weirdness
that
we
all
love
in
in
javascript
is
an
empty
array.
True
or
false
is
an
empty
object,
true
or
false,
and
so
on.
It's
a
string
with
a
single
zero
character
and
a
true
or
false
is
a
string
with
two
zero
characters
and
12
volts.
B
B
J
C
C
One
eight
yeah,
I
think
that's
just
the
same
issue
and
probably
we
can
resolve
it
in
the
same
direction.
C
So
this
may
be
a
place
where
you
want
to
to
do
some
extension
sooner
or
later,
but
I'm
I'm
happy
with
that
as
the
basic
behavior.
So
it
would
essentially
be
a
byte
string
comparison
if
you
think
in
utf-8
or
a
code
point
sequence
comparison
if
you
think
in
unicode
code
points,
and
we
can
always
go
ahead
and
edit
normalizing
later
and
we
probably
would
add
a
normalizing
comparison,
but
also
a
normalizing
indexing,
and
that's
maybe
something
that
people
don't
have
in
mind
when
they
discuss
this.
So
if
I'm
looking
for,
I.
B
B
B
And-
and
I
think
you
know
if
you
look
across
the
spectrum
of
iatf
rfcs,
the
the
practice
is-
is
very
uniform
that
don't
normalize
just
don't.
C
Well,
it's
a
little
bit
more
subtle,
but
yeah
you
don't
just
normalize
everything
upon
ingestion
that
that
it
was
a
mistake
that
should
never
be
done
by
the
way
to.
B
Be
better,
I
think
I
prefer
code
point
comparison
to
a
byte
string
comparison
because
that
you
know
you
might
be
using
java
and
it's
actually
utf-16
inside
your
code.
You
know
you
don't
have
to
look
at
bytes
right.
F
C
Yeah,
I
think
that
the
question
was:
can
can
your.
C
F
I
H
I
I
think
I
understand
the
the
question
now
again.
We
we
we
do
have
a
problem
to
select
from
the
argument.
I
A
member
named
a
or
d,
it's
simply
not
possible
you
all
we
can
do
is
iterate
over
the
argument
and
we
get
the
values
of
each
member,
but
we
cannot
address
the
key.
So
the
the
the
subject
of
this
issue
was
in
the
end.
I
I
think
that
we
need
something
like
at
key
or
a
function
to
address.
The
key
of
that
current
selected
member
or
element
makes
no
sense,
but
the
key
of
a
member.
I
I
I
I
C
B
G
C
I
C
I
All
we
can
do
is
to
iterate
over
all
members
of
the
top
level
object
and
ask
for
their
values,
but
we
cannot
ask
for
the
for
the
key.
So
it's
simply
not
possible
to
answer
the
question
via
a
query:
does
top
level
object?
Have
a
member
called
named
a.
I
C
C
G
B
I
C
D
D
J
It's
interesting
because,
because
we've
noticed
the
problem
properly
in
the
spec,
we're
doing
we
started
with
james
bath
and
james
path
is
optimized
for
projections
and
isn't
as
good
at
actually
pointing
at
things.
It's
maybe
maybe
the
answer
is
you're
using
the
wrong
tool
for
the
job.
If
you
want
to
do,
projections.
J
I
J
But
again
I
think
you
know
we
should
probably
hunt
for
examples
as
to
specific
cases
where
that's
absolutely
neat,
because
it
is
only
a
problem
at
the
root
right.
J
B
So
where
are
we
coming
in
on?
I
think
I
think
we
acknowledge
the
issue.
The
you
know.
The
issue
is
a
real
issue.
So,
first
of
all,
are
we
interested
in
trying
to
solve
it.
I
It's
a
fact
that
this
issue
did
come
not
very
often
in
the
past,
so
it's
not
a
very
important
issue.
I
think
I
tried
mentally
to
put
this
object
in
the
first
comment,
one
level
deeper
and
even
then
you
cannot.
H
C
C
C
So
typically
when
I
would
write
a
query,
I
would
then
tell
the
api,
oh
by
the
way,
only
give
me
the
first
20
hits
that
I
would
see
that
in
the
api.
But
of
course
there
are
cases
conceivable
where
you
want
to
have
pagination
inside
a
json
path.
Expression,
I'm
just
having
a
hard
time.
Thinking
of
such
cases.
J
J
Because
I
may
want
to
present
those
on
the
ui,
I
may
be
only
interested
in
getting
some
sample
set
of
data
to
play
around
with.
There
may
be
a
thousand
objects
in
the
target
document,
but
I
only
want
to.
I
only
need
a
few
in
order
to
achieve
my
goal
and
rather
than
returning
the
full
results
and
then
throwing
the
rest
away.
I
I
think
we
need
to
decide
if
we
want
to
allow
or
support
some
kind
of
post
processing
of
the
results
of
a
query
which
I
would
suggest
that
this
happens
here
or
to
extend
the
query
capabilities
to
do
exactly
that
so
return,
only
the
last
five
or
the
first
five,
or
something
in
somewhere
in
the
middle
five
elements
of
the
of
the
result.
Note
list.
J
B
C
G
C
Limit
we
have
offset
we
have
order
by
which
is
pretty
important
if
you
only
want
to
have
a
limited
number
of
results,
so
that
would
need
to
be
part
of
that
extension.
A
But
then
I'm
cognizant
of
time,
because
we've
got
only
about
seven
minutes
left
and
glenn.
You
said
you
wanted
to
cover
regular
expressions
which
is
still
a
handful
of
slides
down.
Is
that
something
we
might
want
to
cover
and
then
leave
a
couple
more
minutes
to
wrap
up
and
perhaps
discuss
when
we
might
have
our
next
meeting?
If
we
are
having
an
interim
sure
cool.
B
Is
the
first
option
open
to
us?
Is
there
a
regular
expression
flavor
that
we
could
select.
B
I'm
trying
to
swap
in
this
discussion
we
didn't
like
xsd
for
some
reason.
D
I
guess
my
concern
is
that
regular
expression,
syntax
and
semantics
seems
like
an
orthogonal
concern
to
jsonpath.
D
We
ought
to
be
able
to
mix
and
match
so
you
know
I
prefer
to
not
to
have
to
freeze
or
pick
a
particular
regular
expression
syntax
in
the
standard,
but
to
allow
you
to
make
some
matches,
so
you
could
then
have
json
path
over
xsd
or
jsonpath
over
re2
or
whatever
regular
expression
language.
You
choose
it.
Obviously
the
limit's
interoperation,
but
I
think
it's
it's
more
attractive
for
standard.
B
I
would
hope
that
the
same
the
same
json
path
applied
to
the
same
argument
would
produce
the
same
result.
Modulo
ordering
consistently.
D
Yeah
I
mean
what
I
had
in
mind:
was
that
jason
path
over
princess
re2
would
interoperate
perfectly
with
jason
path
over
re2,
but
not
necessarily
perfectly
with
jason
path.
Over
xsd.
C
Well,
first
of
all,
regular
expressions
are
a
mathematical
concept
that
that
is
expressed
in
these
various
forms
of
real
world.
Regular
expressions,
and
some
of
them
are
going
pretty
far
away
from
the
concept
of
regular
expressions
like
like
pcie
and
ecmascript.
That
was
built
from
pcie
and
some
are
rather
closer.
C
You
can
actually
use
the
implementation
of
regular
language
to
to
implement
this,
so
that
that's,
for
instance,
true
for
the
xsd
regular
expressions
so
by
by
defining
a
subset
that
is
essentially
within
the
the
field
of
chomsky
type
3
languages,
the
mathematical
form
of
regular
expressions.
C
B
And
implementers,
you
know,
aren't
I
suspect,
in
most
cases
going
to
be
thinking
about
the
chomsky
type
they're
going
to
be
thinking
about
what
library
can
I
use,
because
you
know
I
don't
think
a
json
path.
Implementer
should
have
to
also
implement
regular
expressions.
They
should
be
able
to
say
regex.match.
D
Yeah,
that
was
my
concern
really,
if
you
have
to
build
up
a
mapping
to
your
whatever
your
language
library
is
for
regular
expressions
and
do
do
a
mapping
of
iregxp
or
whatever.
Then
it's
puts
a
big
burden
on
the
implementer.
J
I
will
say
that
most
of
the
people
I
interact
with,
who
are
interested
in
working
with
jason
path
are
also
in
parallel,
working
with
jason
schema,
and
so
they
have
their
they've
picked
their
particular
flavor,
and
there
would
be
value
at
least
to
that
part
of
the
audience
to
doing
something
very
similar.
B
B
D
Well,
could
we
also
include
my
option,
which
was
to
factor
out
the
regular
expression,
language,
yep.
B
A
A
Should
we
be
scheduling
an
interim
meeting
before
then
say
in
january
or
february
after
new
year.
A
Okay,
perhaps.
B
B
Okay:
okay,
okay!
Thank
you,
everybody!
This
has
been
super
constructive
and
I
think
we've
pushed
this
thing
a
little
further
uphill,
and
I'm
optimistic
that
we
have
a
finish
line
inside
if
we
can
figure
out
what
to
do
with
reggae.