►
From YouTube: IETF-JSONPATH-20220817-0800
Description
JSONPATH meeting session at IETF
2022/08/17 0800
https://datatracker.ietf.org/meeting//proceedings/
A
B
The
problem
with
things
like
that
is
that
can
serialize
changes
that
are
easier
to
do
if
they
actually
stack
on
each
the
other
and
really
should
be
the
discretion
of
the
editors,
whether
we
can
fix
a
typo
or
something
like
that
or
rearrange
sections
or
changes
like
that,
which
really
need
to
be
done
in
a
sequential
way
or
gets
in
the
way.
So
I'm
not
not
a
big
fan
of
shackling
ourselves
to
some
rule
that
that
really
isn't
necessary.
On
the
other
hand,
I
I
do
respect
that.
A
I
I
doubt
that
24
hours
for
an
open
pr
is
going
to
be
all
that
much
and
if
you
have
multiple
pr's
that
need
to
be
stacked
on
each
other,
then
you
can
put
a
like.
It
depends
on
thing
in
the
the
comment,
and
you
will
know
that
the
the
one
pr
depends
on
another
one
and
you
open
them
all
at
the
same
time
and
they
can
all
be
reviewed.
At
the
same
time,.
C
Yeah,
it
just
means
there's
some
rebasing
required
then,
and
it
can,
you
can
end
up
with
delta
clashes
and
extra
work
right
now
I
would
say
that
the
pace
might
pick
up
as
we
do
increasing
sort
of
fine
polishing
of
the
document,
just
a
wording,
because
that's
gonna
be
scattered
all
over
the
place
and
it's
not
going
to
be
particularly
deep.
So
that's
my
concern,
but
I
think
for
any
substantive
change.
Yeah
the
24-hour
grace
period
is
good
idea.
D
B
B
E
E
E
E
E
D
Do
that
now
and
yeah
if
possible?
Let's
do
that!
First!
Okay!
So
if
I
recall,
if
I
can
just
speak
to
that,
if
I
recall
correctly,
we
agreed
that
we
were
ready
to
take
that
one
forward
to
to
to
last
call,
but
we
need
a
document
shepard
which
can't
be
me
since
I'm
a
co-author
and
you
didn't,
you
didn't
have
time
to
do
it,
as
I
recall
james
or
no.
E
D
E
There's
separately,
that
I
know
that
there's
been
a
lot
of
work
done
else
from
the
ietf
around
the
template,
for
it
so
I'll
just
read
the
documentation
there
and
perhaps
find
some
other
write-ups
to
give
me
some
inspiration
for
what
should
be
in
there
and
what
it
might
look
like.
I
might.
I
might
clean
up
a
pre-emptive
version
of
it
out
just
to
get
some
feedback.
Pizza
rings
is
my
first
attempt
at
this,
but
okay.
D
D
D
E
D
A
A
F
Yes,
at
the
beginning,
I'm
I
was
against
the
equality
of
structured
values,
but
I
gradually
changed
my
mind
and
I
think
now
it's
it's
really
much
more
consistent
with
with
any
anything
else.
Equality
is
one
thing.
The
other
thing
is
comparing
with
with
with
smaller
or
greater
than,
but
we
can
exclude
this
for
now
and
I'm
in
favor
of
this
year.
D
Carson,
oh,
I
did
let
me
let
me
just
raise
one
issue.
I
put
myself
on
the
q4,
which
is:
if
we
do
this,
do
we
need
to
add
literals
so
that
I
can
do
a
literal
equals
against?
You
know
a
an
object
literal
provided
in
in
the
in
the
in
the
json
path
itself.
That's
just
a
non-rhetorical
question.
Okay,
I'm
done
karsten.
B
Yeah,
I
think
that
that's
a
good
point
and
the
the
other
thing
is
about
doing
inequalities,
comparisons
less
than
and
greater
than
that.
The
same
issue
applies
here
that,
if
we
don't
put
it
in,
it
would
be
hard
to
fix
that
data
and
inequalities
of
arrays
is
pretty
easy
to
define,
and
so
the
the
question
is
whether
that
shouldn't
be
very
easy
to
put
in,
and
inequality
of
maps
is
indeed
not
so
easy
and
that's
probably
a
place
where
people
will
not
be
surprised.
E
F
E
D
Okay,
so
in
opposition
to
this,
my
probably
my
primary
concern
is:
is
this
actually
good
practice?
Would
I
actually
want
to
do
this
in
an
application
you
know?
Have
you
know
some,
especially
since
there's
no
literals
do
some?
You
know
comparison
of
arbitrarily
deep
structure
nesting
in
a
stream
of
of
json
coming
in
over
the
internet.
I,
if
you
know,
if
somebody
did
that
in
a
code
review
and
sent
it
to
me.
I'd
probably
say
you
know
you
shouldn't
do
that.
A
To
counterpoint
that
dot
net
released
the
their
json
model
that
that
I
use
in
all
of
my
libraries
and
one
of
the
huge
outcries
that
the.net
world
had
was:
why
isn't
there
a
jason
compare
or
the
adjacent
equality
in
included
in
this
model?
People
want
that
nested
equality,
at
least
to
have
the
ability
to
do
it.
E
E
C
A
C
A
E
A
C
Can
I
just
say
something
to
tim's
point
about
stretch,
deep
structure?
Comparisons
being
you
know
an
anti-pattern
useless?
I
somewhat
agree,
but
I
think
the
surprise
factor
of
if
someone
actually
found
a
used
for
it
and
it
didn't
work.
I
think
that
tips,
the
balance
for
me.
That's
why
I
wanted
to
do
it.
D
For
what
it
was
like,
I
looked
at
c
bergman's
comparison
and
it's
all
over
the
map.
You
know
some
do
some,
don't
so
it's
it's
not.
I
didn't
actually
count
or
anything
like
that,
but
this
is
certainly
not
wildly
out
of
sync
with
what
at
least
some
implementations
do.
Okay,
just
to
save
time,
I'm
going
to
say
that
I
smell
rough
consensus
here,
which
is
that,
yes,
we
should
go
ahead
and
do
this
and
that
we
should
also
support.
So
at
least
we
have,
I
think,
we're
just
consistent.
D
A
C
A
E
D
C
D
C
D
D
So
I
think,
on
duplicate
keys,
we
all
agree
that
this
is
bad
and
we're
not
going
to
specify
in
detail
what
the
we're
not
going
to
try
and
be
the
what
wg
and
specify
in
detail
the
exact
semantics
of
all
the
possible
error.
Permutations
and-
and
you
know,
we're
going
to
do
the
moral
equivalent
of
8259
when
she
says
this
is
you
know
the
behavior
is
unpredictable
and
there
was
a
lot
of
argument
about,
but
the
best
way
to
say
that
was
which
I
got
bored
and
stopped
reading
is.
A
D
C
C
So
I
think
I
use
the
term
implementation
dependent.
The
the
details
in
line
11
lines
1180
to
1183
can
actually
be
simplified
with
that
precondition
on
1179,
but
let's
not
get
into
that
here.
I'll
follow
up
with
the
simplification,
but
basically
I've
just
said
that
the
if
there
are
no
duplicate
names
keys,
if
you
like,
then
we
can
define
object,
equality
and
then
on
line
1186.
I
said
if
there
is
an
object,
and
at
least
one
of
them
either
of
them
has
got
either
or
both
have
got
duplicate
names.
D
A
C
B
B
The
the
implementation
defined
thing
we
have
is,
how
does
a
json
decoder
react
to
duplicate
keys
and
that
that,
of
course
is,
is
an
issue
that
would
have
needed
to
be
solved
in
json.
It
never
was
solved.
So
we
have
this
ambiguity
here.
It's
not
at
all
clear
to
me
that
on
the
json
value
level,
we
can
still
have
duplicate
keys,
so
greg
has
one
example.
B
In
javascript
and
many
other
implementations,
just
one
of
the
the
keys
is
selected
and
the
other
ones
are
discarded,
and
I
think
we
would
have
to
search
long
and
wide
for
implementations
that
actually
carry
duplicate
keys
from
a
json
text
to
a
json
video,
and
I
think
we
should
simply
exclude
that
from
consideration
for
this
document
and
yeah.
That's
not
something
that
that's
a
problem
in
practice,
because
the
problem
is
on
the
way
from
the
text
to
the
json
value.
D
Where
this
is
actually
a
rise
in
practice
is
when
you're
using
a
streaming
tokenizer,
which
I
I've
actually
done
a
lot,
because
you
know
in
high
throughput
event
processing
things
you
don't
want
to
take
the
time
to
parse
everything
into
an
object
model.
You
know
you
want
to
you
to
use
a
tokenizer,
and
in
that
scenario
it
is
certainly
the
case
that
you
know
you
can
you
know
you.
Your
partial
callbacks
could
be
called
back
twice
for
the
same
member
for
a
member
with
the
same
key,
and
I
think
that's
true.
D
In
at
least
you
know
the
popular
mainstream
parsers
in
in
in
in
multiple
languages,
so
you
can
get.
You
can
run
into
this.
Actually,
okay,
what
you're
saying
in
in
in
this
in
the
case
where,
where
you're
using
I
I
use
jackson
a
lot
so
jackson
has
a
json
next
token
api
and
it
also
has
a
an
object.
Mapper
object.
Is
that
what
it's
called,
I
think
api,
and
if
you
use
the
object,
mapper
api.
Well,
the
these
one
of
the
keys
vanishes.
A
D
C
C
Go
ahead.
A
similar
example
occurred
a
few
years
ago,
where
I
made
the
assumption
that
any
sane
representation
of
linux,
environment
variables
wouldn't
have
duplicate
keys,
and
I
was
wrong,
and
so
my
point
here
is
that
it
all
depends
on
the
representation.
That's
chosen
for
the
data
structure.
You
know
the
representation
of
the
object.
C
But
my
second
point
is
that
if
I
was
a
tester
and
I
was
going
to
test
jsonpath,
I
would
create
a
hostile
implementation
of
json
json
that
did
all
sorts
of
strange
things
with
duplicate
keys.
I
know
push
this
back
to
its
limit.
You
know
it
won't
happen
in
practice.
I
don't
think
it's
unlikely
to
happen
in
practice,
but
in
terms
of
the
robustness
of
the
spec,
I
think
we
need
to
take
it
into
account.
E
D
I
would
you
know,
whereas
I
disagree
with
kirsten
that
you
know
this.
Just
you
know
doesn't
happen
at
the
jason
value
level.
I
would
agree
with
him
that
I
think
this
should
probably
that
this
is
really
an
issue
at
the
jason
text
level,
primarily
in
terms
of
right
way
to
think
about
it.
So
I
I
would
probably
disagree
with
you
glenn
that
this
needs
handling
down
at
the
detail
level.
I
I
would.
D
I
would
think
this
would
be
best
handled
by
a
statement
relatively
high
up
saying,
depending
on
how
the
you
know,
the
mapping
from
json
text
to
nodes
in
effect
is
done.
The
behavior
in
presence
of
is
unpredictable,
and
that
applies
to
every
statement
in
this
spec
that
concerns
behavior
concerning
a
key,
that's
extracted
by
a
a
member,
that's
specified
by
kiva
and
then
just
leave
it
that.
F
D
So
let
me
speak
to
that.
So
in
principle
I
agree
with
you,
stefan
unfortunately,
whereas
I
jason
is
used
quite
a
bit
in
in
in
specs.
I
have
not
observed
it
being
available
in
parsers.
I
I
don't
I
I
haven't
seen
really
say
you
know,
let's
create
a
parser
put
it
in
my
json
mode,
so
so,
whereas
that
what
you
say
is
correct,
I'm
not
sure
it's
that
useful.
C
E
C
Yeah,
so
I'm
coming
around
to
this
idea
of
a
general
statement
of
unpredictable
behavior,
but
just
want
to
be
absolutely
clear.
If
we
look
at
the
text
on
the
screen,
we
delete
line
1186,
so
we
wouldn't
actually
make
any
statement
about
what
happens
when
there
are
duplicate
keys.
We
just
spec
the
case
where
there
are
no
duplicate
keys.
Is
that
correct.
D
E
C
B
B
A
D
A
C
D
Retaining
so
okay,
that's
in
the
case,
we
have
a
tight
mismatch
and
a
tight
mismatch
right.
You
haven't
changed
anything
right
in
the
type
mismatch
it's
just
false
and
that
actually
breaks
the
rule
of
you
know.
If,
if
you
know,
if
the
word
foo
is
tested
to
being
less
than
three,
and
that
turns
false,
it
does
not
mean
that
foo
is
greater
than
or
equal
to
3.
right.
Both
both
sides
of
that
are
just
pulse.
C
A
D
B
A
I
think
that
comes,
I
think,
that
comes
at
the
the
type
mismatch
level
rather
than
at
the
greater
than
or
equal
level.
So
if
we,
if
we
in
the
spec,
define
greater
than
greater
than
equal
operator
as
greater
than
or
equal,
then
the
type
mismatch
thing
still
applies.
It's
still
uncomfortable,
but
it's
still
logically
sound.
F
E
C
F
B
Yeah,
I
I
only
just
returned
from
vacation
and
then
so.
This
is
about
the
minimal
presentation
I
can
make
about
this
subject.
So
we
had
a
lot
of
discussions
about
extension,
points
that
were
kind
of
on
the
implicit
level
without
actually
writing
down
things
and
the
the
one
extension
point
that
that
we
we
have
identified
really.
B
Is
this
this
functor
extension
point
where
we
had
length
as
a
long-standing
example,
so
you
can
distinguish
a
10-digit
isbn
from
the
13-digit
isbn
or
something
like
that,
and
we
can
generalize
this
to
to
a
functor
with
zero,
more
arguments
which
are
comma
separated
so
that
that
would
be
the
overall
syntactic
form
of
this
extension
point
and
the
specific
name,
the
functor
length
current
here,
compare,
normalized
and
so
on.
Those
would
be
registered
extensions
and
to
make
sure
that
the
extension
point
mechanism
is
actually
implemented.
B
We
would
use
length
as
an
extension
that
actually
comes
with
a
json
path,
so
so
people
actually
write
the
code
to
pass
this
so
that
I
think
that
that's
essentially
where
we
are
at
now.
The
question
is:
where
does
this
syntactic
form
go
to?
So
what?
Where
can
that
appear,
and
that
turns
out
to
be
a
little
bit
more
complicated,
because
we
have
pushed
some
some
of
our
typing
system
into
the
syntax
so
having
a
common
syntax
for
various
things
that
that
might
want
to
be
addressed
by
extensions
might
bite
us.
B
So
I
think
we
have
to
to
discuss
how
the
things
that
that
are
still
tractable
not
easy,
but
tractable
with
the
current
syntax
change,
when
we
use
the
extension
in
different
locations
and
the
inverse
of
course
also
holds
the
the
extension.
Can
have
arguments
and
these
could
be
boolean
expressions.
These
could
be
comparables.
These
could
be
singular
paths.
These
could
be
string
literals
and
right.
B
So
we
we
have
kind
of
the
location
problem
on
the
the
top
down
and
we
have
the
argument
problem
on
the
bottom
up
and
we
have
to
make
sure
that
we
fit
into
the
syntax
with
that
and
that's
why
I
didn't
just
throw
out
a
proposal,
because
every
proposal
I
came
up
with
immediately
ran
into
complexities
here.
So
there
are
many
ways
of
serving
that.
We
could
have
singles
something
like
that.
B
I'm
not
going
into
that,
but
I
think
we
really
should
be
coming
up
with
a
number
of
examples
where
we
want
this
to
work
right
and
then
and
then
of
course,
examples
that
that
are
supported
by
by
people
actually
doing
something
in
existing
json
path
and
json
path
like
implementations
and
then
work
from
there
and
and
look
at
the
syntactical
issues
and
look
at
the
the
potential
semantic
impact
of
of
having
to
distinguish
a
singular
path
from
a
compare
comparable.
For
instance,.
E
A
I
think
this
is
great.
One
thing
I
would
add
is
order
of
execution,
so
in
c
sharp.
If
you
look
at
the
compare
normalized
in
c
sharp,
what
that
would
do
is
it
would
evaluate
the
the
at
first
name
and
then
it
would
have
tried
to
evaluate
the
the
string
constants.
But
if
you're,
if
you
didn't,
have
a
string
consonant
there's
something
evaluable,
it
would
do
that.
A
B
C
B
B
There
are
lots
of
specs
that
use
extension
points,
but
this
specific
syntax
here
came
to
mind
quickly
because
it's
a
pretty
common
way
of
doing
extension
points.
So
I
I
would
have
to
dig
in
in
rcs
which
rcs
actually
use
an
extension
point.
Syntax
like
this,
so
the
ones
I
have
recently
written
use
different
syntaxes.
B
But
these
are
not
syntaxes.
We
would
want
to
copy
here,
but
the
function
function,
argument
notation
is
so
familiar
and
we
already
have
examples
like
like
length
and
wasn't
there
a
size.
I
don't
remember
so.
We
had
several
examples
already
that
took
the
syntactic
form
and
adopting
this
syntactic
form
as
the
syntactic
form.
For
the
extension
point
we
want
to
have
in
jsonpath
seems
to
work
very
well.
A
D
The
type
system
a
little
bit
it's
it's
I
mean
json-
has
a
type
system
of
a
sort.
It's
it's
well,
but
it's
complicated
because
you
look
at
that
length
function
and
you
say
well,
if
you're
going
to
write
the
definition
of
the
length
function,
it's
perfectly
reasonable
to
apply
it
to
a
string
to
an
array,
it's
even
reasonable,
to
apply
it
to
an
object.
You
know
how
many
members
does.
This
object
have
like
on
lots
of
programming
languages.
B
A
D
A
boolean
yeah,
so
so
the
point
I'm
making
is
that
to
write.
If
I
were
going
to
write
the
definition
of
length,
I
would
feel
the
need
to
say
you
know
when
applied
to
a
string.
It
means
this
when
applied
to
an
array.
It
means
that,
when
applied
to
an
object,
it
means
this
other
thing.
When
applied
to
a
number,
what
happens
it
has
no
meaning
it
throws
an
exception.
D
D
B
B
B
E
D
Well,
we
do
have
to
if
we're
going
to
define
this
thing.
We
are
going
to
have
to
write
language
about
the
way
it
interacts
with
types
and
also,
as
you
point
out
with
like
arguments
that
just
don't
work
right.
You
know
that
aren't
there.
So
I'm
just
saying:
let's
not
underestimate
the
the
necessity
for
being
careful
and
and
thinking
about
this
glenn,
please
go
ahead.
C
I'm
just
wondering
if
we
could
get
away
with
a
set
of
restrictions
on
these
functions
that
says
that
the
arguments
must
be
type
adjacent
type
or
absent.
They're
like
in
at
dot
isbn
it's
either.
The
result
is
either
jason
type
or
absence,
and
if
we
made
the
result
of
a
functor,
all
always
the
same,
the
same
kind
of
type
you
know
adjacent
type
or
absent,
then
we
might
be
able
to.
You
know
say
that
every
every
function
definition
has
got
to
cope
with
those
half
a
dozen
cases.
E
A
Yeah,
I
was
going
to
say
the
same
thing.
I
was
going
to
say
that
you
know
the
json
path
specification
where
we're
defining
what
a
function
functor
is
we
say
that
the
arguments
can
be
of
these
types?
You
know
these
json
types
or
some
internal
representation
of
absent,
and
then
it's
the
responsibility
of
the
functor
to
handle
any
of
those
possibilities
and
then,
where
we
specify
length,
because
we
have
to
do
that
because
we're
going
to
include
it,
it's
not.
We
show
an
example
of
how
to
do
that.
A
D
B
F
B
F
A
Correct
so
current,
with
their
current
expression,
syntax.
The
way
that
it
works
is,
if
you
have
a
path
that
results
in
an
absent
value,
that
absent
just
falls
through
and
the
entire
expression
returns.
False
same
thing
would
happen
here.
If
you
do
the
length
of
two,
it
would
return
absent,
and
the
entire
expression
would
just
return
false.
B
Yeah,
that
was
what
I
wanted
to
enable
here.
So
this
is
the
the
alternate
approach
to
saying
we
can
only
have
json
values
there,
but
yeah.
Now
you
have
all
the
complexity
in
the
definition
of
each
single
extension
how
to
handle
these
different
cases.
I
think
it's
not
a
big
complexity,
but
we
certainly
should
make
sure
that,
in
the
lengthy
example
we
handle
this
in
such
a
way
that
implementers
of
other
extensions
will
know
what
to
do.
There.
B
D
B
D
Because
I
I
my
my
my
intuition
is
that
if
we
do
a
really
good
job
of
that,
because
obviously
it's
going
to
be
used
in
places
where
comparisons
are
expected
right.
Otherwise
why
would
you
be
doing
it?
So
it's
going
to
force
us
to
say
what
happens
in
various
failure
modes
in
those
comparisons,
maybe
that's
already
covered
by
the
language.
I'm
not
sure
like
you
know.
If,
for
example,
if
I
say
length
on
a
path,
that's
broken,
then
any
comparison
that
shows
up
and
returns
false.
D
I
guess
because
it's
a
tight
mismatch
or
something
like
that,
but
we
need
to
write
all
that
down
and
my
intuition
is
that
if
we
do
a
good
job
on
that
with
length
because
it
has
a
parameter-
and
you
know
and
has
a
result,
that
would
be
expected
to
be
used-
that
there
should
be
some
hope
that
would
you'd
have
to
solve
the
larger
problem
to
do
a
good
job
of
doing
that.
Okay,
glenn.
B
E
F
B
B
D
E
B
B
C
B
A
D
That
you
know
that
that
might
be
advantageous.
If
we
limited
the
extension
point
to
be
applied
in
filter
expressions,
then
I
think
that
simplifies
the
task
of
dealing
with
errors,
and
you
know
absent
arguments
and
things
like
that
because
it
you
know
the
the
filter,
then
just
simply
does
not
return
anything
right
or
it
did
yeah.
C
D
At
that
point,
I
would
be
inclined
to
hold
that
that's
a
demonstration
that
the
cost
benefit
of
this
work
is
not
favorable
and
we
might
have
to
live
without
it.
So
you
know
yeah.
I
think
I
think
the
way
is
clear
to
taking
the
next
steps,
which
I
think
is
focusing
on
length
to
make
sure
we
understand
at
least
that
and
probably
restricting
ourselves
to
filter
expressions,
but
there's
a
limit
to
how
much
we
should
invest
in
this.
That's
all.
B
A
D
Okay,
okay,
so
I
think
we
have,
you
know,
made
some
progress
in
understanding
the
complexity
of
the
issue
and-
and
I
think
the
idea
of
limiting
this
to
filter
expressions
is
is,
is
has
merit
and
is
worth
serious
consideration,
and
I
think
we've,
and
so
I
think
the
next
step
here
is
for
kirsten
to
convince
us
all
that
this
can
be
done,
at
least
in
an
example.
By
doing
by
doing
the
length
function
right
up.
Is
that
fair
statement
of
where
we
stand.
D
A
B
Yeah,
that
is
pretty
much
standard
fare
in
in
this
space,
because
if
you
make
something
extensible,
you
have
to
live
with
interoperability
between
components
that
have
the
extension
and
don't
have
the
extension.
And
there
are
a
number
of
things
you
have
to
get
right
and
the
most
important
one
is
not
to
create
false
interoperability,
which
is
where,
where
one
implementation
thinks
it
can
act
on
the
extension
but
but
doesn't
have
everything
it
needs
to.
A
B
D
D
B
D
A
C
A
C
A
D
C
D
E
A
D
A
So
if
we,
if
we
say
that
the
list
selector
is
the
only
thing
it's
got,
you
got
the
square
brackets
and
then
a
list
of
the
other
things
in
between
it.
And
you
know,
if
you
only
have
one,
then
that's
just
the
other
things.
I
think
we
could
collapse
things
a
little
bit
better
in
the
grammar
and
it
would
actually
align
with
how
at
least
I
how
I've
implemented
it,
because
I
don't
have
a
separate
list
selector.
I
just
have
okay,
I've
gotten
a
bracket.
A
I
expect
a
list
of
indices
and
an
index
can
be
what
we
explicitly
call
an
index,
which
is
a
number.
It
can
be
a
slice
or
a
range.
It
can
be
a
filter
expression.
A
name
can
be
any
of
those
things
that
exists
inside
the
brackets
comma
delimited,
but
I
don't
explicitly
have
a
list
selector
per
se.
Does
that?
Does
that
really
make
sense
at
all.
A
B
F
A
A
A
A
C
Yeah
you
see,
I
I
think
duplication
is
actually
helpful
for
readers,
who
want
to
examine
a
particular
selector,
because
they've
got
fewer
depth
levels
of
selected
to
go
through
a
few
levels
of
documentation
to
go
through.
You
know,
for
example,
you
know
list
they
can
just
go
there
and
see
that
it's
a
list
and
then
they
they
can
then
refer
to
one
of
the
the
other
selectors
and
they're
done
rather
than
having.
A
B
I
think
the
the
problem
we're
running
into
here
is
that
we
need
a
second
term
and,
and
you
are
trying
to
really
find
selector
to
be
the
second
term,
and
then
we
are
in
lack
of
the
term
term,
for
what
is
called
a
selector
right
now,
and
I
actually
would
be
happy
if
we
could
find
a
term
for
that.
We
briefly
had
index
for
that.
B
D
Okay,
let's
move
on
to
another
issue,
then
do
you
do
extension
point
branding,
I'm
not
going
to
talk
about
branding
here?
Oh
right
and
the
last
one
is
glenn's
issue
about
the
list
form
of
the
dependent
selector,
which
is
like
which
I
can
summarize
as
saying
that
our
our
current
draft
departs
from
the
consensus.
C
C
A
C
F
As
far
as
I
had
understand,
this
issue,
part
of
the
problem
here
was
that
you
have
two
iterators
one:
iterator
is
iterating
over
the
list.
Selector
and
the
other
iterator
is
iterating
over
the
the
descendants
in,
and
so,
if
you
swap
what
the
outer
iterator
is
and
the
inner
you
get
different
result
lists,
and
I'm
not
sure
if
yeah
we
could
explicitly
define
it.
C
B
A
D
C
C
C
D
D
B
D
D
Like
that,
no
it's
not
it's
not!
You
greg!
It's
the
fact
that,
aside
from
you
and
me,
everybody
else
on
this
on
who's
contributing
is
in
europe,
and
so
we've
been
doing
this
at
a
convenient
to
europe.
I
I
you
know
I
may
have
dark
feelings
in
my
head,
but
it
actually
makes
practical
sense
to
do
that
and
I
can
handle
it.
You
know
once
every
six
weeks,
okay,.
A
E
B
B
B
Into
the
the
hedgehog,
so
of
course
these
are
not
official
notes,
but
if
you
need
some
reminders
for
what
we
discussed,
of
course,
I
was
also
discussing
so
that
the
notes
may
not
be
complete.
On
the
other
hand,
this
is
a
hedgehog.
So
if
you
see
something
wrong
with
those
notes
and
want
to
fix
it,
that
could
also
help.