►
From YouTube: JSONPATH WG Interim Meeting, 2021-05-11
Description
JSONPATH WG Interim Meeting, 2021-05-11
A
I
suppose
we
might
as
well
get
started
kirsten
stuck
his
head
in,
and
I
said,
he'd
be
he'd,
be
back
in
a
couple
of
minutes,
so
welcome
everybody.
Thank
you
for
coming
out
to
the
interim
meeting
of
the
itf
jason
path,
working
group.
I
guess
I'm
the
only
new
world
person
on
here.
So
it's
good
morning
to
all
of
you.
A
Once
again,
as
at
all
iatf
meetings,
this
applies
by
joining.
You
agree
to
certain
conditions
which
are
listed
here.
They
keep
changing
this.
If
you
haven't
read
this
for
a
while,
you
might
want
to
read
it.
I
recommend
doing
so.
A
Okay,
fair
enough,
so
note
takers.
Since
I
I
don't
have
a
lot
of
strong
opinions,
I'm
going
to
be
taking
notes.
Does
anybody
will
anybody
else
take.
A
Do
we
have
a
requirement
for
a
jabber
scribe
james?
Do
you
see
anybody
joining
us
on
jabra
on
jabber.
A
Okay,
I
think
we
might
as
well
proceed
to
discuss
our
agenda.
I
think
that's
the
next
slide
there,
james.
A
Right
so
I
had
suggested
the
first
three
listed
here:
glenn
had
added
the
the
duplicates
issue.
I
think
we
have
a
good
chance
of
making
good
progress,
and
I
also
think
that
these
are
big
and,
to
the
extent
that
we
have
blockers
that
they
would
be
included
here.
A
I
don't
hear
a
lot
of
voices
going.
A
A
A
Repeated
so
stefan,
I
know
you
in
a
note
here.
I
noticed
that
you
said
in
in
the
email
list.
I
I
I
think
you
said
something
like
you
think
we
are
in
good
shape
on
the
terminology
issue,
that's
my
opinion.
We.
C
D
A
I
have
some
opinions
on
this,
but
I
I'm
they're
not
that
strong.
So
I
have
not
so
I
don't
want
to
really
advance
them.
Does
anybody?
So
if
I
understand
the
state
of
the
discussion,
there
was
some
sentiment
that
we
should.
You
know,
stick
to
8259
terminology
where
possible
and
introduce
you
know
terms
as
necessary
to
improve
readability.
A
There
was
a
specific
issue
that
you
know
where
everything
we're
talking
about
is,
in
fact,
a
json
value,
with
the
exception
of
member
names
in
in
objects,
everything
is
a
json
value
and
that
it
would
be
reasonable
to
have
something
shorter
to
use
to
in
the
case.
So
we're
not
saying
just
in
value
adjacent
value,
adjacent
value,
all
the
time
there
were
candidates
for
what
work.
What
word
to
use
there,
such
as
node.
E
I
don't
think
we
have
to
start
from
january
here,
so
we
we
have
a
few
things
that
are
in
the
document.
That
probably
don't
need
to
be
revisited,
and
we
have
a
few
open
issues
around.
E
How
do
we
actually
call
the
things
that
that
we
put
into
indexing
filters
and
how
do
we
call
the
syntactic
elements
of
the
jsonpath
query,
so
we
we
have
had
index
indexing
key
for
the
first
thing,
I
think
we
are
pretty
clear
that
the
the
answer
to
the
second
thing
is
selector,
but
of
course
there
are
a
few
details.
We
we
have
to
understand
about
what
kinds
of
selectors
we
have
and
whether
there's
any
useful
terminological
grouping
of
these.
E
E
Yeah,
so
I'm
essentially
saying
that
maybe
we
need
a
term
for
all
those
selectors
that
are
really
indexing
and
that
probably
is
useful
to
have
a
term
like
indexing
selector.
That
includes
the
the
three
kinds,
and
I
think
we
haven't
really
decided
whether
the
these
are
actually
different
kinds.
So
the
the
current
draft
has
an
index
selector
as
a
special
case
of
a
union
selector,
and
you
might
also
have
an
index
selector
as
a
special
case
of
a
slice
selector.
E
So
it's
maybe
not
that
helpful
to
actually
separate
them
out
into
different
categories.
F
Is
that
a
selector
is
the
operator
so,
whether
it's
a
dot
operator
or
like
a
dot
name
or
it's
a
bracketed
selector
or
whichever
the
selector
is
the
the
encompassing
thing
an
indexer
would
be
specifically
the
bracket
operator
or
the
bracket
selector,
and
the
indexes
would
be
the
things
in
there.
F
G
E
Yeah,
I
think
we
have
pretty
much
consensus
on
this,
the
maybe
a
little
bit
of
wiggling
current
items.
He
like
the
is
that
exactly
the
best
term,
but
I
think
the
the
overall
structure
of
this
is
pretty
much
consensus.
Now.
E
The
other
half
I
didn't
comment
on
that
part
of
your
your,
so
we
we
had
the
the
word
key.
We
had
the
word
indexing
key,
so
that's
the
other
part
that
I
think
we
need
to
decide
on
this
ticket.
A
Looking
at
stefan's
list
here,
you're
talking
about
the.
E
I
thought
so
sorry,
I'm
I've
lost
this
right
here,
a
little
bit.
Can
you
so
the
the
point
is
just
that
we
have
we're,
often
in
a
situation
where
you
can
can
supply
either
an
array
index
or
an
object.
Member
name
right
and
it's
useful
to
have
a
common
term
for
these
two
subterms
right.
Yes-
and
stefan
is
proposing
index
here,
and
I
was
previously
proposing
indexing
key
or
something
like
that-
I'm
not
strongly
attached
to
that.
H
A
E
I
I've
got
concern
about
the
use
of
the
word
index
in
that
it.
For
me,
it
carries
array
connotations,
and
so
I'd
like
to
see
the
pr
that
comes
out
of
this
to
know
whether
in
the
ways
in
the
places
this
is
used,
it
gives
that
impression.
I
F
The
I
I
come
from
a.net
world,
where
I'm
primarily
in
c
sharp,
and
so
when
we
build
an
indexer,
we
can
use
various
data
types
for
the
values
that
go
in
that
index.
You
can
use
a
string.
You
can
use
an
integer.
You
can
really
use
anything
that
creates
a
hash
value.
F
I
suppose,
or
any
any
data
type
would
work
inside
of
an
index.
Some
would
be
more
awkward
than
others,
but
for
me,
having
that
understanding
that
any
data
type
can
be
an
index
makes
having
index
a
bit
more
of
a
general
use
term.
But
I
totally
understand
where
index
does
have
a
array
connotation
as
well.
A
Yeah
the
trouble
is
that
key,
I
think,
has
an
object
connotation.
So
we
I've
seen
a
proposal
for
a
truly
neutral
term.
Having
said
that,
I'm
okay
with
either
of
these,
so
I'm
going
to
shut.
A
J
I
just
wanted
to
add
something.
Sorry
in
it
doesn't
seem
that
this
summary
captures
the
state
where
the
array
slice
selector
is
part
of
of
is
a
is
an
index
because
it
can
be
repeated
in
the
union
selector.
K
J
And
the
the
the
additional
problem
is
that
this
the
index
cannot
be
expressed
just
as
a
degenerate
form
of
the
slice
expression,
because
then
the
key,
the
non-integer
key
select
the
key
index
is
not
a
valid
start
value
in
the
in
the
slice
expression
or
it's
not
now.
J
So
I
think
we
were.
We
were
wondering
whether
we
can
kind
of
call
us
some
of
those
cases
as
a
special
case
of
something
else
right.
So,
for
example,
the
union
selector
is
a
good
candidate
because
a
union
of
one
basically
subsumes
the
the
what
we
call
the
index
index
selector
that
contains
only
one
index,
but
the
index
the.
If
we
only
have
one
value
in
it
or
only
a
union
selector
of
multiple
indices,
they
can
be
either
strings
or
numbers.
J
So
that's
fine,
but
if
we
also
want
to
subsume
the
slice
expression
in
in
in
the
same
picture
and
having
a
index
a
single
index
just
to
be
the
degenerate
form
of
this
slice,
selector,
where
we
only
have
the
start
and
the
end
and
step
are
omitted.
That
wouldn't
cover
the
case
where
the
index
is
a
string
value,
namely
as
a
key.
J
F
F
I
would
say
a
union
can
can
union
for
lack
of
a
better
word.
Any
of
these
acceptable
values.
A
Okay,
so
I'm
not
hearing
strong
issues
of
principle
being
expressed
here
that
this
particular
option
is
wrong,
or
this
other
particular
option
must
be
used.
So
this
is
starting
to
smell
to
me
like
an
editorial
issue,
where
we
should
hand
it
to
our
editors
and
if,
in
fact,
we
then
object
specifically
to
formulations,
we
should
object.
We
should
do
so.
E
A
E
We
we
should
give
the
editors
a
direction
to
go
and
then
the
the
truth
truth
is
in
the
actual
wording.
So
the
editors
have
to
have
a
little
bit
of
leeway
of
fixing
things
when
they
note
something.
We
that
look
good
on
a
napkin,
that
this
doesn't
work
in
the
actual
text,
so
that
let's
agree
directions
here,
but
not
all
the
final
details.
G
E
Talk
say
we
are
now
comfortable
taking
off
with
that.
We
can
go
to
the
next
item.
F
I
I
have
a
proposal
here
supposing,
when
we
call
an
index
whether
it's
an
index
is
the
the
string
or
number
and
you
have
a
slice
or
a
filter
selector
those
are
the
things
that
can
go
in
the
brackets.
F
F
C
C
C
C
This
is
the
term
which
is
currently
called
node.
Maybe
we
define
node
is
the
same
as
index
value
pair,
but
I
still
haven't.
C
F
Field,
yes,
are
you
talking
when
you
say
index
value
pair?
Are
you
talking
about
looking
at
the
the
input,
data
and
finding
a
specific
location
and
and
the
value
at
that
location.
L
C
C
C
C
I
C
I
Just
may
I
take
a
quick
digression
to
say:
I'm
not
sure
who's
going
to
write
the
pr
for
this
or
in
general,
who's
going
to
write
pr's,
because
the
term
editor
to
me
has
a
connotation
of
someone
who
receives
prs
and
then
makes
comments
on
them
and
emerges
them,
and
so
we're
I'm
really
looking
for
for
who's
going
to
author,
the
pr
pr's
that
go
into
the
spec
and
who
sees
that's
a
bit
their
role.
I
Maybe
that's
another
agenda
item
we
could
add
on
to
any
other
business,
but
I
tried
to
bring
it
up
on
the
list.
I
just
mentioned
it
here
because
we
are
bringing
our
hands
saying
it'd
be
great
when
we
get
to
a
pr
and
yet
I
don't
hear
anybody
saying
it's
possibly
carsten,
I'm
going
to
write
a
pr
for
this.
F
Now
that
I've
got
a
building,
I'm
happy
to
start
start
writing
stuff,
but
I
got
it
building
as
of
like
15
minutes,
or
I
guess
now
about
30
45
minutes
ago.
So
fantastic.
A
So
it's
clearly
the
sense
of
the
of
the
working
group
that
we
need
a
pr
here
and
that
I
I
personally
think
that,
given
a
pr,
we
should
be
able
to
progress.
A
A
F
I'll
take
the
the
terminology
stuff.
F
A
Anybody
can
write
a
pr
of
course,
but
I
think
it
would
be
useful
in
this
meeting
if
we
have,
if
we,
if
we
create
an
expectation,
we're
going
to
see
one
from
somebody
in
the
near
future,.
A
Okay
and
it
oh,
are
we
still
sticking
with
the
ner
with
the
term
node?
Yes,.
J
A
Does
that
language
appear
in
the
draft
the
pairing?
I
don't,
I
think,
the
language
the
draft
talks
about
when
we
are
considering
it
in
a
locational
context
or
something
like
that.
A
C
I
don't
have
any
objections
to
the
term
if
we
consider
the
json
root
and
below,
as
as
a
kind
of
tree,
then
node
makes
sense,
and
this
specific
node
can
be
isolated
by
its
index
value
pair
or
from
the
root
look.
Its
location
is
defined
by
its
path.
A
Was
going
to
be
issue
number
59
relative.
A
A
Now
I
think
that
the
use
of
relative
paths
in
jsonpath
is
is
is
is
not
controversial
if
I'm
correct,
the
open
issue
is
whether
we're
going
to
support
the
the
at
sign
relative
path,
as
at
as
in
the
root
position
of
a
json
path
at
the
front
of
adjacent
path
at
the
middle
level.
Do
people
agree.
That
is
what
we're
talking
about.
I
I
thought
it
was
also
using
at
outside
the
filter
expression,
but
not
necessarily
the
front
of
the
selector.
I
I
I
think
there
were
examples
given
given
in
this
by
david
weren't
there
a
deleted,
but
personally
I
don't
favor
it,
I'm
just
pointing
out
that
I
think
that
was
under
discussion
and
haven't
yet
been
finalized.
E
C
That
it
took
a
long
time
for
me
to
to
understand
what
what
the
use
case
is
for
for
this.
C
F
That's
what
david's
point
was
or
david,
so
what
he
would
be
doing
is
he
would
be
saying
that
there's
some
external
tool
which
has
navigated
partially
into
some
json
input
and
has
a
path
and
wants
to
be
able
to
take
that
path
and
navigate
relative
to
where
he
has
navigated.
C
F
F
F
I
think
it
makes
sense
to,
in
some
cases
to
go
back
to
the
root
for
some
things,
but
in
other
cases
to
be
able
to
specify
the
local.
J
So,
basically,
what
I
was
trying
to
write
there
is
the
difference.
So
if
you,
if
you,
if
I
understand
correctly
what
stefan
was
saying
we
could,
if
all
we
want
to
do,
is
just
to
drill
down
and
just
continue
doing
stuff
from
where
we
stopped,
then
we
can
just
reevaluate
the
remake
the
query
by
passing
a
new
argument,
the
current
node
as
the
argument,
and
then
you
use
the
dollar
from
there.
J
So
the
only
case
where
we
wouldn't
want
to
do
that
is
when
we
want
to
kind
of
go
back,
go
back
above
the
the
current
route
by.
J
G
E
C
E
E
So
if
I
have
a
copyright
statement
at
the
top
of
my
json
and
I
need
to
look
at
that
to
to
decide
which
part
I
actually
can
deliver,
that
would
require
going
at
the
root
even
for
a
relative
query.
So
I
can
imagine
a
use
case.
I'm
just
not
sure
that
we
need
to
address
this.
A
There's
a
there
is
actually
an
argument
to
be
made
that
this
is
outside
our
charter.
It
is
you
know,
somebody
said
that
of
the
known
implementations,
something
like
25
of
them
suggest
supported
this
idiom.
B
F
Implementation
does
not
I'm
happy
to
do
so.
One
of
the
things
that
we
do
in
jason's
schema
is
we'll
we'll
specify
the
smaller
required
the
smaller
feature
as
a
requirement.
That
would
be
starting
a
path
with
dollar
sign
here
and
that's
it,
and
then
we
make
allowances
in
the
implementation
or
in
the
spec
that
allow
implementations
to
optionally
do
some
other
behavior
or
even
we
make
general
allowances
that
this
the
an
implementation
can
optionally
go
do
other
stuff,
but
the
default
behavior
should
be
what's
defined
in
the
spec.
F
A
Yeah,
I
I
think
that,
well
my
certainly
I
just
shouldn't
speak
for
myself.
I
I
hate
optional,
behavior
and
standards.
The
whole
point
is
that
we're
trying
to
write
rules
to
achieve
interoperability-
and
you
know
at
the
moment,
should
somebody
read
the
rfc
and
see
this
thing,
then
we're
not
giving
them
much
help
as
to
you
know
if
they
send
such
a
thing
across
the
internet,
to
something
that
processes
jsonpath.
Is
it
going
to
work
or
not?
Well
a
lot
of
times.
A
It's
not
does
anybody
you
know
so
at
the
moment.
To
be
honest,
I
I
personally,
you
know
no
hats
on
this.
Smells
like
it's
outside
our
charter.
E
Yeah
well,
but
I
think
it's
really
useful
to
talk
about
the
extensibility
model
before
we
finish
this
particular
issue,
because
essentially
the
the
resolution
depends
on
what
extensibility
model
we
have
so
one
extensibility
model
instead
of
json,
which
is
we
nail
down
the
features
at
once
and
yeah.
Everything
that
is
not
within
that
feature
set
is
not
json
and
that's
it.
So
that's
one
way,
another
way
is
actually
introducing
versions,
so
you
have
a
version
one
and
a
version
two
and
version
three,
and
there
is
the
linear
progression.
E
E
So
I
think
what
we
really
should
be
doing
is:
is
group
optional
things
into
features
and
say
there
is
a
feature
that
you
can
have
and
if
you
have
that,
then
you
can
do
this
and
that
and
that
and
that,
if
you
don't
have
it,
you
cannot
do
it.
The
number
of
features
should
be
a
small
single
digit.
F
Here
is
to
just
allow
the
dollar
sign
and
only
support
the
dollar
sign,
and
the
specification
says
if
it
doesn't
start
with
the
dollar
sign
fail,
but
then
an
implementation
completely
on
its
own
can
optionally
say
you
know,
allow
this
thing
allowed
the
at
sign
to
start
a
path,
and
then
that
can
become
known
as
this
implementation
supports
this.
F
Right
so
what
I'm
saying
is
we
don't
move
forward
with
this
and
then,
if
enough
implementations
do
it
and
it
starts
to
gather
traction,
then
you
know
at
some
point
in
the
future.
When
we
go
to
update
the
spec,
because
it
will,
we
will
want
to
update
the
spec.
A
So
for
what
it's
worth,
let
me
just
remind
people
of
the
language
in
the
in
of
the
charter,
which
says
that
we
will
develop
a
standard
track.
A
Thank
you.
So
it
says
we
will
develop
a
standards
track
specification
that
is
technically
sound
and
complete,
based
on
the
common
semantics
and
other
aspects
of
existing
implementations,
where
there
are
differences,
because
we'll
analyze
those
differences
and
make
choices
that
rough
considers
rough
consensus
considers
technically
best.
So
the
question
is:
is
the
relative
path
and
the
use
of
the
at-sign
does
that
fall
within
the
basket
of
the
common
semantics
and
other
aspects
of
his
existing
implementations?
Well,
not
obvious
in
this
case.
I
Yeah
I
was
going
to
make
a
point
on
that.
Hopefully
I'm
not
echoing
too
badly
when
I'm
speaking.
Oh.
I
Okay,
which
was
the
if
we
make
out
at
the
beginning
of
a
path,
a
syntax
error
in
the
spec,
then
one
extensibility
model,
which
gives
david
what
he
wants
is
to
allow
implementations
to
override
syntax
errors
and
and
that
behavior,
so
you
know,
treat
syntax
errors
as
being
the
kind
of
extension
points.
If
you
like.
A
I
I
haven't
actually
seen
a
I
possibly
I
just
missed
it.
Maybe
maybe
it's
there
and
I
just
missed
it.
I
haven't
seen
any
specific
proposals
for
extensibility
models.
Yet
kirsten
did
I
miss
something.
E
No,
I
I
didn't
write
this
up
yet
because
so
far
I
didn't
need
to,
but
I
think
we
have
tons
of
experience
in
the
itf
doing
extensibility,
so
we
might
want
to
apply
that
knowledge
here
and
specifically.
I
think
we
need
to
have
identified
extension
points,
so
we
can
do
extensions
in
a
more
orderly
way
than
just
saying
everybody
can
can
do
with
a
syntactically
invalid
json
path
specification
what
they
want,
because
that
never
gives
us
inter
interability.
E
A
Just
to
make
this
concrete,
for
example,
one
extension
point
would
be
the
first
character
of
the
json
path
and
that
any
value
other
than
dollar
signifies
an
extension.
You
know
not
defined
in
this
in
this
in
this
draft.
Is
that
the
kind
of
thing
you're
thinking
about.
E
Yes-
and
there
would
also
be
an
iana
registry
of
of
first
characters
with
a
defined
registry
policy,
so
we
know
how
to
to
how
to
go
ahead
and
and
start
making
an
extension,
and
we
can
discuss
lots
of
different
ways
of
doing
that.
I
don't
want
to
do
that
today,
because
I
haven't
written
up
a
proposal,
but
I
think
the
important
thing
is
not
just
to
to
open
the
floodgates.
A
Okay,
so
I
I
think
I
think
it's
hard
to
disagree
with.
What
kirsten
is
saying
is
that
a
a
suggestion
for
an
extensibility
model
would
be
welcomed.
Let
me
just
present
the
contra
point
of
view
you
talk
about,
you
know,
jason,
having
no
extensibility
model
whatsoever
and
how
awful
that
is.
Well,
you
know
jason's
doing
pretty
well
out
there.
You
know
I
I'm
actually
okay
with
things
that
never
get
revised
once
1.0
has
shipped,
but
you
know,
I'm
probably
I
may
be
in
a
minority
on
that.
A
So
so
I
think
a
necessary
next
step
would
be
somebody
saying
something
specific
about
extensibility.
I
do
not
get
the
present
the
the
feeling
that
anybody
on
this
call
at
least
strongly
feels
that
we
should
write
support
into
our
document
for
json
paths,
beginning
with
that
sign.
D
E
A
Enough,
okay,
so
we're
asking
people
to
to
propose
an
extensibility
model,
and
I
think
we
even
have
an
agreement
on
what
one
piece
of
it
looks
like
you
know,
which
is
the
first
character
anything
else.
We
need
to
discuss
on
the
relative
path
and
the
at
sign.
I
think
there
is.
I
I
think
there
is
a
meta
issue
which,
which
is:
how
is
this
decision
communicated
back
to
david,
oh
david,
because
the
tone
through
this
issue
has
been.
I
think
this
is
in
within
our
charter.
We
should
be
able
to
do
this.
I
don't
see
any
arguments
against
it
and
because
he's
not
here,
I'm
disappointed
that
he
won't
participate
in
this
part
of
this
discussion,
and
I
can
just
see
this
blowing
up
again
in
the
issue.
So
how
do
we
present
this
to
him?.
A
Well,
we
will,
you
know
the
meeting,
I
don't
know
if
anybody
else
is
and
we
will
go
back
to
it
to
the
working
group
mailing
list
with
the
notes
you
know
this
being
the
the
itf
david
david
is
is
is
able
to
explain
to
us
why?
Why
we're
wrong
and
if
he
can
convince
us,
then
that's
fine,
okay,
okay,.
A
A
A
So
so
what
is
the
state
of
the
art
in
the
in
the
comparison
world
hold
on
look
at
the
at
the
at
the
grid
here
so
yeah?
I
was
looking
at
the
grid
that,
what's
his
name
c
brigmer
did.
F
F
So
I
think
let
me
answer
them
in
that
order.
E
E
E
Go
ahead
that
there
are
two
kinds
of
regular
expressions:
there
are
the
regular
expressions
that
grab
pioneered
that
essentially
tell
you
whether
you
have
a
match
or
you
don't
have
a
match,
and
then
there
are
the
regular
expressions
that
are
actually
meant
for
for
parsing
input
and
extracting
subparts
and
computing
on
them,
and
this
is
the
the
javascript
and
and
the
perl
and
and
all
these
other
irregular
expressions.
They
were
actually
defined
for
that
kind
of
application.
E
So
the
problem,
of
course,
is
that
a
regular
expression
mechanism
that
is
useful
for
computing
can,
in
a
pinch,
also
be
used
for
matching
it's
just
a
little
bit
more
verbose,
then,
and
that's
why
people
who
have
who
are
writing.
Implementations
are
typically
focusing
on
the
matching
on
the
computing
regular
expression
because
they
get
to
cover
both
bases.
E
But
in
respect
like
this,
this
means
that
you
get
a
lot
of
complexity
in
the
regular
expression,
the
component
and
and
all
the
diversity.
Of
course
you
find
out
there
are,
is
in
the
computing
side
and
and
not
really
in
the
matching
side.
Well,
there
is
a
little
bit
of
diversity
in
the
matching
side,
but
not
as
much
as
on
the
computing
side.
E
E
If
we
go
from
first
principles,
we
really
should
be
looking
for
for
a
matching
kind
of
regular
expression
and
the
only
kind
I
found
when
we
discussed
this
in
in
the
context
of
of
cddl
was
the
w3c
schema
regular
expressions,
and
these
may
be
a
little
bit
unpopular
because
they
are
98
what
we
need,
except
they
have
these
character
class
sub
subtractions,
which
no
other
regular
expression
flavor
has,
which
is
really
useful,
but
it's
unfortunate.
Nobody
tells
them
so
allowing
the
the
whole
w3c
schema.
E
Regular
expression,
gamut
leads
to
problems
with
peeping
the
people
having
to
to
change
their
implementations
to
to
support
that,
so
that
that's
not
really
a
choice
we
can
make
either.
So
in
the
end,
I
think
what
we
will
do
is
we
will
point
to
a
regular
expression
specification
that
that
is
already
a
standard
like
w3c
like
ecmascript,
and
simply
say
this
is
the
subset
that
jsonpath
actually
supports.
E
So
it's
pretty
easy
to
write
an
abnf
for
for
a
w3c
schema,
regular
expression
that
doesn't
have
character
class
subtraction
so
that
that
would
be
my
personal
favorite.
But
that's
not
the
point
I'm
trying
to
make
here.
I'm
trying
to
make
the
point
we
will
define
a
subset
and
we
could
also
use
ecmascript
and
pcie
and
extract
a
common
subset
of
those
for
our
purposes
as
well,
and
probably
ie2
would
be
in
this
that
same
set.
A
Let
me
make
a
deduction
from
what
you
just
said
kirsten.
I
think
what
you,
what
you
didn't
say,
but
what
you
meant
is
that
we
we
should
not
do
this
unless
we
have
a
specification
of
exactly
what
we
mean
when
we
say.
A
N
A
Can
I
mute
him?
Okay,
okay!
Is
there
anybody
who
wants
to
argue
that
we
should
just
leave
regular
expressions
out.
P
J
But
it
seemed
to
be
very
hard
to
actually
get
to
something
that
is,
that
is
easy
to
make
to
make
it
interoperable.
In
practice,
I
mean
right.
B
F
Okay,
my
personal
preference
in
as
an
implementer
is
to
go,
get
a
library
that
does
regular
expressions
for
me
and
it'd
be
ideal.
If
I
could
find
a
library
that
exactly
matches
what
we
specify
here
and
is
supported
in
all
the
various
or
it
has
support
in
all
the
various
languages,
that's
a
talk.
J
E
F
I
I
understand
that
from
my
work
with
jason
schema,
but
this
this
seems
like
a
big
enough
feature
that
it's
worth,
including
in
my
opinion,
we
just
have
to
figure
out
how.
A
So
I'm
going
to
agree
strongly
with
karsten
and
say
that
unless
we
can
have
a
specification
of
what
we
mean
when
we
say
regex
against
consensus
support,
then
we
should
just
shouldn't
have
regex
it.
I
just
don't
think
it's
okay
to
say:
yeah.
You
can
use
regexes
in
your
filters
without
and
say,
and-
and
you
know
it
depends
what
god
and
the
implementer
happen
to
put
in
in
their
particular
regex
library.
A
I
I
don't
think
that's
that's
acceptable.
So
so
I
think
that
those
who
want
to
have
regular
expressions
in
jsonpath
filters
need
to
propose
exactly
what
that
means.
Not
by
that
I
mean
proposed.
I
I'm
expecting
that
if
we
pick
a
subset
of
the
w3c
stuff,
then
any
given
implementation,
like
my
own,
might
need
to
then
get
into
the
business
of
massaging
that
subset
into
equivalence
in
the
implementation
that
is
available
on
the
platform
or.
G
In
the
language-
and
that's
that's
quite
if
we
do
this
right
if.
E
We
do
this
right,
actually,
the
massaging
carriage
at
the
start
and
the
dollar
at
the
end.
I
Well,
that'd
be
perfect,
but
yeah,
let's
see
where
it
goes,
but
yeah
somebody
has
made.
I
I
The
point
was
making
in
general
was
that
if
the
subset
doesn't
have
that
property
that
it's
easy
to
implement
on
top
of
existing
platform,
implementations
of
regex
then
we're
putting
quite
a
burden
on
the
implementer,
and
I
would
start
to
be
nervous
about
including
it
in
the
spec.
At
that
point,.
A
E
Which
ones
well,
for
instance,
yang,
defines
regular
expressions
to
use
w3c
schema,
regular
expressions
and
young
implementations
instead
use
pcie.
J
When
we
are
saying
about
subsets,
do
we
mean
that
we
are
fine,
having
implementations
evaluating
a
weld,
a
well-defined,
a
well
well-formed
json
path,
regular
expression
on
their
engine,
but
what,
if
they're,
fed
a
invalid
malformed
regular
expression
path?
Do
we
does
the
standard
would
standard,
require
the
library
to
refuse
such
a
regular
expression
or.
J
E
J
A
This
opens
another
issue
at
some
point.
You
know
in
rfc
8259
there
are
interoperability
notes
saying
well,
you
know
here
are
things
that
are
allowed,
but
you
know
could
lead
to
interoperability
problems.
One
would
expect
that
there
would
be
a
space
for
a
caution
here,
given
that
you
know,
there's
there's
a
lot
of
variation
in
what
implementations
do,
but
anyhow,
to
get
back
to
what
I
say
is.
I
think
that
people
would
be
okay
with
including
regular
expressions
in
jsonpath
once
we
have
a
specific
proposal
for
what
that.
C
I
would
prefer
to
restrict
the
right-hand
side
of
the
regular
expression
match
to
a
literal,
regular
expression.
Discussions
was
about
allowing
json
path
fragments
inside
of
regular
expressions.
We
should
agree
here
to
not
allow
this
and
the
first
version,
at
least
to
only
allow
literal,
regular
expressions.
My
proportion.
A
Right
so
I
mean,
I
think,
that's
covered
by
what
we
just
said
is
that
once
we
have
a
specification
of
what
we
mean
by
jsonpath,
that
should
not
include.
I
said:
what
do
you
mean
by
regular
expression
that
should
not
include
any
magic,
non-literal
stuff.
E
Now,
that's
a
completely
orthogonal
question
whether
you
can
compute
a
regular
expression
or
a
limit
to
limit
it
to
literals
is
is
completely
orthogonal
to
what
the
regular
expression
means
once
you
have
it,
and
I
think
that
that
what
stefan
said
is
that
we
we
should
have
literals,
and
I
would
expect
that
there
will
be
extensions
to
to
the
expression
language
inside
json
path
over
time.
So
that
would
be
an
extension
point
that
is
very
likely
to
come
up
at
some
point,
but
probably
for
a
basic
json
part.
E
A
E
A
Reasonably
good
consensus
that
we
need
to
define
what
regular
expressions
we're
going
to
allow
and
then
then
then
then
allow
them
cool.
Does
anybody
want
to
say
anything
else
on
this
subject.
I
Just
from
the
opening
comment
on
that
issue,
when
I
implemented
regular
expressions
in
my
jsonpath
implementation,
someone
came
to
my
aid
and
pointed
out
about
regular
expression,
dos
attacks,
and
is
this
something
that
we
need
to
be
concerned
about
in
a
security
section
or
to
address
in
the
subset
that
we
choose?
Are
we
going
to
kind
of
close
our
minds
to
that
or
you
know
restrict
our
interest
away
from
that.
I
G
F
E
A
Okay,
very
good,
so
we
I
think,
we've
made
some
useful
progress
on
the
three
issues
that
I
suggested.
Glenn
had
also
suggested
one
james.
You
put
it
in
a
slide.
I
think
which
one
was
that
again
59,
I
think
here
no,
we
did
59.
glenn
what
what
what
was
the
one
you
suggested.
I
A
F
So
yeah
I've
raised
this
and
someone's
that
going.
I
raised
this
and
basically
the
idea
behind
it
is
that
if
we
have
the
two
of
the
same
value
in
the
in
the
output,
if
that
value
is
an
extensive
object,
say
we
found
that
same
identical,
extensive
object
in
multiple
places
within
the
within
the
input
value.
F
It
doesn't
make
sense
to
evaluate
the
remaining
portion
of
the
path
against
both
instances
that
are
identical
because
you'll
get
just
get
the
same
set
of
values
out
so
from
that,
does
it
make
sense
to
collapse
down,
to
duplicate,
to
or
to
collapse
the
duplicates
into
a
single
value
in
the
output?
F
And,
ultimately,
questions
are
raised
around
identifying,
not
only
a
value
but
also
its
location,
which
would
be
a
node,
and
we
determined
that
if
somehow
a
if
somehow
the
path
evaluated
the
same
location
and
value
in
the
the
same
node
twice,
then
those
would
be
those
would
be
removed.
F
But
if
it
evaluated
to
the
same
value
but
different
locations,
those
are
different
nodes,
and
so
those
would
actually
remain
in
the
remain
in
the
the
final
output
implementations
could
take
advantage
of
the
fact
that
they
are
the
same
and
only
run
or
that
the
values
are
the
same
and
only
run
the
pr
path
on
one
copy
of
the
value,
noting
that
it's
in
both
locations,
that
would
be
an.
G
F
Two
nodes
with
the
same
value
should
not
be
collapsed
correct,
but
if
you
get
two,
if
you
get
two
independent
results
from
see,
if
you
get
two
selectors
returning
the
same
node,
which
is
the
same
value
in
the
same
location,
which
one
value
in
in
one
location
returned
twice,
then
those
two
should
be
collapsed.
A
So
you
know,
I
have
to
say
that
you
know
when
I
looked
at
your
very
first
example
way
back
in
september:
24th
wow.
You
know
your
very
first
example
from
you
greg
you
know,
of
of
of
a
and
b
with
string
null
true
and
false
string,
something
right
and
and
you're
going
to
collapse,
string
null
full
string
into
string
null
false.
A
I
think
that
makes
the
life
way
more
difficult
for
the
person.
Writing
the
json
paths
and
writing
code
to
process
what's
coming
back,
because
if
they
assume
they're
just
going
to,
they
know
that
you
know
that
the
the
object
they're
addressing
has
a
bunch
of
array,
value,
top-level
things
and
they're
getting
two
from
each,
but
all
of
a
sudden.
They
only
get
one
from
one
case,
because
it
happens
to
be
the
same
as
something
before.
Isn't
that
going
to
make
writing
the
code
to
process
the
output
of
this
much
more
difficult.
A
Then
I'm
then,
I
know
that
if
there
are
four
top
level
items
then
I
expect
eight
things
in
the
list
that
comes
out
and
if
I,
if
they're
magically
there
aren't
because
two
of
them
happen
to
be.
F
Right,
and
so
that
goes,
that
goes
into
the
idea
that,
like
in
in
this
particular
case,
what
I've
written
is
not
what
we
landed
on.
What
I've
written
is
strict
value
equality,
not
node
to
quality
in
that
first
set
string
null
false
string.
F
Those
two
strings
are
actually
from
different
nodes,
and
so
what
we
landed
on
is
to
say
that
those
strings
would
both
be
included
in
this
set
because
they're
from
different
locations
and
using
stefan's
original
implementation,
where
you
can
optionally
get
the
the
locations
reported
instead
of
the
values
or
in
addition
to
the
values,
it
makes
more
sense
in
that
context,
with
that
level
of
output,
if
you're,
just
looking
at
the
values,
maybe
you're
not
interested,
that
string
is
included
in
there
twice.
F
Maybe
you
are,
I
don't
know,
but
from
a
performance
point
of
view,
if
string
isn't
string,
but
is
a
rather
complex
object
that
I'm
evaluating
it
has
the
same
keys
and
all
those
keys
have
the
same
values
and
the
the
depth
is
extensive.
I
don't
want
to
have
to
from
a
performance
point
of
view.
I
don't
want
to
evaluate
the
same
object.
C
F
F
Yeah,
I
think
I
had
an
example
somewhere
in
here
where
it
actually
did
return
the
same
location
twice.
F
If
you
wanted
to
do,
I
don't
know
for
lack
of
a
better
example,
star,
comma
one
where,
if
you
were
to
get
an
object,
you
just
get
all
the
keys
or
you'd
get
you
get
the
values
under
all
the
keys.
But
if
you
get
an
array,
then
you
would
get
all
of
the
objects
and
then
you
would
also
get
the
second
element
in
the
array.
Again.
C
The
chat,
I
think
you
cannot
judge
duplication
by
values
alone.
You
you
always
need
the
location,
and
if
locations
are
the
same
identical,
then
we
can
remove
or
collapse
them.
K
A
E
If
I
want
to
vaccinate
people
with
biontech
vaccine
and
I'm
looking
in
my
json
for
people
who
are
female
because
they
they
all
get
the
biontech
and
for
males
older
than
than
60.
E
So
I
could
simply
choose
for
people
older
than
60
and
choose
females,
and
then
I
get
a
result
and
that
of
course
will
have
the
the
females
that
are
older
than
60
twice.
So
that's
the
kind
of
application
that
you
have
in
mind
when,
when
you
say
you
collapse,
duplicates.
A
I
might
make
an
argument
that
that
happens
at
another
level
of
the
program
yeah
and
if
I
want
to
crush
duplicates
out
of
it,
okay,
I
can
crush
duplicates
out
of
it.
That's
a
one-liner
in
most
programming
languages,
but
I'm
not
sure
I
want
that
happening
down.
In
my
you
know,
pull
the
pieces
of
json
out
code.
F
E
J
If,
if
we
screen
the
right
way,
isn't
the
descendant
selector,
also
kind
of
implicitly
removing
the
removing
duplicates
because
it
if
you,
if
you
look
at
it
as
if
finding
an
intermediate
node
and
then
going
recursively
deeper
until
it
matches
some
something
else,
wooden
that
find
multiple
nodes,
depending
on
where
the
recursive
search
has
been
started?
J
F
I
I
think
what
mark
was
saying
is
that
if
you
enumerate
your
grandchildren
you're,
obviously
so
enumerate
your
children
and
their
children,
you're,
obviously
going
to
enumerate
your
grandchildren
and
so
there's
a
level
of
duplication.
If
you
just
look
at
it
abstractly,
but
any
any
sane
kind
of
recursion,
because
the
descent
would
wouldn't
produce
duplicate
locations,
and
I
think
that
I
think
that's
fine.
I
don't
think
that
that's
kind
of
opens
the
door
for
us
to
avoid
duplicate
locations
elsewhere
in
the
spec.
F
A
I
I've
kind
of
been
prodding
people
to
write
the
descendants
pr
for
a
while,
and
at
least
two
people
have
got
it
on
their
to-do
list,
but
it
hasn't
appeared
yet,
and
I
think
it
should
be
an
easy
one
to
knock
off.
So,
let's
hope
it
appears
in
the
next
few
weeks.
J
That's
why
I
was
thinking
about
that
problem.
Unfortunately,
I
didn't
yet
my
time
to
actually
write
it
here.
A
Okay,
I
think
we
have
made
good
progress
on
that
one.
So
we
have
moved
through
all
of
our
expanded
agenda
in
one
hour
and
a
half
does
anybody
else
we
have?
We
all
got.
We
all
got
online
and
gathered
here
together.
Is
there
any
other
productive
use
we
can
put
our
time
to?
Is
there
anything
else?
Any
other.
F
E
F
E
This
quick,
quick
question
of
order,
I'm
typing
into
a
dmd
file
that
james
has
typed
into,
but
he
has
seems
to
have
stopped
doing
that.
B
Some
confusion,
sorry
carson.
I
I
I
couldn't
keep
up
with
the
conversation
I
was
going
to
edit
the
notes
when
the
vod
for
this
meeting
would
be
online
and
then
I'd
have
a.
E
B
I
Just
another
point
of
order:
can
we
please
capture
volunteers
who
have
stepped
forward
to
write
prs
in
the
minutes.
I
A
I
I've
been
writing
myself
a
set
of
notes
in
a
private
document
which
which
james
I
will
shoot
over
to
you.
It
may
be
helpful.
G
I
A
Okay
was
that
greg,
I
said,
want
to
talk
about
filter
expressions.
Just
do
you
have
an
issue
on
that.
A
Well,
we
did
talk
about
the
you
know,
the
at
sign,
the
relative
paths
and
we
talked
about
regular
expressions,
but
I
think
I.
F
F
F
Was,
oh
so
there's
64.,
there's
92
open
by
stefan.
E
Yeah,
the
first
thing
we
run
into
is
that
we
have
a
terminology
problem
that
I
think
we
can
now
resolve,
because
the
the
whole
thing
with
the
record
and
the
question
mark
and
so
on.
That
is
the
filters
selector
and
within
the
question
mark
within
the
parenthesis.
Following
the
question
mark
there,
we
have
expressions
that
we
could
call
filter
expressions
because
they
are
being
used
in
the
context
of
filters
and
they
are
probably
slightly
different
from
the
indexing
expressions
that
we're
using
in
indexing
selectors.
C
F
Yeah,
I
I
pers
yeah,
there's
a
lot
going
on
with
these
with
the
filter,
expressions
lots
of
questions
that
are
up
in
the
air.
I
think
I
think
it
might
be
worth
coalescing
all
these
issues
into
a
single
into
a
single
issue.
We've
got
number
17,
which
I
originally
opened
back
in
september
number
57,
which
stefan
you
opened
92,
which
stefan
also
opened.
F
E
F
F
A
This
was
from
stefan
on
an
issue.
This
is
the
64..
Stefan
posted
something
looks
like
the
first
of
may,
with
a
nice
with
a
nice
discussion
tour
through
the
whole
issue.
C
F
C
C
C
A
little
bit
in.
A
C
Discuss
the
operators
used
in
this
filter
expression
might
not
use
arithmetic
operators,
as
addition
subtraction
at
the
first
glance.
Maybe
they
are
possible
this.
I
I
have
not
a
good
feeling
about
this.
I
would
start
with
just
using
comparison
and
boolean
operators.
C
F
So
if
I
want
to
say
that
the
node
I'm
looking
at
say,
the
current
node
is
equal
to
some
other
node
that
I
reference
from
the
root
minus
one.
Then
I
should
I
should
be
able
to
do
that.
F
C
C
M
A
Well,
I
think
I'd
like
to
have
a
quick
look
at
what
existing
implementations
actually
do.
I'm
a
minimalist,
I'm
I'm.
You
know
when
in
doubt
leave
it
out,
and
so
I
would,
I
would
certainly
be
sympathetic
to
leaving
arithmetic
out
unless
that
happens,
to
be
widely
supported
and
interoperable,
in
which
case
hey
no
problem.
F
I
already
had
I
already
support
all
of
these
in
my
in
my
implementation
in
my
previous
implementation.
C
I
My
perspective
is
that
these
numeric
operations
don't
really
pay
for
their
cost.
The
cost
benefit,
isn't
really
it's
a
bit
too
high
personally,
but
and
I'm
thinking
in
terms
of
the
spec
agree,
implementation
wouldn't
be
too
bad,
but
it's
just
extra
verbage
verbiage
in
the
spec
from
my
perspective,
but
I
don't
strongly
objective
if
they're
commonly
supported.
I
A
A
A
A
C
When
comparing,
if
we
comparing
weak
types
or
do
we
strong
typing
comparison
and
I'm
not
not
because
I'm
coming
now
nearly
exclusively
from
javascript
I'm,
I
would
prefer
the
the
weak
type
comparison.
F
Yeah
personally,
I
come
from.net,
which
is
very
strongly
typed
and
I
have
had
to
implement
loose
comparisons
already.
So
I
can
just
kind
of
work
that
logic
over,
but
it
was.
F
It
was
a
pain
to
do,
and
I
don't
want
to
force
other
implementers
into
doing
that
if
they
happen
to
be
in
a
strong
language.
C
F
F
Yeah,
okay,
coming
back
to
the
loose
equality
thing,
I
imagine
this
would
be
pretty
a
pretty
divisive
topic,
but
yeah,
I
would
I'd,
prefer
a
strict
equality
over
a
loose
equality,
but
people
with
different
language
backgrounds
have
different
views.
J
Would
happen
what
we
have
to
define
is
what
happens
when
the
input
values
do
have
incompatible
types
and
how
to
bubble
up
the
how
to
model
the
behavior
of
ignoring
those
cases.
Since
we
have
the
overarching
rule
that
a
syntactically,
validated
sympathetic
expression
shall
never
return
error,
but
we
should
just
not
produce
not
produce
outward
bonds
right.
A
A
You
know,
as
glenn
pointed
out
there
is
that
you
know.
There's
there's
the
whole
arithmetic
thing
is
not
you
know,
does
not
the
current
point
offer
good
interoperability.
So
that's
another
argument
for
not
going
there
even
granted
that
there's
it's
easy
to
think
of
situations
where
it
would
be
useful.
F
I
think
it's
the
task
of
the
implementer
or
the
client
of
the
implementation,
which
would
be
the.
E
M
A
I
Now,
just
let's
raise
another
another
aspect
of
filter
expressions,
while
we're
here
just
to
raise
the
awareness
which
is,
if
you
have,
if
you
allow
non-scalar
comparisons.
So
an
example
would.
I
I
So
you
know
that's
just
another
consideration
and
I
think
I
may
have
pointed
out
that
christoph
christopher
bergma
in
his
proposal,
a
came
up
with
a
syntactic
restriction
on
the
filter,
expressions
to
avoid
those
kind
of
non-scalar
comparisons
and
sidestep
the
whole
issue,
which
is
rather
neat,
but
I
can
understand
why
we
might
want
not
want
to
go
that
route.
I
just
wanted
to
raise
a
general
issue
because
it
will
come
up.
I
A
C
Pull
request
and
I
I
would
like
to
start
exactly
this
and
expect
a
lot
of
comments
regarding
this.
J
Another
related
somehow
related
thing:
what
about
lexographical
sorting
and
you
know,
collation
ordering
in
multilingual
situations.
C
Doesn't
do
ordering
or
any
post
processing.
J
No,
no,
we
have
the
greater
than
operation.
Okay,.
A
I
you
know,
I
think
you
you
have
to
go
with
with
just
unicode
code
points.
Anything
else
leads
you
to
madness
right.
D
C
Can
we
agree
all
to
the
fact
and
the
greg's
proposal
to
use
for
operators
the
very
common
c
based
syntax.
N
C
F
C
A
Here:
okay,
we're
getting
close,
we're
getting
close
to
the
end
of
our
time.
Is
there
anything
else,
that's
urgent
and
deserves
our
time
that
we
should
make
sure
we
get
in.
A
Well,
what
is
the
next
ietf
111
is
sorry,
when's
that.
D
E
D
A
A
A
Tell
you
what
I'll
we'll
do
the
same
thing
we'll
set
up
a
doodle.