►
From YouTube: GraphQL Working Group - March 3, 2021
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
D
Glad
to
see
a
bunch
of
folks
here
on
time,
I
think
there's
a
handful
more
that
are
on
the
attendee
list.
So
we'll
give
it
a
couple
minutes
and
see.
E
D
I
tend
to
merge
them
as
they
show
up
just
because
it's
easier
to
not
have
to
like
do
a
manual
merge
every
single
time,
and
then
I
usually
sort
them
in
alphabetical
order.
I
used
to
sort
them
by
alphabetical
and
organization,
but
I
think
that
was
too
fiddly.
So
now
I've
just
been
raw.
Just
like
you
can
literally
I
just
open
in
the
ide,
select
all
the
rows
below
me
and
do
alpha
sort
and
whatever
it
does.
I
roll
with
that
tends
to
work.
F
Lee
we
don't
have
the
live
notes,
yet
oh
good
call.
Thank
you.
D
I
need
to
make
a
script
that
just
does
this,
because
it's
I'm
sure
there's
a
way
to
do
that.
It's
literally
just
me
creating
a
new
shared
dock
and
a
folder
in
google
docs.
Every
time.
D
D
D
D
D
F
F
Since
you're
in
there
already
lee
the
title
for
the
april
agenda
is
march,
you
might
want
to
fix
that.
D
D
I
almost
made
the
mistake
of
editing
that
april
1
because
it
said
march
2.
so
fell
into
my
own
failure.
Okay,
I
think
I've
got
all
pull
requests
merged.
D
Thank
you
for
that
updates
in
so
I
believe
our
agenda's
cleaned
up
ready
to
go
and
we
are
plenty
time
over.
So
I
think
we
got
a
very
stable
participant
list,
so
thanks
everybody
for
joining
yet
another
working
group
meeting
to
start
off
on
our
agenda.
Of
course,
by
joining,
we
all
agree
to
the
membership
agreement,
participation,
guidelines
and
code
of
conduct.
D
You
may
have
noticed
if
you
sent
pull
requests
up,
that
we
have
a
cla
bot.
That's
now
enforcing
some
of
these
things.
Some
of
them
failed.
I
merged
those
anyway,
so
we'd
have
an
accurate
record
move
forward,
but
please
sort
of
treat
those
as
a
little
bit
of
an
asynchronous
sign
that
you
need
to
go
clean,
something
up,
one
in
three
odds
that
it's
a
bug
in
the
cla
tool.
D
D
If
you
can
reload
and
get
an
accurate
view
of
the
agenda,
we'll
just
do
intros,
starting
from
the
top
work
our
way
down
in
the
order
that
they
appear
there
and
if
we
miss
anyone,
then
we'll
intro
you
at
the
end,
although
I
think
we've
got
everybody
here
so
we'll
start
with
me:
hey
everybody!
My
name
is
lee.
Here's
your
fearless
leader.
G
Good
morning
everybody
here's
andy
doing
crafty
java
working
for
atlassian
calling
in
from
sydney
this
morning.
F
Hey
everyone,
I'm
maintainer
of
the
graphile
suite
of
open
source
tools,
and
I'm
also
involved
in
a
few
of
the
pushing
a
few
of
the
spec
things
forward
today.
I
D
I
Just
joined
so
always
checking
my
position
and
released,
I
hope
is
graphql
js
and
my
name
is
one
and
I'm
from
louisville
ukraine.
K
Sorry
about
that,
hey,
I'm
john!
I
work
at
with
amazon
web
services
on
aws
appsync
welcome.
J
Everyone,
hello,
hey
everyone,
I'm
mark.
I
work
with
yelp
on
graphql
stuff,
I'm
here
interested
today
in
wendy's
conversation
for
operation,
expressions.
A
Hi,
I'm
michael
I'm
working
at
chili
cream
and
we're
building
the
hot
chocolate
graphql
server.
K
M
D
Spec
excellent
and
rob
I
see
you
there
too,
I
just
merged
your
pull
request.
D
Insure
yourself
yeah,
I'm
robert
with
aws.
D
Awesome,
healthy
crew
thanks
everybody:
let's
take
a
quick
look
over
our
agenda
and
make
sure
that
we
have
everything
here
that
we
want
to
talk
about.
I'm
going
to
give
an
update
about
new
meeting
times
we're
going
to
go
over
our
previous
meeting
action
items.
Then
we've
got
replacing
query
errors
with
request
errors
from
benji.
D
That's
a
pretty
healthy
list
of
things
to
talk
through
anything.
That's
not
on
this
list
that
anyone
wants
to
cover
today.
D
I
like
silence.
That
means
we've
got
an
up-to-date
agenda.
So
first
is
just
a
quick
update
and
this
is
related
to
to
andy's
agenda.
So
I
think
I
might
jump
to
that
one
out
of
order
after
we
get
through
some
of
these
other
things,
but
this
one
is
mostly
a
heads
up
and
it
was
started
by
the
first
time.
Andy
posed
this
of
wanting
to
start
to
shift
around
our
meeting
times
to
be
more
amenable
to
the
asia
time
zone.
D
So
our
next
april
meeting
will
happen.
Two
hours
shifted,
plus
there's
a
daylight
savings
time
shift
that
happens
for
many
between
now
and
then
so.
Lots
of
things
happening
with
dates
and
calendars
that
are
confusing,
so
go
check
that
out,
I
updated
the
link
and
that
one
to
include
more
accurate
time
zones
that
the
people
who
have
been
attending
most
frequently
are
closest
to
so,
hopefully
that's
a
worthwhile
tool
to
make
sure
that
you've
got
it
appropriately
represented
on
your
calendar.
D
H
And
the
shared
google
calendar
still
shows
the
old
time.
For
me,
I
don't
know.
D
Okay,
I
might
need
to
update
that.
I
know
at
some
point.
We
had
two
different
calendars,
so
I
thought
I
saw
the
one
from
brian
change,
but
maybe
it's
not
represented
correctly,
so
thanks
for
the
flag,
I'll
follow
up
and
make
sure
that
gets
fixed.
D
G
Sure,
but
that's
not
there's
not
a
lot
of
science
behind
it.
It's
just
like
the
idea
of
having
more
suitable
meeting
times
across
the
world
and
it's
a
it's
kind
of
an
unsolvable
problem
and,
to
some
extent,
right
like
you,
can't
have
a
good
meeting
time
for
the
whole
world.
So
the
rough
idea
was
to
kind
of
alternate
between
three
or
maybe
even
four
different
meeting
times
to
kind
of
cover
the
world
better,
and
I
picked
totally
biased
just
to
highlight
the
problem.
G
A
little
bit
like
san
francisco,
berlin,
new
delhi
and
sydney
as
as
representatives
and
and
they're
put
inside
the
working
group
issue.
590
like
there's
a
small
table
with
three
different
meeting
times
suggested,
which
kind
of
covers
the
four
areas
better.
I
would
say
nothing
is
perfect.
Really
like
you.
G
Could
you
yeah,
like
I
said,
there's
not
a
suitable
mythic
time
for
all,
and
if
you
want
to
like
the
goal
was
that
at
least
every
of
these
four
cities
has
one
good
meeting
spot
and
actually
I
I
kind
of
gave
more
preferable
treatment
to
the
europe
and
u.s,
because
most
people
coming
from
there.
O
G
It
was
the
idea
in
this
ticket
is
basically
to
have
two
one
meeting
time,
which
is
good
for
san
francisco
and
berlin,
one
for
good,
which
is
sun
for
sunscreen
sydney
and
one
good
for
berlin
and
new
delhi.
That's
basically
the
fundamental
deal.
A
G
Have
to
say
yeah
like
yeah,
actually,
europe
got
got
away
quite
quite
well
with
6
p.m,
eleven
and
nine
a.m.
San
francisco
has
two
very
good
spots
with
nine
a.m
and
two
p.m,
and
one
very
bad
with
one
midnight.
G
Really
not
oh,
these
are
the
times
these
of
the
times.
I
think
we
have
to
choose
so
it's
more
like
a
starting
point
for
a
discussion
so,
but
the
fundamental
idea
is
to
have
alternate
meeting
times
to
cover
the
world
better,
so
yeah
happy
to
hear
some
thoughts.
F
So
I
think
my
first
thought
on
this
would
be
a
great
great
effort,
and
I
certainly
would
like
to
make
the
graphical
working
group
more
accessible.
F
But
I
wonder
if
having
three
or
four
meeting
times
might
become
a
bit
hard
to
predict
for
people
like
they're
gonna
have
to
keep
referencing
their
calendars
to
find
out
where
it
is.
Would
we
be
able
to
achieve
similar
goals
by
just
having
two
meeting
times
that
alternates?
G
G
G
D
It's
definitely
not
a
formal
requirement,
and
I
was
thinking
as
you
as
you
were
kind
of
proposing
that
that
a
mode
that
we
could
run
here
is
is
to
have
like
a
main
meeting
and
then
satellite
meetings
at
different
times.
And
so
you
know
you
could
imagine
having
a
main
meeting.
You'd
still
want
to
make
sure
the
main
meeting
was
like
reasonably
accessible,
but
having
satellite
meetings
that
were
much
more
amenable
to
like
certain
focus
areas,
and
so
you
could
have
like
the
asia
pacific
specific
meeting
time
and
the
euro
specific
meeting
time.
D
That
would
allow
more
people
to
attend
to
those
and
having
sort
of
a
delegate
report
back
with
anything
that
was
meaningful
could
be
one
interesting
way
to
take
at
this,
but
yeah
I'm.
I
certainly
don't
have
to
to
be
at
all
of
them
and
if
we
wanted
to
run
one
that
was
sort
of
you
know
middle
of
the
night
for
the
us,
but
a
much
more
amenable
time
for
europe
and
asia.
Then
we
just
picked
somebody
else
to
run
that
particular
meeting.
That
would
be
totally
fine.
A
I
have
to
say
I
would
be
also
okay
with
if
europe,
but
let's
just
meet
from
you.
If
europe
is
at
one
point
later
in
the
in
the
night,
I
see
the.
If
I
look
at
the
first
meeting,
it's
it's
4a
4
a.m
in
in
sydney.
I
wonder
if
we
just
push
europe
for
one
meeting
more
in
the
night
and
it
would
be
morning
in
sydney
still
good
in
san
francisco
and
kind
of
okay
for
new
delhi.
I
think
we
could
really
do
two
meeting
times.
G
Well,
if
you
push
two
hours
ahead
and
make
it
like,
like
the
next
meeting,
lee
will
be
two
hours
ahead
of
now
right,
yeah.
So
this
this
is
like.
Actually,
I
think,
okay
for
san
francisco
berlin
and
sydney,
but
like
kind
of
okay
for
berlin
with
apm,
but
but
new
delhi
is
kind
of
in
the
horrible
time
zone
at
midnight.
G
For
them
for
new
delhi,
you
know,
so
this
is
the
challenge
of
having
one.
I
think
it's
not
enough.
I
think
that's
the
core
core
yeah,
I'm
saying
here.
A
So
but
I
would
be
totally
okay
to
have
my
meeting
once
so
every
now
and
then
having
a
meeting
around
midnight.
I
would
be
okay,
I
don't
know
how
it's
with
benji
you're,
also
in
europe.
F
It
would
be
a
challenge
for
me
because
at
the
moment,
due
to
lockdown
and
various
other
things,
my
computer
room
is
in
my
bedroom,
so
I
don't
think
the
wife
would
be
too
supportive
of
that.
I
could
probably
find
another
place
in
the
house,
so
yeah
I
can.
I
can
make
it
work.
It
shouldn't
be
too
much
of
an
issue.
D
Well,
I
I
want
to
make
sure
we
have
a
path
forward,
so
my
thought
was
that
we
just
get
a
little
bit
experimental
with
some
of
the
times
and
another
thing
that
we
could
consider
is
holding
these
meetings
more
frequently
and
having
them
be
slightly
shorter.
So
I
actually
scheduled
the
next
one
to
be
a
two
hour
window
of
time,
rather
than
a
three
hour
window
of
time,
one
just
recognizing
that.
D
Sometimes
we
go
to
a
full
three
hours,
oftentimes
we
go
short
and
we
and
land
at
two
and
those
typically
feel
like
the
most
well-run
meetings,
in
my
opinion,
so
having
like
a
firm
time
end,
might
you
know,
keep
us
on
point
on
the
agenda.
Yeah
and
three
hours
is
a
lot,
so
you
know
we
could
doing
them.
D
Monthly
makes
them
really
easy
to
talk
about
and
schedule,
because
there's
one
every
month,
but
we
could
do
one
every
three
weeks
or
two
a
month
and
especially
we're
going
to
alternate
in
a
way
where
it
gets
much
better
for
half
of
this
audience
so
much
worse.
For
half
of
this
audience,
I
imagine
that's,
even
though
some
of
us
are
saying
that
we'd
make
it
work,
you
know
reasonably
it's
going
to
affect
attendance
and
then
also
like.
D
We
got
to
not
forget
that
we've
got
a
lot
of
east
coast,
u.s
folks
as
well,
and
so
I'd
actually
probably
be
okay
to
top
in
a
call
at
11
p.m
or
midnight.
My
time,
but
that's
you
know
two
or
three
am
east
coast
time,
and
I
I
suspect
that
our
new
york
and
boston
members
may
may
not
be
willing
to
wake
up
at
that
time
and
join.
G
Andy,
so
so,
okay!
So
then
what
about?
As
a
concrete
suggestion
like
what
about
every
three
weeks
alternate
meeting
times
two
hours.
D
Here's
what
I'm
gonna
pitch,
I
think
we
should
do.
We
we've
got
our
updated
time
for
april.
That's
just
shifted
by
two
hours
so
that
at
least
it's
still
pretty
early
for
sydney,
but
it's
at
least
not
the
middle
of
the
night.
D
Let's
try
that
one
and
then
the
following
month,
let's
shift
to
afternoon
afternoon
for
the
the
u.s
time
zone,
which
I
think
puts
us
in
the
danger
zone
for
europe,
but
is
much
much
healthier
for
the
indian
and
asian
time
zones
as
an
experiment
and
we'll
see
what
that
does
to
attendance
and
and
see
if
it's
functional,
because
if
it,
if
we
find
that
it's
actually
creating
a
drag
force,
then
that's
the
sign
that
will
want
to
increase
frequency.
D
And
if
it's
actually
works
out
fine,
then
you
can
make
it
work.
But
yeah.
Does
that
sound
like
a
reasonable
way
to.
O
E
D
Yeah,
I
think
the
other
option
here
is
that
we
create
a
satellite
working
group
that
is
just
in
the
prime
hours
for
the
europe
to
asian
time
zone.
That's
just
the
worst
hours
for
the
us.
D
And
but
hopefully
it
means
that
we'll
get
dramatically
better
attendance
from
folks
in
asia
and
in
india
and
at
least
we'll
have
like
benji,
michael
you,
you
both
have
been
at
the
meetings
for
a
very
long
time,
and
I
trust
you
to
facilitate
those.
That's
another
thing
we
could.
We
could
try
to
do.
We
could
have
you
know
working
group,
one
first
of
the
month
working
group
second
of
the
month.
A
D
G
Yes,
that's
good,
like
as
a
side
note,
can
we
use
a
little
bit-
maybe
our
social
media
present,
especially
on
twitter,
to
kind
of
announce
us
and
make
it
a
little
bit
more
clear
to
people
that
we
change
this,
like
maybe
send
out
a
tweet
at
our
twitter
account
or
so
to
see
the
effect
of.
D
That's
a
great
idea
and
I've.
I've
got
a
whole
backlog
of
news
that
I
want
to
kind
of
share
through
those
channels
anyway,
so
I'll
make
it
part
of
that
whole
set
because
we're,
I
believe,
as
of
today,
actually
the
thing
that
we
voted
on
last
meeting
goes
through
and
so
we're
now
legally
in
the
clear
to
release
the
cut
of
the
spec.
So
I
want
to
announce
that,
and
I've
also
been
working
on
a
a
grant
program
that
I'll
share
details
with
y'all
at
a
later
date.
But
that's
another
thing.
D
Okay
sounds
like
our
our
action
item
for
this.
One
is
set
up
a
second
april
meeting
that
will
happen
later
in
the
day
for
optimal
times
for
london,
through
sydney.
D
Sweet,
let's
continue:
let's
go
through
action
items.
D
I'm
popping
open
this
list.
I
I
tagged
a
bunch
myself
ready
for
review,
so
I'm
getting
better
at
doing
these,
although
benji
is
typically
our
champion
of
the
action
items,
we
have
a
lot
actually
that
are
listed
up
as
ready
for
review.
D
Okay,
we
have
seven
that
are
open.
Should
I
present
I'll
present
my
screen.
D
Can
you
all
see
this
yes,
cool,
all
right,
let's
work
through
these
in
order,
so
changing
primary
branch
from
master
to
main
this
happened
we're
on
main.
Hopefully
that
didn't
cause
too
much
confusion
for
folks
as
you're
doing
pull.
D
O
D
That's
excellent,
open
an
issue
to
discuss
expansions
we
might
take
a
top
schema,
coordinates.
F
That's
also
being
discussed
today.
That's
the
operation,
expressions.
D
Closed
collection
techniques
for
finding
a
good
set
of
times,
I'm
pretty
sure
that
date
time
link
is
the
the
best
one.
So
I've
marked
it
ready
for
review
and
it
proves
that
this
is
a
hard
problem.
So
we
just
talked
about
that
I'll,
close
examples
of
default,
values
being
used
for
arguments
and
input,
objects.
F
That's
being
oh,
I
think
we've
had
this
open
for
long
enough
that
you
know,
as
many
people
who
are
gonna
submit
examples
have
done
so
so
I
think
we
might
as
well
close
it
now
great
okay,
we've.
D
Q
R
D
I
Remove
everybody
who
is
not
in
team
in
any
team,
so
basically,
as
we
discussed,
this
issue
was
mostly
about,
like
people
accounts
that
we
got
from
facebook
during
immigration,
not
like
account.
That
was
explicitly
because
some
reason
so
since
liu
setup,
like
teams
when
they
switched
to
foundation
organization.
I
D
Great
worst
case,
if
we
mess
something
up,
I'm
sure
they
will
bother
us
we'll
have
them
right
back,
but
that's
awesome
thanks
for
getting
it
organized
onto
the
teams.
That
was
my
intent
in
getting
those
started.
So
thanks
for
wrapping
it
up,
that's
great.
We
can
close
this
and
reload
just
to
make
sure
woohoo
all
right
that
one's
smoother
than
any
meeting
before
I'll
stop
sharing
my
screen
there
and
next
up
we
are
going
to
talk
about
benji.
I
think
the
next
one
is
yours,
replacing
query
error
with
request
error.
F
Yeah
cool,
so
we've
discussed
this
before
and
the
the
stopping
point
was
well.
We've
got
nothing
in
the
schema
that
actually
says
sorry
in
the
spec
that
actually
says
what
a
query
error
even
is
so
I
have
gone
ahead
and
added
a
definition
to
this
rfc.
F
It's
only
a
small
paragraph
basically
adds
the
basic
details
of
it.
We
also
link
to
it.
I
think,
in
the
first
place
where
it's
mentioned,
I
haven't
bothered
linking
to
it
from
every
case,
because
I
think
that
would
just
be
a
lot
of
markdown
links
and
unnecessary,
but
broadly
I've
also
carefully
gone
over
the
changes
to
make
sure
that
I'm
happy
with
all
of
them
there's
only
one
of
them
where
I
think
there's
like
it
could
go
either
way.
F
So
I've
left
that,
as
is
but
broadly,
I
think
that
this
is
ready
to
be
merged
into
the
spec.
If
everyone
agrees
so
I'm
proposing
moving
it
forward.
A
A
D
Where
does
the
request
errors
did?
I
am
I
just
looking
at
the
wrong
thing.
F
S
D
This
is
great,
I
think
the
one
thing
that
we
can
definitely
should
not
block
this.
I'm
really
happy
with
this.
I
think
we
should
mark
it
as
approved
and
I'll,
do
a
careful,
read
and
merge
it
after
the
meeting
is
we.
D
We
really
need
a
section
that
just
describes
errors
in
general
and
the
different
kinds
of
them
and
how
they
work,
and
when
we
do
that
we
might
either
refer
to
the
same
section
again
or
pull
sort
of
this
description
into
that
section,
because
there's
there
are
more
kinds
of
errors
than
just
request
errors,
which
I
think
was
part
of
the
the
rationale
and
making
this
clear.
D
But
this
is
a
humongous
clarification,
so
I
I
really
really
like
this
I'm
going
to
tag
it
up
so
that
I
don't
lose
track
of
it
awesome
that
was
all
on
this
one
sweet
and
there's
is
there.
I
mean
there's
no
functional
change
here,
so
I
don't
know
that
we
need
to
wait
on
a
draft
status
or
a
pull
request
of
any
kind.
F
D
F
No,
but
there
is
interest
in
potentially
pushing
forward
the
idea
of
a
glossary
which
I
proposed
when
I
first
introduced
the
concept
of
query
ambiguity
in
particular:
I'd
like
to
speak
with
you
at
some
point,
lee
about
how
that
would
work
within
spec
md,
whether
there
is
a
thing
that
already
works
for
it
or
whether
we
need
to
add
a
special
syntax
for
it,
whether
it's
just
a
new
document
at
the
end
or
whether
we
can
link
across
the
document
to
these
keywords,
so
that
I
mean
that
would
be.
F
D
Yeah,
I'm
totally
with
you
manually,
building
a
glossary
would
be
a
pain
and
we're
likely
to
get
it
wrong.
So
automating,
the
creation
of
that
would
be,
would
be
great
and
there's
also
some
overlap
where
oftentimes,
something
that
we'd
want
to
appear
in
the
glossary
is
actually
an
existing
headline.
So
I
know
that's
going
to
make
it
a
little
bit
confusing
where
the
definition
of
some
term
is
there,
but
I
think
that's
that's
very
clever
to
like
have
formal
definitions
of
terms
as
they
appear.
D
So
you
know
you're
not
just
reading
flowery
prose,
but
an
actual
term
of
art
is
appearing
right
now.
That
would
be
a
very
good
clarification.
F
I
think
it
would
be
really
neat
as
well
if
we
could,
for
example,
hoist
them
a
bit
like
tool
tips
almost.
So
as
you
hover
over
it,
you
can
see
it
right
there,
as
well
as
having
an
actual
document
at
the
bottom
that
you
can
read
through
in
full.
I
think
that
would
be
really
valuable
and
spec
md
would
be
the
place
to
do
that.
Of
course,.
B
Is
is
there
any
any
appetite
for
like
standard
error
codes
like
an
error
code
field
that
go
into
the
the
error
body.
D
I
think
that's
a
compelling
idea.
I
feel,
like
we've
talked
about
this
before
yes
several
times
I
would
say,
yeah,
I'm
trying
to
remember
the
exact
if
it
actually
formed
a
proposal
or
not.
F
I
think
one
of
the
things
that
we
did
was
to
make
space
for
that
error
code.
By
effectively,
we
made
a
change
to
the
spec,
where
we
forbade
any
other
properties
on
errors
that
weren't
within
the
extensions
property,
so
that
effectively
clears
that
namespace
so
that
we
could
add
code.
I
think
we
did
that,
maybe
two
years
ago
it
was
quite
a
while
ago,
but
that
should
mean
that
we
are
now
in
a
situation
where
we
can
add
additional
properties
such
as
code
to
errors.
H
I
mean,
I
know
a
lot
of
places
already.
Do
it
add
error
codes
in
the
extensions,
and
I
think
I
think
that
works
well
enough-
that
nobody,
really
nobody
I
know-
would
have-
has
pushed
for
it
just
because
that
works
well
enough,
and
so
it's
not
a
major
pain
point
right
now,
but
it
would
definitely
be
nice
to
have
them
at
the
top
level.
J
Yeah,
I
think
we
spent
a
lot
of
time
recently
trying
to
figure
out
how
to
like
do
error,
modeling
and
the
fact
that
we
could
have
put
error
codes
on
the
air
objects
directly
was
like
a
bit
too
subtle.
I
don't
think
we
made
that
leap.
That's
really
interesting
to
hear
yeah.
It
doesn't
have
having
says
it
was
just
easier
to
do
any
extensions.
D
Yeah
I
like
this.
The
one
thing
I
would
suggest
is
just
to
think
of
error
codes
as
a
genre
of
solution,
rather
than
a
tactical
solve
and
start
with,
like.
What's
actually
the
information
that
we
want
to
portray
in
the
error
and
how
might
tools
like
graphical
or
relay
or
chili
cream,
or
any
of
these
others
take
advantage
of
those
in
a
in
a
mechanicalized
way.
D
D
That
was
a
a
project
that
got
started
long
ago
and
and
never
picked
up
steam,
but
would
be
a
really
incredibly
valuable
thing
to
have,
and
one
of
the
things
that
makes
it
really
challenging.
Is
that
it's
hard
to
know
like
if
you
want
to
test
that
a
particular
thing
fails
validation,
it's
hard
to
assert
that
the
way
that
it
failed
was
the
correct
one,
and
some
form
of
codes
could
be
a
really
nice
way
to
to
model
the
error
states.
As
expected.
F
G
Agreed
actually,
actually
I
have
a
small
comment
to
the
original
discussion
from
benji.
Can
we
maybe
highlight
like,
while
reading
your
your
per
request
about
replacing
operation
with
requests
in
general?
I
totally
agree
it
makes
sense,
but
maybe
we
can
highlight
that
a
lot
of
people
think
about
request
in
the
pre
like
in
the
serialization
format.
G
They
actually
execute
a
request,
so
they
think
about
a
request
in
the
http
requested
and
what
we
are
describing
here
is
actually
a
request
after
the
serialization
and
so,
for
example,
that's
also
topic
about
craft
for
the
graphical
over
http
spec.
In
the
future,
we
treat
errors
which
happen
before
the
execution
kind
of
different
than
errors
that
happen
during
the
execution.
So
the
request
error
inside
graphql
is
different
than
a
request
error.
Let's
say
the
json
body
is
not
even
well
formatted,
so
it
doesn't
reach
the
engine
at
all.
A
Now
there
are
also
discussions
in
the
http
group
to
even
answer
at
this
point
with
a
graphql
response.
It's
not,
I
think,
necessarily
done
like
this,
but
you
could
also
do
that
at
this
point.
G
Yeah,
like
I
think,
there's
a
bigger
discussion
when
we
talk
about
graphical
over
hp,
but
for
this
back
edition
I
think
it's
like
craftworld
without
hdp
right,
it's
graphql
without
any
specific
civilization
or
transpose
transportation
format,
and
I
think
we
should
highlight
that
request
is
not
the
actual
http
json
post
the
request.
Most
people
use
yeah,
it's
actually
the
graphql
request.
So
the
the
request
to
the
graph.
F
Yeah,
this
is
what
I
kind
of
like.
I
I
completely.
I
completely
agree
with
this
topic.
I
spent
a
lot
of
time
trying
to
figure
out
what
the
right
word
to
use
for
this
would
be,
and
since
request
is
already
used
in
the
graphql
spec
and
keeping
in
mind
that
the
graphql
spec
broadly
doesn't
relate
to
http
or
a
transport
and
in
general
I
thought
this
was
in
the
end,
a
sufficient
term,
and
I
couldn't
find
a
better
one.
F
That
said,
I
think
it
probably
would
make
sense
to
add
a
non-normative
note
just
to
say
for
clarity,
a
graphql
request
is,
you
know,
independent
of
or
not
independent
of,
but
like
it's
not
the
same
concept
as
an
http
request.
I
think
there
would
be
potentially
value
in
saying
that
I'm
not
sure
exactly
how
to
phrase
that
yeah
agreed.
F
I
don't
think
we
should
factor
in
like
terms
like
serialization
into
that
note,
but
I
think
it
could
also
be
done
as
a
separate
thing,
because
we
already
talked
about
graphql
requests
in
this
case.
D
Another
potential
option
here
is
to
call
this
an
execution
error
that
I
know
there's
a
a
distinction
between
the
kinds
of
errors
that
should
be
known,
statically
and
the
kinds
of
errors
that
you
can't
know
until
you
run
the
query
itself
or
mutation
or
whatever,
which
is,
I
think,
part
of
the
original
rationale
for
calling
it.
A
query
error
was
that
it
happened
during
the
course
of
running
the
query,
but
the
intent
here
is
to
expand
query
to
all
of
the
operations,
so
execution
error
might
be
another
way
to.
D
Yeah,
so
this
is
why
I
want
to
have
a
section
that
specifically
breaks
down
errors
and
to
steven's
point
then
like
being
able
to
codify
that
in
a
machine-readable
way.
Later
is
a
nice
thing
to
have,
but
considering
that
we've
already
spent
15
minutes
just
talking
about
like
what
the
hierarchy
of
errors
is,
makes
it
clear
that
this
is
something
we
need
to
map
out.
D
So
you
know
I
I
want
to
keep
moving
on
on
benji's
proposal
here,
because
the
the
opportunity
cost
of
doing
it
is
super
low,
because
I'm
viewing
this
as
a
clarification,
since
it's
all
non-normative,
if
we
decide
that
we
want
to
change,
query
error,
to
request
error
and
then
exchange
request
air
to
something
that's
even
more
clear.
Once
we
figure
out
errors,
we
don't
lose
much
so
unless
anyone
is
thinking
of
something
that
I'm
not
thinking
of
that's
my.
G
D
Great
point
benji,
and
I
will
make
sure
that
we
add
that
non-normative
note
before
closing
this
out
as
part
of
the
editorial
process.
Thank
you
very
much.
F
Yeah,
so
this
is
and
andy
had
his
earlier.
I
have
managed
to
intersperse
them,
but
like
yeah,
okay,
so
default
value,
coercion,
rules-
we've
talked
about
this,
I
think
for
the
last
couple
of
working
groups.
Actually,
I
have
attempted
to
advance
this
a
little
bit
further.
There
was
some
complexity
in
the
wording
that
I
believe
that
I've
now
resolved.
F
I
haven't
written
a
graphql
js
pull
request
for
this
yet
because
I
think
there's
there's
effectively
two
ways
that
the
working
group
have
considered
that
we
could
go.
One
is
the
way
that
I
propose
in
this
rfc
and
the
other
one
is
just
to
do
an
additional
amount
of
validation.
F
I
think
on
the
on
the
default
values
themselves,
just
because
at
the
moment
it
just
says
it
must
coerce
to,
but
that
coercion
could
mean
that
the
default
value
which
we
use
uncoerced
could
actually
be
invalid
or
like
breaks
the
promises
that
we
make.
So
we
could
just
require
that
it's
more
than
coercion.
F
I
personally
I'm
much
more
in
favor
of
this
one,
because
I
feel
that
the
current
behavior
isn't
right.
I'm
not
I
don't
like
it.
I
think
it
is
very
it's
inconsistent
and
one
of
the
things
I
really
like
about
graphql
is
like
the
consistency
and
guarantees
that
it
gives
you
so
to
me.
This
is
a
glaring
issue
in
graphql
that
I
would
like
to
fix
properly
so
codifying
the
existing
behavior,
though
tempting
in
that
it
doesn't
break
anything.
F
I
think
we
could
say
that
fixing
it.
The
way
that
I'm
proposing
is
unlikely
to
break
anything,
because
anyone
who
has
this
issue
will
already
have
had
to
have
dealt
with
it.
That
said,
on
the
server
side,
it
may
introduce
some
overhead
for
people
adopting
the
new
versions
of
the
graphql
like
server-side
implementations,
because
no
longer
will
they
be
just
using,
like.
I
think
it's
like
native
objects
that
you
use
rather
than
say
the
graphql
representations,
whereas
we
will
be
having
to
coerce
those
values
now.
F
Implementations
that
are
out
there.
That
said,
I
believe
that
the
terminology
that
I've
used
in
the
pull
request
is
now
valid.
There's
nothing
hand-wavy
going
like
no
infinite
recursion,
please.
There
is
actually
words
to
handle
that
correctly.
I
believe
they
do
need
checking,
of
course,
but
I
think
that's
all
good,
so
I
think
this
is
ready.
I
I'm
a
fan
of
this
approach,
but
I'm
also
not
willing
to
invest
time.
Writing
the
graphql
js
for
it
until
we
sort
of
agree
that
this
is
the
better
approach
of
the
two.
D
I'm
trying
to
page
back
in
where
we
were
the
last
time
we
talked
about
this,
which
I
think
was
maybe
two
meetings
ago.
Can
you
can
you
help
me
remember
what
the
decision
fork
was
last
time
and
and
which
of
those
were
following.
F
So
the
the
decision
fork
was
basically
should
we
just
require,
should
we
fix
the
validation
rule
on
the
schema
that
looks
at
the
default
of
default
values,
and
should
we
just
say
these
default
values
must
specify
all
of
the
relevant
properties
such
that
it
can't
be
the
case
that,
as
I
laid
it
out
at
the
moment,
that
can't
happen,
and
I
think
the
general,
like
your
thought,
lee,
I
think,
was
broadly
that
you
want
the
objects
to
be
fully
specified
as
the
default
values
you
don't
you
don't
want
things
to
be
implied
as
part
of
them
by
default,
values
on
input,
object,
fields,
there's.
D
F
And
I
think
that
was
the
reason
that
we
then
requested
information
about
various
people
that
are
using
default
objects
and
default
object
fields,
basically
to
see
whether
that
would
result
in
particularly
large
schemas
when
we're
reproducing
this
like
redundant
data.
F
But
I
also
pointed
out
that
tools
such
as
graphical
that
might
expose
this
could
absolutely
do
that
completion
themselves
anyway,
like
they
have
the
information
there,
so
they
can
do
it,
so
it
doesn't
necessarily
have
to
be
an
issue
is
is
basically
when
you
write
it.
Excuse
me
when
you
write
it
in
sdl,
do
you
have
to
fully
write
out
every
time
and
there
are
people
that
write
their
schemas
in
sdl
right.
So
every
time
you
add,
like
a
a
field
in
an
input
object
with
a
default.
F
We
considered
then
expanding
and
just
having
it
like
handled
by
tooling
and,
as
I
recall,
ivan
raised
the
issue
there
that
if
you
take
an
sdl
schema,
pass
it
to
graphql
and
then
write
it
back
out
as
an
stl
schemer.
It
should
be
able
to
be
written
out
as
the
exact
same
thing
as
was
read
in
and
if
we
were
filling
in
the
gaps
for
them,
then
that
wouldn't
be
the.
A
A
F
Things
I
I
have
to
say
that
I
am
very
much
on
the
fence
about
whether
this,
whether
listing
everything
out
fully
actually
improves
credibility,
saying
this
has
a
default,
which
is
the
empty
object
to
me
says
it
would
be
the
same
as
if
you
pass
the
empty
object.
F
F
I
think
when
you
see
the
all
of
the
default
values
listed
out,
particularly
if
you
have
a
lot
of
them
that
can
actually
be
quite
overwhelming
and
that
overwhelmingness
can
actually
reduce
readability,
because
it
adds
a
lot
more
visual
noise
to
what's
going
on.
So
I'm
not
completely
sold
on
that
argument.
Personally,.
D
I
actually
think
that
we,
where
this
is
landing,
is
aligned
to
that
principle
in
the
sense
that
you
should
be
able
to
read
your
query
definition
that
tells
you
you
know
what
variables
are
are
required
and
know
fully
what
you
can
and
can't
send
without
having
to
go
like
dig
deep
through
document
nested
documentation
to
figure
it
out,
and
the
argument
that
you
just
made
benji,
I
think,
is
in
my
mind
that
what
made
me
convinced
that
this
is
the
right
approach,
which
is,
you
should
be
able
to
look
at
the
default
value
copy
that
put
that
in
as
the
value
for
your
variable
and
get
identical
behavior,
which,
in
the
the
logic
that
you're
proposing
here,
is
exactly
what
would
happen
and-
and
that
does
seem
to
pass
the
sort
of
readability
test
where
it's
doing
that
thing,
and
there
are.
D
D
I
don't
think
well
it's
a
little
bit
different
right
because,
with
the
interfaces
it's
about
assembling
the
the
schema
itself
or
maybe
what
do
you
mean
when
you
say
that,
do
you
mean
like
yeah.
A
D
It's
a
reasonable
point.
I
think,
there's
a
bit
of
a
distinction
there,
just
because
interfaces
are
an
inheritance
hierarchy,
which
is
a
little
bit
more
of
a
nefarious
legibility
problem,
where,
if
you
see
one
interface
that
especially
now
you
can
inherit
multiple
interfaces,
you
could
find
yourself
in
a
position
where
you
have
to
crawl
a
fairly
sophisticated
hierarchy
of
interfaces
to
be
able
to
know
what
fields
are.
Can
I
query
here?
D
What's
what's
accessible
and
the
intent
in
you
know
requiring
that
you
spell
out
the
full
shape
of
that
interface
was
to
you
know,
remove
the
need
to
go
crawling
through
the
list
of
documentation.
D
I
I'm
not
sure
that
the
same,
certainly
the
shape
of
this
problem
is
similar,
but
I
don't
think
it
is
quite
as
nefarious
as
the
interface
problem,
where,
if
you
see
a
particular
value
in
an
object
value
that
has
default
fields,
you
have
to
click
through
that,
anyway,
to
understand
the
nature
of
the
types
of
that
field
and
they're,
like
it's
more
like
crawling,
the
hierarchy
of
types
anyhow,
as
opposed
to
crawling
an
inheritance
tree
to
figure
out
the
definition
of
a
single
type,
and
I
think
I'm
also
remembering
benji
the
last
time.
D
We
talked
about
this,
the
realization
that
what
we
have
here
is
very
much
a
bug,
and
so
we
have
to
fix
it
one
way
or
the
other,
and
one
of
the
the
bugs
with
the
the
validation
rules
was
either
we'd
have
to
come
up
with
a
new
validation
rule
for
for
values,
specifically
for
default
values.
To
say,
like
this
value
is
legal
by
ignoring
all
nested
default
values
from
here
and
and
that
ended
up
being
some
fairly
complex
logic
in
its
own
right.
D
F
F
Well,
I'd
also
like
to
point
out
on
the
on
the
readability
point
of
view:
there's
nothing
in
this
that
prevents
people
from
expanding
those
and
even
writing.
Graphql
validation
or
linting
rules.
That
would
say:
hey
you've,
not
added
these
fields
to
the
default,
but
they're
going
to
be
applied.
Why
don't
you
add
them
in
so
it's
something
that
if
the
if
the
ecosystem
feels
is
an
important
thing,
it
can
be
added
by
the
people
that
implement
the
graphql
schema.
But
I
don't
think
that
it's
something
that
we
have
to.
A
The
the
second
issue
that
you
said
what
even
essentially
pointed
out
so
with
printing
it
out
the
same
way.
So
in
order
to
do
that,
you
need
to
then
essentially.
F
This
doesn't
make
any
change
to
the
schema
or
to
introspection
of
the
schema.
It
is
literally
a
a
change
to
execution
effectively,
so
it's
written
as
a
it's
written
as
part
of
the
coercion
rules
so
that
effectively
the
the
input
gets
coerced.
F
The
default
value
gets
coerced
at
runtime,
but
effectively
that
can
be
memoized,
so
you
can
actually
do
it
at
schema,
build
time
and
then
store
it
into
a
like
a
separate
thing,
but
it's
just
a
memorized
value.
It
wouldn't
ever
come
through
introspection,
so
no
it
doesn't.
It
doesn't
affect
any
of
those
things.
It's
fine,
it's
the
same
behavior
as
it
has
currently.
D
That's
actually
one
thing
that
I
think
we
should
explicitly
call
out
in
a
non-normative
note
is
that
most
service
rep
service
implementations
should
memorize
the
coercion
of
default
value.
F
How
would
you
do
that?
So
I've
put
a
note
in
as
you'll
see
at
the
at
the
bottom
of
the
pull
request
saying
this:
should
this
is
memorizable,
but
I
wasn't
sure
where,
to
put
that
note,
I
considered
putting
it
like
in
line
here,
but
inline
in
a
bulleted
list
seemed
wrong
and
further
away
from
here,
I
I
just
couldn't
work
out
the
right
place.
To
put
it.
D
You'll
notice
that
in
the
the
two
places
within
section
six
that
you
had
to
make
an
edit,
there
are
already
non-normative
notes
below
both
of
those
algorithms
and
I'd
probably
put
it
in
both
of
those,
and
you
can
literally
just
repeat
it
in
both,
and
in
fact
those
are
two
algorithms
are
almost
exactly
the
same
as
one
another
which
maybe
one
day,
we'll
figure
out
how
to
reconcile
them
to
be
the
same
algorithm.
But
that's
that's
probably
the
right
place
to
put
those.
A
So
with,
if
you
memorize
these
default
values,
if
you
memorize
objects,
they
could
be
because
they
they
could
be
non-read.
F
Yes,
I
think
that's
why
that
would
be
a
non-normative
note
right.
It's
effectively
an
optimization,
it's
an
optimization
that
if
you
believe
that
your
graphql
implementation
is
not
going
to
fall,
follow
then
by
all
means
use
this
optimization,
but
otherwise
just
do
it
like
the
the
algorithm
itself.
Has
you
do
it
every
single
time.
I
Just
qualifying
what
it's
not
a
big
issue
anyway,
since
we
do
memorization
of
correction
right
now
for
arguments,
because
if
you
have,
if
you
have
array
lists,
you
repeat,
resolver
for
every
item
of
a
list
and
inside
the
resolver,
you
have
access
to
like
ic
and
yeah
to
curse
values.
A
Okay,
but
so
so
how
I
meant
this,
so
how
we
actually
do
it.
We
have
the
literals
as
an
object,
so
we
don't
pass
them
so
and
we
use
these
literals
to
compose
from
them
the
actual
runtime
values.
That
is
not
the
impact,
then,
if
you
would
pass
that
we
memorize
for
mu
for
immutable
stuff
like
strings
and
dot
net
are
immutable
inside
mutable.
We
can
do
that,
but
for
many
objects
you
cannot.
You
cannot
memorize
them.
A
The
the
the
the
second
thing
here
is
that
its
input
values
we
are
talking
about,
so
they
in
most
things,
you
don't
have
like
huge
trees
of
input,
graphs
that
you
co
earth,
or
at
least
in
the
schemas
that
we
see.
So
it's
not
that
much
of
an
impact
like
if
you,
if
we
were
talking
about
output
data
that
always
have
to
be
passed
but
yeah,
I
agree
memoize,
where
possible
would
be
my.
D
D
That,
aside
from
having
the
note
here
about
getting
the
memorization
opportunity
correct,
it's
the
right
way
forward
cool
one.
I
One
thing
I
have
wait:
yeah
initially,
I
was
kind
of
for
alternative
approach
of
just
validating
values
instead
of
cursing
them,
but
yeah
agree.
Sorry,
it's
also
not
ideal,
but
it's
ticking
more
boxes
in
a
sense
and
in
a
sense
yeah.
So
but
I
have
a
question,
so
it's
basically
just
not
a
question.
I
would
like
a
note
that
we
all
were
that
it
basically
means-
and
there
is
like
a
bunch
of
different
representation
of
of
the
same
value
inside
like
introspection.
I
So,
for
example,
for
example,
like
question
rules,
allow
you
to
pass
one
one
value
instead
of
list
or
it
allows
you
to
pass
number
instead
of
id
so
default.
Representation
of
id
is
a
string,
but
you
can
pass
like
a
number
instead.
I
It's
not
only
like
default
default
fields,
the
photon
port
fields,
it's
also
like
other
customers.
D
That's
that's
just
for
the
taking
a
a
and
non-graphql
literal
value,
a
runtime
value.
I
D
I
Oh
yeah
yeah,
I
discovered
type
you
can
pass.
I
meant
well
so,
like
idea
for
id
type
before
representation
is
string,
but
you
can
also
pass
numbers.
So
basically
wait
just
know
it's
not
like
argument.
It's
argument
against,
but
I
still
think
it's
the
best
solution
it
can
come
yeah
is
that
like
inside
and
so
transfection?
Basically,
you
can
pass.
I
Imagine
like
we
have
list
of
ids
as
a
input
field.
So
as
default
value,
we
can
choose,
put
like
a
list
of
one
string.
I
We
can
put
a
single
string
or
we
can
put
like
a
number,
so
we
can
put
like
a
square
braces
and
quotation
five.
We
can
just
put
quotation
five
and
we
can
put
just
five
and
basically
it's
the
same
and
they
mean
the
same,
but
inside
the
introspection
we
will
probably
to
keep
to
keep
as
daily
reversible,
meaning
like
you,
you
put
a
deal
and
you
get
the
introspection.
D
No,
I
think
I
think
it's
an
argument
for
for
continuing
to
do
this
right,
or
maybe
I'm
misunderstanding,
but
either
way
I
want
to
make
sure
we
have
time
for
the
rest
of
stuff
this,
let's
get
like
examples
written
down
so,
okay,
two
actions
I
want
to
propose
out
of
this
one
is
one
that
I
just
did,
which
I'm
advancing
this
from
proposal
to
draft,
since
it's
now
in
a
state
where
I
we
think
other
than
non-normative
stuff.
G
Divergence:
okay,
let
me
link
the
issue
just
a
little
bit
explanation.
G
It's
more
a
lot
more
about
getting
some
feedback.
So
if
you
open
the
issue,
there's
a
so
one
of
the
most
complicated
validation
rules
we
have
is
about
overlapping
fields
which
basically
allows
you
to
kind
of
repeat
fields.
G
Well,
let
me
phrase
it
differently.
It
allows
you
it
doesn't
force
you
to
make
sure
that
every
field
is
unique
in
your
query.
Right,
especially
if
you
have
it
like
composed
queries
across
the
ui
you
you
can't
even
do
this
so
kraftker
lets
you
well
that
kraftker
lets
you
repeat
fields
all
over
and
the
engine
has
now
the
unthankful
job
of
merging
them
together
and
making
sure
that
the
field
is
only
executables,
and
this
is
the
whole
purpose
of
the
overlapping
field
rule
to
make
sure
that
this
merging
can
be
actually
done.
G
You
want
to
add
something
b
or
subscript.
This
sounds
right,
so
in
one
corner
case,
actually
you
merged
previously,
like
way
back
in
times
like
in
november.
2015
was
that
we
loosened
these
rules
for
object
types
which
can't
be
realized
at
the
same
time.
So
if
you
look
at
the
example
query
in
the
beginning,
you
have
like
pets
and
cat
and
dog
is
like
a
concrete
pet
and
it
can
be
at
run
time.
Actually
it
can
be
only
a
cat
or
a
dog.
G
So
this
is
why
this
is
why
the
above
query
is
correct
or
not
correct.
This
is
like
valid
because
you
can't
have
a
cat
or
dog,
so
it's
totally
okay
to
have
a
friend
which
is
actually
cat
friend
and
for
cats,
and
you
have
a
friend
which
is
a
dog
friend
for
dogs.
Even
if
the
reside
key
like
the
value
and
the
restaurant
is
friend.
O
G
G
G
Example
in
the
description
of
the
issue
and
you
have
value
which
is
a
cat
value
or
duct
value
which
are
scalars
not
like
complex
objects,
and
this
is
now
not
allowed
anymore,
because
the
current
rule
says
cat
value
is
not
equal
to
dot
value
because
one
is
int
and
one
is
float
so
so
this
is
rejected
and
kind
of
my
question
is
like.
A
G
A
M
I
think
the
next
step,
so
the
next
step
was
to
like
try
to
come
up
with
an
rfc
to
see
how
this
could
work
and
if
it
would
be
okay,
because
I
think
the
reason
we
wanted
to
change.
It
was
because
a
lot
of
client
folks
would
have
to
alias
these
fields,
which
can
become
like
really
really
tedious.
So
we
thought
if
we
can
come
up
with
an
rfc
and
see
like
you
know,
if
it
is
worth
doing
and
if
it
isn't.
You
know
too
much
of
an
issue.
M
Then
we
could
move
forward
with
it,
which
I
have
not
done
things
get
busy,
but
I
think
that's
where
it
was
left.
G
M
G
So,
just
just
to
be
clear
like
why
I
poked
around
a
little
bit,
I
I
feel
it's
very
inconsistent
at
the
moment,
so
I'm
not
sure
just
like
it's
not
just
about
losing
something
to
allow
more
it's
a
little
bit.
We
are
already
allow
quite
different
restaurant
shapes
for
the
same
name,
but
at
some
cases
we
don't
do.
S
E
Can
speak
to
this,
given,
I
am
probably
the
person
that
has
to
deal
with
the
code
base
that
currently
still
is
restricted
by
this
problem.
So,
basically
the
like
taking
a
step
back
when
graphql
was
first
introduced
to
facebook,
we
did
it
via
something
called
type
models
which
basically
models
generated,
match
the
schema
very
quickly.
We
found
out
that
that
was
like
a
terrible
way
to
do.
Models
on
the
client
and
the
models
that
we've
been
operating
with
for
the
last
six
years
mostly
have
been
what
we
call
response
models
which
are.
E
Basically,
if
you
look
at
the
json
response,
we
generate
models
that
exactly
map
what
the
fields
in
the
json
response
are
going
to
give
us
so
like
a
json
object
is
kind
of
a
generic
thing.
It's
okay!
If
there's
two
underlying
different,
like
object
types,
but
it's
not!
Okay.
If
a
field
ever
could
resolve,
if
field
in
the
json
at
the
same
point
at
the
same
level,
could
ever
resolve
to
either
an
integer
or
a
float,
because
like
in
java,
when
you
generate
a
model,
you
can't
you
can't
generate
a
model
unless
you
have
like.
D
Yeah,
that's
to
maybe
recap
the
in
the
critical
issue
and
the
rationale
for
this
original
constraint
is:
if
you
follow
any
path
through
the
resulting
payload,
you
should
statically
know
exactly
what
type
that
thing
will
give
you
and
designing
off
the
limitations
of
java
and
objective-c,
which
is
where
the
original
clients
for
these
were
built.
D
D
So
that's
the
reason
why
for
an
object,
you
know
it.
It
doesn't
actually
matter
that
that
object
is
a
high-level,
graphql
type
of
a
cat
or
a
dog.
It
just
matters
that
it
is
a
object
shape
that
has
fields
in
it
and
those
fields
also
have
to
match.
So
the
one
that
you
mentioned
in
the
chat
evan,
the
on
a
cat
narrowing
down
to
some
field
and
a
dog
narrowing
down
to
some
field.
H
E
H
G
G
If
something,
if
you
look
at
the
first
example
again,
I
placed
it
in
the
chat.
Also,
if
you
look
in
the
first
example
again,
it's
a
little
bit
different
from
what
evan
wrote
is
like
friend,
you
have
friend
cat
friend,
friend,
dogford,
and
actually
the
childs
are
different,
so
the
cat
friend
has
cat
friend,
name
and
dogfriend
has
dog
friend,
name,
okay,
and
this
is
also
valid
at
the
moment.
D
D
You'll
have
a
field
called
friend
and
on
friend,
you'll
have
two
fields:
cat
friend
name
and
dog
friend
name,
both
of
which
are
nullable
as
opposed
to
a
more
modern
type
system
might
instead
want
to
represent
that-
and
I
think
relay
actually
does
this
of
saying
that
your
pet
or
your
friend,
pet's
friend
field
is
going
to
either
be
an
object
with
a
single
property
cat
friend
name
or
an
object
with
the
single
property
dog
friend
name
and
then
represent
the
types
of
those
correctly
if
they
happen
to
be
non-nullable,
but
for
a
an
older,
less
sophisticated
type
system,
language
those
would
get
merged
into
one
response,
payload,
which
I
think
most
graphql
java
and
graphqlc
and
graphical
objective
c,
still
generate
their
model
responses.
E
D
So
if
I'm
remembering
correctly
from
a
few
months
back
when
sasha
brought
the
same
problem
up,
the
thought
process
out
was
if
this
validation
rule
is
yielding
net
negative
value.
For
the
vast
majority
of
modern
clients
which
are
typescript
and
kotlin
and
swift,
then
we
should
look
at
evolving
this,
and
in
doing
so
you
know
you
won't.
We
wouldn't
want
to
create
backwards,
breaking
work,
so
presumably
you
would
take
the
old
version
of
that
validation
rule,
transform
it
into
a
lint
rule
which
operates
the
same
way
as
a
validation
rule
but
or
optional.
D
E
D
Yeah,
so
relay
has
this
right,
where
there's
some
things
that
are
technically
valid
graphql,
but
are
not
valid
relay
graphql,
where
relay
is
slightly
more
strict
in
scenarios
where
it
wants
to
to
generate
smarter
models
or
do
something,
and
I
I
can
imagine
a
future
where
core
graphql
becomes
more
lenient
in
this
way,
but
tools
like
relay
or
like
other
in
the
facebook's
other
internal
tools
represent
the
same
sort
of
constraint,
but
as
an
additive
thing
as
part
of
that
tool,
rather
than
as
a
core
thing
of
the
of
the
library
itself.
D
That
could
be
reasonable.
I
I
just
my
hesitation
with
it
is
I
want
to
make
sure
that
it
is
we're
representing
that
problem
correctly,
that
it
is
purely
a
these:
are
the
oldest
systems
and
they're,
the
only
ones
that
suffer
this
constraint,
and
therefore
this
is
a
safe
thing
to
do
for
the
rest
of
the
graphql
ecosystem,
but
if
we
find
that
there's
like
actually
a
lot
of
stuff
across
the
ecosystem
that
would
end
up
being
broken
by
expanding
this,
then
we'd
want
to
pump
the
brakes.
I.
D
Well,
response
models
are
okay,
you
just
they
they
would
be
ambiguous
in
older
languages.
They
would
be
clear
like
if
you're
writing
a
response
model
in
typescript
and
you've
got
the
the
second
query
that
that
andy
wrote.
Then
you
would
just
say:
pet's
value
is
int
bar
float,
and
that
would
be
an
appropriate
response,
shape.
R
G
I
see
what
you're
saying
honestly,
I'm
like
I'm
very
happy
with
the
explanation
that
you
gave
in
terms
of
it
improved
a
lot
of
my
understanding
for
for
the
restriction
so,
and
I
was
not
aware
that
sasha
already
brought
this
up
in
the
previous
video.
I
could
not
find
anything.
A
So
I
think
it
still
adds
value
or
it
could
add
value
to
clients.
So
it
would
be
great
to
explore
that.
D
Yeah
this
this
restriction
is
narrowing
it
down,
so
that
we
guarantee
that
graphql
responses
can
be
well
typed
by
lots
of
painfully
subpar
type
generators,
and
it
would
be
nice
to
expand
it
to
say.
D
If
you
want
to
use
your
subpar
type
generator,
then
you
should
restrict
what
kind
of
queries
you
allow,
but
otherwise,
let's
leave
room
for
more
sophisticated
response.
Type
generators
to
exist
that
are
have
better
developer
experience.
So
that's
the
rationale
that
I
like
of
why
we
should
kind
of
keep
on
this,
recognizing
that
it's
a
little
bit
non-obvious,
but
in
the
meantime,
I
think
a
reasonable
action
item
is
to
just
add
a
little
bit
of
prose
for
this
particular
validation
rule
in
the
spec.
That
illustrates
a
little
bit
more
of
the
rationale
for
whites
there.
D
G
Yeah
like
in
to
to
highlight
this
in
this
specific
validation
theory
that
there
comes
like
the
two
different
constraints
into
place
that
you
want
to
have
a
clearly
executable
one
with
a
clear
type
response
strip.
I
think
this
combination,
which
forces
this
validation,
makes
it
so
hard
to
understand.
So
so
adding
a
little
bit
of
prostate
really
would
be
really
great.
D
Okay,
let's
keep
going
operation
express
expressions
benji.
This
is
yours.
F
Sorry
for
the
notes,
could
you
clarify
what
the
action
item
was
exactly.
D
Add
prose
or
non-normative
note
to
the
this
particular
validation
rule.
I
don't
remember
the
name
of
it,
but.
F
Okay,
lovely
thanks
all
right,
switching
from
note
mode.
Where
are
we?
What
are
we
looking
at
now
operation,
expressions,
operation,
expressions,
okay,
cool
so,
as
you'll
know,
mark
has
been
proposing.
His
schema
coordinates,
rfc,
which
I
think
is
excellent,
and
I
definitely
support
as
it
is.
One
of
the
things
that
I
was
interested
in
from
the
beginning
is
to
see
how
these
syntax
that
mark
has
come
up
with,
or
really
has
noticed
that
everyone
is
already
using
and
gone.
F
Let's
make
this
a
standard
how
that
could
be
expanded
for
other
use
cases.
So
we've
talked
about
this
in
previous
working
groups.
I've
discussed
how
I've
talked
about
it
with,
for
example,
daniel
danielman
from
apollo
and
various
other
people
to
see
what
the
various
use
cases
of
this
are.
F
My
main
motivation
for
bringing
this
up
at
the
working
group
is
not
to
analyze
the
syntax
that
I've
come
up
with.
It
is
instead
to
gather
more
use
cases,
and
this
document
was
originally
gathering
use
cases,
but
I
got
a
little
bit
carried
away
and
I
came
up
with
a
syntax
that
works
for
all
of
the
current
ones.
Do
not
constrain
yourself
by
this
syntax.
Also,
I
apologize
for
this
syntax.
F
Basically,
the
aim
is
to
understand
what
other
things
we
might
want
to
build
on
top
of
the
schema
coordinates
rfc
just
so
that
we
know
that
we
can
say
yes,
the
schema
coordinates.
Rfc
is
great.
Let's
merge
this
in
like
let's
make
this
an
official
thing
and
then
not
regret
it
later,
so
where
this
is
relevant,
for
example,
is-
and
we've
resolved
this
already,
but
I
want
to
raise
it
anyway.
F
We
discussed
before
about,
for
example,
arguments
on
fields
within
a
type
could
be
referenced
as
type
dot
field,
dot
argument,
or
they
could
be
referenced
with
type
dot
field,
parenthesis
argument
and
then
optionally,
a
colon
and
there's
a
bunch
of
different
syntaxes
that
were
proposed
as
part
of
the
schema
coordinates
rfc.
F
F
Obviously
we
could
use
any
other
symbol,
but
if
we
decided
that
a
period
is
what
we
want
to
use
for
namespaces,
then
using
the
period
in
the
schema
coordinates
may
not
be
so
desirable
so
broadly,
if
you've
got
stuff
that
might
be
able
to
make
use
of,
the
schema
coordinates
syntax,
but
in
a
in
a
broader
in
a
wider
use
case.
Please
tell
me
what
your
use
cases
are
to
give
you
some
ideas.
F
I've
outlined
some
use
cases
that
we've
discussed
previously
in
this
document,
so
one
is,
for
example,
referencing
a
position
within
a
graphql
operation
document,
so
you've
got
your
graphql
query
that
you've
written
and
you
want
to
reference
a
specific
field
within
that
and
that
might
be
within
fragments.
It
might
be
within
all
sorts
of
other
complex
things.
F
How
would
we
write
a
a
path,
for
example,
that
specifies
that
exact
thing?
Another
thing
that
I
came
up
with
was
we,
you
may
or
may
not
be
familiar
with
emmett,
which
is
a
way
of
building
html
documents
quickly
by
writing
out
effectively
css
classes
and
having
them
auto-complete.
F
I
propose
that
we
might
use
a
syntax,
such
as
an
extended
syntax
from
schema,
coordinates
to
build
documents
or
potentially
schemas
using
this
kind
of
syntax.
So
that's
another
potential
use
case.
F
Another
thing
is,
for
example,
document
permalinks
and
generally
just
linking
within
documentation
to
parts
of
like
a
query
or
in,
for
example,
graphical
when,
as
you're
in
graphical
browsing
through,
you
might
say
like.
Oh,
I
want
to
look
at
the
query
object
and
then
I
want
to
look
at
this
field,
and
then
I
want
to
look
at
like
the
connection
payload
type
on
that
and
then
the
edges
and
the
node
and
you've
navigated
through
a
big
chain
of
things.
F
Could
we
represent
that
in
the
url
in
a
standard
format,
and
I
figured
that
using
the
schema
coordinate
syntax
here
with?
Maybe
some
separators
could
be
valuable,
linking
within
the
documentation
to
how
you
might
reference
an
actual
field
in
a
in
a
query,
because,
obviously
not
all
fields
are
at
the
root
level
and
you
might
have
to
go
through
a
particular
path
or
there
may
be
many
paths
to
get
to
that
field.
F
Also
analytics
was
one
I
came
up
with
so
like
counting
how
many
times
particular
fields
are
used
and
what
path
they
were
used
via
a
lot
of
the
things
that
I've
come
up
with
are
path-based,
and
I'm
not
saying
that
this
has
to
be
constrained
to
paste.
If
you
can
think
of
other
things
great
but
yeah.
These
are
the
ones
I've
come
up
with
and,
as
it
happens,
I've
actually
used
this
syntax.
Whilst
writing
the
notes
for
the
previous
section.
F
So
if
you're
looking
in
the
live
notes,
I'm
just
going
to
bold
an
entire
section
here,
but
there
is
a
reference
where
we
were
discussing
the
the
path
through
a
document
comparing
the
cat
friend
name
and
the
dog
friend
name,
and
this
this
syntax
allows
us
to
represent
that.
F
D
Is
I
want
to
back
up
and
make
sure
I'm
understanding
the
problem
being
solved
in
the
intent?
Is
the
intent
to
go
broad
and
explore
all
possible
future
use
cases
such
that
we
can
make
smarter
decisions
about
syntax
choice
in
future
proposals,
or
is
this
specifically
about
adding
something
to
the
graphql
language
to
solve
a
specific
problem.
F
J
And,
and
are
you
asking
for
like
specific
use
cases
right
now
or
are
you
just
kind
of
raising
awareness
and
pointing
us
to
the
to
the
dock.
F
If
you've
got
specific
use,
cases
right
now,
I'd
love
to
hear
them,
but
yeah
otherwise,
by
all
means
like
a
pull
request
to
the
dock
or
something
like
this,
I
don't
know
whether
it
would
make
sense
to
merge
this
as
a
really
early
rfc,
so
that
other
people
can
raise
pull
requests
against
it.
Potentially.
J
Yeah
so
I'll
give
this
a
comment
as
well
make
sure
that
people
aware
of
this,
but
I
just
had
two
super
small
thoughts.
Number
one
is
well.
First
of
all,
it
looks
great
so
thanks
for
extending
this
thanks
for
doing
this,
it
looks
amazing
and
definitely
solved
some
of
the
like
comments
that
people
had
the
schema
coordinates
stock,
so
this
is
definitely
needed.
J
So
one
thing
I
was
thinking
of
is
like
would
relative
expressions
be
possible
because
I
was
thinking
for
like
definite
like
when
you're
deprecating
your
fields
and
you
feel
like
a
different
like
a
little
deprecation
notice
like
use
this
field?
Instead,
I
can
imagine
some
sort
of
like
tooling
to
also
generate
that
message
for
you
and
if
you're
like
you,
know,
renaming
the
field
or
something,
and
then
you
want
to
do
like
a
relative
expression.
So
I
don't
know
if
that's
like.
F
J
Yeah
and
then
the
other
one,
my
other
thought
was
just
to
like
bike
shed
for
a
half
a
second,
not
really
bike
shed,
but
just
something
that
came
up
with
the
schema
coordinates
thing.
We
we
landed
on
the
just
dot
separator
for
everything
pretty
much,
and
this
was
brought
up
by,
I
believe
ivan,
and
I
kind
of
like
appreciated
it.
J
I
didn't
appreciate
it
at
the
time
as
to
why
it
would
be
a
problem,
but
when
I
went
to
do
the
graphql
js
like
function
implementations
to
generate
the
ast,
it
makes
much
harder
having
the
the
single
dot
to
the
separator
for
ast
purposes.
So
I
think,
like
visually
like
as
as
humans,
the
the
dot
separator
and
the
greater
than
arrow
separates.
The
use
in
here,
I
think,
makes
sense,
but
it
may
make
the
like
asd
functions
slightly
harder,
but
that
might
be
a
trade-off
worthwhile.
I
Just
a
four
question
because,
like
use
case
for
for
specifying
alternative
fields
to
use
or
just
referencing
like
inside
description,
referencing
other
fields-
it's
like
compelling
use
case,
but
I
thought
schema
coordinates
was
enough
for
that.
So,
like
I
can
just
say,
instead
of
wrist
field,
please
use
type
name,
dot
new
field.
F
Yes,
so
you
raise
a,
but
that
is
a
particularly
interesting
question
and
I
think
one
of
the
reasons
that
this
is
valuable
is
for
example,
if
you
have
a
root
level
field
on
the
query,
object
and
you
deprecate
that
and
you
want
to
say
instead
use
you
know
user.name
or
something
like
that.
F
That's
great,
it
tells
you
what
the
name
is,
but
it
doesn't
tell
you
how
to
get
it
like
if
there
was
a
thing,
if,
if
you
had,
for
example,
at
the
root
of
your
query,
something
that
said
current
username
and
you
said,
go
and
see
user.name,
that's
like
great,
that's
a
user's
name.
But
how
do
I
get
me?
How
do
I
know
how
what
my
current
user's
name
is
so
showing
what
the
path
through
the
graphql
to
replace
a
field
is,
could
be
valuable.
I
Follow-On
travel
for
quite
big
non-trivial
exchanges.
If
it's
so
deep,
I
don't
think
we
can
do
it
like
syntax
that
cover
everything
I
think
like
if
it's
like,
if,
if
it's
sub
links
so
like
you
just
rename
a
field
and
just
want
to
specify
another
one
schema
cardinal
is
enough.
If
it's
like
whole
type
was
the
name,
it's
also
kind
of
enough.
We
just
move,
but
if
it's
something
major,
we
need
probably
to
provide
sample
quality
anyway,
to
or
link
to
a
better
documentation,
because
it's
like
big
change.
I
Like
I
think,
having
having
like
special
syntaxes
should
should
be
restricted
to
to
only
only
if
it's
improved
for
a
developer
experience
so
for
for
many
things
of
for
returning
stuff
inside
the
introspection
or
for
like
returning
stuff
inside
errors.
We
can
use
like
just
structures,
but
special
syntaxes
are
good
if
it's
like
intended
to
be
consumable,
consumed
by
users
directly
or
users
need
to
like
to
have
like
pattern
recognition.
But
why
schema
cardinal
is
like
it's
used
in
many
places,
so
people
already
starting
recognizing
it.
I
I
It's
like
I'm,
not
sure
we
need
to
invent
developer
experience.
D
Well,
let's,
let's
that's
part
of
why
I
asked
what
the
what
the
intent
and
goal
is
here
is.
I
want
to
make
sure
you
focus
on
that
and
if
the
intent
goal
is
let's
expand
broadly,
so
we
can
make
smarter
syntax
decisions
on
current
proposals.
F
F
There
is
potentially
a
question
over
directives,
but
for
the
the
other
parts,
I'm
perfectly
happy.
D
That's
great,
I'm
super
happy
to
hear
that,
because
I'm
with
yvonne
there's
like
if,
if
we're
gonna
start
to
bend
this
in
the
direction
of
actually
taking
some
of
these
explorations
and
adding
them
to
the
spec,
we'd
wanna
apply
a
much
more
careful
eye
of
critique
and
make
sure
that
we
start
with
the
problem
and
look
through
all
of
our
options,
but
certainly
as
a
syntax
exploration
and
various
potential
things
we
want
to
do
in
the
future.
D
F
So,
in
response
to
what
you
were
saying
ivan,
this
is
effectively
already
in
use
in
the
apollo
studio,
the
apollo
graphql
studio.
So
when
you're
navigating
through
the
documentation,
they
already
indicate
the
different
like
types
that
you're
going
through
the
fields
that
you're
going
through
and
they
even
use
like
the
greater
than
symbol
as
a
separator.
Now,
it's
obviously
a
css
styled
separate
bits
with
clickable
links,
but
it
is
already
in
use
for
describing
these
things,
and
these
use
cases
were.
F
F
These
are
things
that
people
are
doing
like
wanting
to
be
able
to
represent
a
state
within
graphical
is
something
that
we
want
to
do
wanting
to
represent
how
you
would
find
a
particular
field
through
the
graphql
tree,
rather
than
just
saying
it's
this
field
on
this
type
and
then
not
knowing
how
to
get
there.
That
is
a
pain
point
that
apollo
actually
made
a
point
of
saying:
we
show
you
like
the
shorter
routes
to
get
to
that
field
because
it
may
be
relevant
and
having
a
nice
syntax
for
doing
that.
F
I
So
like,
I
think
it
would
be
less
question
and
more
more
collaboration
if
we
have
like
visual
cases
inside
documents
so
like
maybe
even
screenshot
from
a
power
studio
showing
how
it's,
how
it
represented
there,
and
maybe
other
actors
will
contribute
some
more
stuff
so
mo
trying
to
generalize
more
like
we
have
like
with
use
cases
right
now.
Yeah.
F
O
D
D
J
The
last
time
we
spoke
about
it,
it's
stage,
is
it
stage
one
or
two
right
now
I
can't
remember,
but
I'm
sorry,
the
last
time
you
spoke
about,
I
think
you
wanted
to
you
wanted
me
to
add
some
functions
to
graphql
js,
to
do
the
like
ast,
passing
and
serialization
and
stuff,
and
I
kind
of
haven't
had
a
huge
amount
of
spare
time.
The
last
recently
used
various
things,
but
I
am
gonna
focus
back
on
that's
relatively
soon.
J
D
D
F
I
was
just
reading
through
the
chat
and
mark
andre
raised
that
building,
for
example,
selection
sets
like
to
select
schema
members.
That
is
a
nut.
That
is
definitely
something
that
I
would
like
to
consider
as
well.
It
may
not
be
part
of
the
syntax
that
I've
proposed
in
this
document,
but
again,
that's
not
the
point
of
the
exercise.
That
may
be
something
that
we
want
to
consider
see
what
that
might
end
up,
looking
like
to
see,
if
that
is
a
match
for
schema,
coordinates
so
yeah.
Thank
you
mark
andre.
D
Good
point:
let's
keep
going
introspection
or
directives
via
introspection
support.
Andy
this
one's
yours.
G
Hey
again,
it's
between
me
and
benji
today
yeah.
G
So
this
is
I'm
not
sure
this
is
a
famous,
but
it's
it's
a
well-known
issue,
300
in
our
craft,
respect
which
was
created
by
oleg
who's,
unfortunately
not
with
us
anymore,
but
he
writes
the
very
interesting
and
and
still
valid
point
that
well
directives
are
not
introspectible
like
you
can
get
directives
which
are
supported
by
the
engine,
but
you
can't
find
out,
for
example,
that
a
field
has
an
ad
important
directive
by
introspection
and
I'm
like
there's
a
big
discussion
over
the
years,
and
I'm
I'm
not
here
to
to
start
all
of
the
discussion
again,
it's
actually
too
much
to
read.
G
O
G
We
have
now
two
well-known
implementations,
exposing
directors
via
introspection
and
the
design
itself
is
actually
allowing
to
kind
of
push
this
forward.
And
it's
more
like
an
announcement.
I'm
doing
here
it's
and
we
can
talk
about
specific
things,
but
the
actual
design
is
also
not
so
important,
but
I
think
it's
still
a
missing
point.
You
know,
because
that's
my
overall.
A
Sentence,
I
want
to
say
yeah
the
one.
The
one
issue
I
see
there
is
that
we
should
at
least
publish
so
we
copied
from
so
we
are
implementing
it
at
the
moment
also,
and
we
copied
it
from
your
issue
over
the
schema
and
stuff,
but
we
there
should
be
some
specification
for
this
still
where
you
can
grab.
If,
if
you
want
to
follow
that
that
you
can
grab
the
thing,
the
the
the
one
thing
I
I
think
is
a
bit
of
pity.
A
I,
like
the
former
design
more
where
you
have
these
extensions
and
actually
can
have
an
extension
point
in
your
introspection,
and
I
think
that
was
also
the
way
originally
even
was
going
that
you
have
an
imp
point
extension
where
you
can
also
put
other
other
type
specific
data
or
custom
data.
There.
G
We
can
still
have
an
extension
point,
but
for
this
specific
directive,
yeah
like
we
and
trafficker
driver
choose
to
line
with
craftgirl.net
because
we
didn't
want
to
fragmentize
the
ecosystem.
G
A
That's
the
reason
why
we
follow
you
so
that
there
are
more
implement
that
there
is
more
implementations
that
follow
the
same
thing
and
we
don't
actually
end
up
with
a
couple
of
different
approaches
to
that.
But
we
should
we
should
at
least
write
a
rfc
or
something
like
that.
We
could
also
help
on
that.
I
mean
if
we
want
to
share
work
on
that.
G
But
we
yeah
we
should.
I
didn't
know
that
you,
I
didn't
know
that
you
ought
to
do
it
so,
like
that's
great,
to
hear
so
yeah,
I'm
happy
to
write
a
quick
document
also
where
we
kind
of
outline
in
informal
spec
where
people
can
follow
up
on
this
yeah.
We.
A
G
G
A
That's
why
I
say
I
I
I'm
willing
to
help
you
there
and
I
think
I
don't
know
his
name,
some
gamers
so
from
graphql.
That
would
also,
I
think,
chime
in
there.
So
we
would
have
multiple
people
that
could
do
work
there,
but
that
we
initially
have
one.
G
All
can
go
and
put
the
information.
I
think
that
would
be
great
if
we
collaborate
on
this.
That
sounds
awesome
like
question
to
the
room.
Do
you
know
more
implementations
of
this
across
the
ecosystem?
Like
I
think
somebody
asked
in
the
chat,
if
it's
in
ruby
to
be
known,
does
anybody
know.
I
Allows
you
to
add
additional
fields
inside
introspection,
but
they
don't
expose
directives
one
one
thing.
So
I
did
extension
two
types
in
graphql,
js
and
initially
people
was
kind
of
against
it,
but.
I
But
I
communicate
the
reasoning
why
and
I
still
like
stand
by
them,
that,
like
directives
have
like
short
and
nice
names
but
like
it,
was
connected
to
sdl
so
in
a
major
way,
and
so
I
think
from
graphql
js
users.
I
convinced
like
people
to
to
start
using
extensions
and
they
use
more
and
more
and
they
attach
to
types.
But
as
you
write,
they're
not
exposed
through
through.
I
D
Let's
definitely
get
an
rfc
assembled,
so
we
can
start
collecting
the
various
implementations
and
reconciling
one
thing
that
I
would
very
much
like
to
see
is
a
problem-oriented
approach
to
the
rc.
Exposing
directives
through
introspection
is
a
solution.
I
want
to
make
sure
that
that
is
a
solution
of
many
solutions
that
we
can
choose
from
that
solves.
A
problem
that
we
want
to
solve,
especially
since
just
raw
exposing
directives
through
introspection
could
yield
a
bunch
of
side
effects
that
we
don't
want
like.
If
you
have
a
directive,
that's
purely
for
internal
consumption.
D
Only
and
now
it's
exposed
through
introspection.
You
need
control
over
whether
that
happens
or
not.
We
also
don't
want
to
just
like
roll
this
out
and
then
suddenly
expose
everyone's
internal
directives
on
their
schema
out
to
their
customers
if
they
were
not
intended
to
be
exposed
in
that
manner.
So,
there's
just
like
a
bunch
of
problems
that
we
got
to
make
sure
we
get
ahead
of
as
we
go
to
go,
build
this
and
then
also
I
remember
a
couple
of
years
ago,
one
of
the
last
times
we
talked
about
this.
We
recognized
that
directives.
D
If
you
just
purely
take
the
data
in
a
directive
and
try
to
map
it
back
out,
then
it
ends
up
in
a
structure.
That's
not
always
super
helpful
to
consume
and
so
like.
We
got
to
make
sure
that
we're
exposing
the
data
through
introspection
in
a
way.
That's
that's,
reasonably
easy
to
consume
and
solves
problems
that
people
have
and
that's
a
bit
short
coming.
A
A
It
would
be
a
pity
if
we
have
multiple
of
these
implementations,
but
that's
kind
of
not
so
nice,
and
I
think
there
was
also
ivan's
approach
to
have
an
extension
point
where
you
can
essentially
create
a
better
output
structure,
because
on
graphql
directives
we
have
essentially
input
data,
and
with
that
we
could
try
form
essentially
better
output
data,
but
it
allows
for
aligning
graphql,
sdl
and
introspection.
So
essentially
you
don't
have
a
shortcuting.
A
L
From
from
our
perspective,
we
don't
we
think
this
is
really
important.
It's
really
it's
like
a
a
gap
that
we
can't
get
the
directives
or
some
form
of
that
that
kind
of
stuff
over
the
introspection,
but
for
your
concern,
lee
somewhere
up
there
in
issue,
300
I'd,
put
a
suggestion
that,
like
we
have
the
repeatable
word
that
on
directives
you,
you
could
put
a
keyword,
I
think
I
had
exposed
and
so
then,
by
default
nothing's
exposed.
So
it
keeps
backwards
compatibility.
A
Yeah
we
just
we
just
we
just
thought
about
the
same
issue,
because
we
there
are
users
in
of
a
chocolate.
They
have
that
have
authentication
directives
where
they
essentially
expose
which
group
or
which
policy
allows
people
to
access
something,
and
we
didn't
want
to
expose
these
automatically.
That's
why
we
have
this
internal,
but.
L
Yes,
I
think
it's
really
common.
I
think
there
there
are
many
directives
which
are
how
I
do
stuff
on
my
back
end
and
I
it's
nobody
else's
business,
but.
L
D
This
is
exactly
what
I
want
to
see
is
is
just
to
make
sure
that
we
are
exploring
the
gamut
of
solutions,
because
I've
also
seen
this
proposed
as
like
a
metadata
directive
where
the
fields
that
you
pass
in
can
be
structured
out.
I
know
yvonne
has
variations
of
that
idea
too.
We
should
just
make
sure
that
we're
here's
the
problem
at
hand,
here's
a
handful
of
solutions
going
forward.
D
Here's
existing
prototype
implementations
of
some
of
those
that
exist
in
the
ecosystem,
so
that
we're
like
taking
this
as
a
problem-oriented
approach
that
we
can
evaluate,
rather
than
narrowing
in
too
soon
on
a
particular
solution.
Just
because
some
implementations
are
already
following
that
prototype
path.
That'll
give
us
a
lot
of
confidence
that
we're
not
just
like
following
a
momentum
that
we're
actually
approaching
it
from
first
principles.
G
Yeah,
a
few
last
comments.
First,
we
actually
let
you
filter
out
all
directives
like
programmatically,
because
it's
a
valid
concern.
You
don't
want
to
expose
all
of
them.
I
totally
agree.
The
other
thing
is
because
it's
not
officially
spec,
for
example,
we
didn't
go
down
the
road
and
added
a
new
syntax
or
new
directives
like
repeatable
or
public,
and
we
didn't
expressly
didn't
do
it
because
this
would
have
been
gone
too
far
in
our
heads
to
introduce
something
that
is
not
spec
compliant.
G
You
know,
like
that's
a
challenge.
You
want
to
do
something
which
is
not
in
the
spec,
so
you're
kind
of
limited
or
you
need
to
find
your
own
way.
G
O
G
Last
thing
is
yeah,
it's
it
it's
kind
of.
We
follow
the
spec
strictly
overall,
but
this
is
simply
an
issue
that
came
up
too
often
and
too
much,
and
we
also
have
like
we
as
a
maintainer.
We
have
projects
we
want
to
expose
certain
directives
in
terms
of
the
problem
lead
that
you
mentioned
it's,
it's
it's
metadata
around
schema
right,
that's
a
problem
like
like.
We
have
information
that
I
expressed
in
directives
on
the
schema,
and
we
have
other
two
links
that
what
processes
or
rely
on
this.
G
D
And
I
I
don't
mean
to
imply
that
doing
this
via
exposing
directives
is
the
direction
that
I
don't
think
will
work.
I
I
just
want
to
make
sure
that
we
don't
omit
other
potential
paths,
because
we're
like
pre-sold
on
that
particular
path
and
therefore
missed
something
that
might
be
worthwhile
and
help
us
lead
to
a
better
final,
solve
yeah
and
also.
A
I
mean
in
this
particular
case
we
feature
like
that
because
you
have
to
opt
in
and
then
you
have
these
additional
introspection
fields
that
apply
directives,
and
this
way
you
can
try
it
out.
I
mean
we
can
always
walk
that
back
when
they,
but
that's
why
I
say
we
need.
We
need
an
rfc
document
like
for
input
unions,
where
we
just
can
mingle.
D
F
I'm
definitely
also
interested
in
this,
so
I
can.
I
can
lend
some
time
there,
though
I'm
taking
them
quite
a
lot
at
the
moment.
No
sorry
benji
the
water's
full
sorry.
G
D
L
Yeah,
I
don't
know,
I
also
don't
I
I
would
have
ridden
some
pr
myself
if
I'd
had
time
for
it.
I
think
it's
really
important,
but
I
haven't
had
time
so
I
don't
know
how
much
time
I'm
volunteering,
but
I
don't
have
many
constraints,
I'm
more.
I
want
to
see
it.
My
interest
is
more
that
we
want
something
standard.
We
need
something
that
that
everybody's
doing
so
we
can
use
it.
L
D
All
right.
Let's
keep
going.
We've
got
the
perennial
topic
of
input
union
slash
one
of
benji,
this
one's
back
to
you.
F
Yeah,
I
I
put
this
one
at
the
end,
which
I
thought
you
know
it's
gonna
be
a
long
one.
So
I'll
put
it
at
the
end,
but
also
I'm
tired,
right,
okay,
so
input
unions.
We
have
discussed
this
a
lot
over
the
last.
F
What
year
and
a
half
we've
gone
around
in
circles
a
bit,
and
this
is
the
latest
write-up
that
I
have
for
my
solution,
which
is
very
broadly
very
similar
to
the
first
one
that
I
raised,
the
one
field
directive,
which
was
may
2019
so
yeah,
not
not
far
off
two
years
now
so
before
we
go
into
it.
I
just
want
to
stress
that
this
doesn't
have
to
be
a
directive.
F
At
the
moment
we
have
used
a
directive
for
the
syntax,
because
it
means
that
I
don't
have
to
write
spec
edits
to
add
additional
syntax,
but
we
may
decide
that
the
correct
syntax,
for
this
is
a
keyword
or
some
other
alternative
syntax
form,
and
there
are
various
proposals
of
those.
So
do
not
judge
it
as
a
directive,
which
is
I've,
heard
a
lot
of
things
going
on
anyway.
Whatever.
F
Tired
laying
things
out
I
shouldn't
be
so
what
this
is
is
a
proposal
that
we
introduce
types
to
the
graphql
specification
for
input,
objects,
sorry
for
the
fields
on
input,
objects
and
for
arguments
on
output
type
fields.
That
would
allow
us
to
say
that
exactly
one
of
these
things
must
be
present.
F
So,
for
example,
if
you
want
to
find
a
user
within
your
system,
you
might
do
it
using
their
graphql
global
object,
identifier,
the
id,
then
you
might
want
to
do
it
by
their
email
address.
You
might
want
to
do
it
by
their
username
or
by
some
combination
of
details.
You
got
from
somewhere
else
like
an
organization
and
a
registration
number
or
some
other
combination
of
things,
and
at
the
moment,
how
we
generally
model
that
model
that
in
graphql
is
we
add
multiple
fields
for
accessing
these
one
with
each
of
the
set
of
potential
arguments.
F
F
Looking
at
github,
for
example,
like
you,
could
potentially
treat
issues
and
pull
requests
as
a
polymorphic
input,
type
looking
at
say,
medium
you've
got
all
the
blocks
in
the
document
where
you
might
have
a
paragraph
block
or
an
image
block,
or
a
video
block
or
a
pull
quote
block,
and
those
are
different
types
of
blocks
that
you
would
want
to
specify.
F
And
one
thing
to
keep
in
mind
is
often
these
will
actually
take
the
form
of
a
tree
structure
as
well.
So
I
imagine,
if
you
wanted
to
represent,
say
a
trello
board.
You
might
do
that
as
a
nested
structure
of
input
of
polymorphic
inputs,
so
we
have
come
up
with
a
whole
bunch
of
different
potential
solutions
for
this
problem.
We
have
discussed
them
at
length
both
in
the
working
group
and
also
in
the
input
union's
sub
working
group
and
the
one
that
is
currently
leading.
F
Is
this
one
primarily
because
of
its
simplicity,
because
it
doesn't
take
much?
It
doesn't
change
the
graphql
spec
much
and
it's
relatively
compatible
with
existing
clients,
which
is
an
interesting
side
effect
as
well.
F
What
we
are
effectively
doing
is
just
taking
the
input
type
or
the
field
that
we
already
have
and
just
flagging
it
in
some
way.
Just
saying
this
is
a
one-off,
and
that
gives
us
these
these
new
capabilities.
F
F
I
think
I
think
in
full.
Actually,
I
think
I've
pretty
much
laid
out
everything
that
I
want
to
in
the
rfc,
so
there's
probably
going
to
be
mistakes
in
there.
There's
certainly
things
to
discuss,
there's
plenty
of
like
bike
shedding
to
be
done,
but
this
is
a
full
rfc
that
if
we
all
agreed
with
could
be
merged
in,
I
believe
so.
That's
the
state
that
I
feel
that
this
is
at.
So
I
wanted
to
make
you
all
aware
of
this.
F
D
The
exploration
to
know
that
if
we
were
to
expand
it
in
more
places,
does
the
pattern
is
the
pattern
potentially
expandable,
but
I
I
I
think
we
might
be
better
off
with
a
focused
rc
proposal
to
the
actual
spec
text,
especially
since
for
arguments
there's
like
and
also
another,
very
reasonable,
short-term
path
here,
which
is
to
take
an
input,
object
as
a
single
argument
and
allow
that
input
object
to
also
have
one
of
which
is
a
pattern
that
I
know
a
lot
of
graphical
apis
already
use
and
and
that's
a
completely
reasonable
schema
design.
H
You
may
have
end
up
like
if
you
have,
you
could
end
up
with
one
of
at
the
variable
level,
two,
which
is
a
whole
other
can
of
worms.
Don't.
F
You
that's
still
a
concern
with
input
objects.
H
D
D
But
I
I
see
what
you
mean
in
terms
of
like
if
you
have
variables
for
the
different
one
ofs
in
in
that
scenario,
how
does
that
work?
I
don't
have
an
intuitive
sense
of
how
it
should
work.
You.
F
F
D
H
F
It
already
works
so
effectively.
We
differentiate
between
something
being
not
present
and
something
being
null,
and
we
can,
I
believe,
carry
that
through
yeah.
We
we
can.
We
can
carry
that
through
the
variable
level.
Well,
I'm
saying
we
can
we
can
in
graphql
js,
because
I've
done
it.
F
You
know
I've
noticed
that
the
thing
is
not
there,
even
though
I've
got
a
variable
for
it,
so
by
not
specifying
that
variable
it
comes
through
as
if
it
was
not
specified
on
the
object,
I'm
not
sure
if
that's
actually
a
graphql
spec
thing
or
just
specifically
how
graphql
js
works
so
yeah,
maybe
more
research
is
required
there,
but
broadly,
I
think
it's
fine
and
also
I
have
outlined
so
you'll-
see
that
there's
a
there's
a
table
in
the
spec
in
section
three,
around
line
1638
there's
effectively
a
spec
of
what
the
literal
value
is,
what
the
variables
are
and
what
the
result
of
that
should
be,
and
you'll
notice
that
that's
directly
below
a
very
similar
table
that
refers
to
input.
L
F
D
I
think
where
we'll
have
to
have
special
care-
and
this
might
be
space
for
us
to
to
actually
go
build
some
reference.
Implementation
code
is
the
variable
validation
rules,
because
you
have
to
type
your
variables
at
the
top
of
the
query
and
then
your
variables
can
appear
within
the
body
of
of
those
input
objects.
D
So
are
we
confident
we
can
have
a
scenario
where
we
can
appropriately
type
those
variables
and
the
types
flow
through
yeah,
because,
especially
because
the?
If
you
have
a,
if
you
have
one
of
those
fields-
and
if
you
say
this
input
object
is
a
one
of
then
each
independent
field
is
now
non-nullable.
That
implies
that
all
of
those
variables
also
must
be
non-nullable,
and
you
might
end
up
in
a
situation
where
we
require
providing
all
of
the
variables.
H
Yeah
I
just
as
I
was
looking
over
this
table.
Thank
you
benji.
This
is
a
great
way
to
frame
my
thoughts,
we're
missing
at
least
one
case
here,
which
I
just
left
in
a
comment,
so
that
we'll
have
to
figure
that.
H
D
I
don't
have
an
intuitive
sense
of
what
the
right
behavior
is,
but
we
should
dig
into
that.
Yes,
aside
from
that,
I
you
know.
We
both
agree
that
this
approach,
everything
but
the
syntax
for
it,
which
you
very
rightfully
call
out
and
that
rfc
is
completely
up
for
bike,
shedding,
though
I
think
leaning
in
the
direction
of
using
a
directive
is
completely
within
line
of
how
we've
done
this
kind
of
thing.
In
the
past
re-deprecated
fields
we
represent
as
a
directive.
D
I
see
this
is
along
similar
lines.
It's
a
it's
a
property
of
that
thing,
but
we
use
directives
the
way
to
show
that
syntax,
like
description,
also
description
yep.
Another
great
example:
that's
that
one
shows
up
as
an
inline
string,
but
yeah.
A
I
they're
definitely
almost
the
right
one
yeah.
A
D
H
I
don't
actually
know
if
we
have
it
for
the
concept
of
variables
specifically
or
just
for
arguments
and
input
fields,
because
variables
can
only
they
only
have
the
one
state.
They
only
have
the
bang
or
not
the
bang,
whereas
arguments
it
gets
not
provided
or
provided
as
explicit
null
or
provided
as
an
actual
value.
I
F
H
F
E
E
E
E
R
E
A
I
Yeah
so
quick
return
back
to
original
discussion.
It's
a
question:
do
we
need
to
all
people
to
specify
unpacked
input
unions,
because
there
is
no
problem
with
part
one?
So
if
you
use
variable
with
cat
and
dock
variable
of
input,
union
type,
everything
is
okay.
You
just
need
to
inside
json.
You
just
need
to
put
cat
dog
cat
fish.
I
D
That's
that's
the
right
question
you
could
go
as
far
as
to
say
if,
if
you
just
like
make
that
illegal
right,
if
if
an
input
object
is
a
of
a
type
one
of
then
you
can't
put
variables
inside
it.
D
I
don't
know
if
that's
going
too
far
or
not.
It's
certainly
a
blunt
hammer
to
solve
the
problem.
You
just
make
the
potential
case
go
away.
I
think.
Actually.
The
crux
of
this
is
the
the
type
changing
behavior
of
you.
You
specify
the
field
as
non-nullable,
but
through
the
introduction
of
the
one
of
modifier,
the
types
all
of
a
sudden
become
non-nullable,
which
independent
of
this
particular
variable
issue.
I
already
was
a
little
bit
wary
of
this
behavior.
F
Sorry,
I
sorry
I
mentioned.
I
was
tired.
This
is
all
wrong.
We've
required
the
inner
one
of
I
have
thought
about
this
and
have
solved,
and
it's
all
fine
yay
in
a
one-off
object.
Every
field
must
be
nullable,
so
it
is
required
that
the
fields
are
all
nullable,
so
non-nullability
isn't
a
concern.
All
the
variables
are
have
to
then
be.
Would
then
be
none
non-nullable.
Actually,
you
could
make
a
variable
non-nullable
as
long
as
you
only
provide
one
of
them
and
then
effectively.
D
So
there's
a
difference.
I
mean
this
is
still
quirky
right
and
we
should
oh
yeah
the
thing
that
I
think
is
the
weakest
point
of
the
proposal
so
far,
and
maybe
that's
just
where
we
have
to
settle.
It
is
there's
a
difference
between
the
static
time
type
and
the
runtime
type.
So
the
static
time
type
says
these
are
nullable
and
the
runtime
types
is
that
they
are
in
fact
not
nullable.
D
A
F
I've
been
very
explicit
in
the
definition
of
it
that
effectively
it's
one
field
and
that
field
is
non-null,
so
I
am
not
planning
to
represent
the
case
of
this,
that
you
specify
one
field
and
that
field
is
null.
That's
not
a
desired
use
case
effectively.
There
is
one
non-null
value
and
every
other
value
is
omitted.
D
That
works
around
this
problem.
I
think
you
we
will
have
to
be
especially
careful.
There's
a
assumption
being
made
based
on
the
current
validation
rules
around
variables
and
their
placement
within
input
objects
that,
because
we
validate
that
the
variable
type
is
at
equal
or
more
specific
than
the
placement
that
you
find
it
that.
Therefore,
you
should
be
able
to
take
those
values
and
flow
them
through
without
coercion,
or
rather
you
should.
D
D
So
you
might
have
already
accounted
for
that,
but
that
seems
like
part
of
the
fiddly
edge
and
corner
case,
but
maybe
just
to
back
up.
I
think
my
my
recommendation
here
stands,
which
is
we
gotta,
go
write
some
real
code
and
write
a
bunch
of
unit
tests
against
this,
and
this
is
one
of
those
scenarios
where
you
write
the
spec
text
to
inform
the
code.
R
F
Yeah
in
in
summary,
though,
I
think
all
of
these
concerns
are
already
addressed
in
the
current
rfc
and
I
believe
back
to
what
I
said
before.
I
think
it
is
technically
mergeable,
so
I'm
I'm
happy
to
start
progressing
this,
but
I
would
love
some
reads
of
the
rfc
to
make
sure
that
I've
not
missed
anything
but
yeah.
I'm
I'm
generally
happy
with
it.
A
But
what
what
did
we
say
now?
Are
we
just
applying
it
on
on
input
objects
or
are
we
keeping
it
working
on
arguments.
D
F
That
makes
sense
to
me
I'm
happy
to
merge
them
in
two
stages.
I
think
the
arguments
I
mean,
as
we
know,
arguments
in
the
input
objects
are
very
similar,
so
the
the
differences
are
quite
slight,
but
smaller
changes
are
better.
My
main,
my
main
concern-
I
guess
at
this
time,
is
what
syntax
should
we
use
and
if
we're
only
going
to
use
this
with
input
objects
like
in
the
end
and
we're
never
going
to
use
it
with
arguments,
then
it
may
make
more
sense
to
use
a
custom
syntax.
F
I
have
been
consistent
in
the
rfc
to
call
these
one
of
input,
objects
and
one
of
fields,
so
I
do
call
them
as
if
they
are
a
different
type,
so
putting
a
keyword.
There
would
make
a
lot
of
sense,
though,
in
introspection
they
are
definitely
represented
as
the
same
thing.
F
F
Syntax
is
definitely
a
question
if
we
were
to
extend
this
to
arguments
as
I
have
done
in
the
rfc.
One
of
my
concerns
that
I
have
is
that
the
directive
that
you
apply
to
the
field
is
effectively
applying
to
the
arguments.
F
It's
saying
there's
one
of
the
arguments,
but
you
actually
apply
it
to
the
field,
so
it
goes
after
the
type
definition
of
the
field
it
which
actually
removes
it
from
the
context
of
where
it
actually
kind
of
applies,
and
I'm
not
super
happy
with
that,
but
also
I
couldn't
justify
any
of
the
alternative
syntaxes
at
this
stage.
F
If
we
want
to
continue
this
with
an
input,
objects
only
and
then
potentially
add
arguments
later,
that's
something
that
we
need
to
address
now,
even
though
we're
not
actually
going
to
implement
it.
Because
if
we
decide
that
we
find
the
one-off
directive
to
be
unpleasant
and
actually
undesirable
for
arguments,
then
we
don't
want
to
use
it
for
input
objects
either.
So
it
kind
of
needs
resolving,
even
though
we
may
not
actually
include
it
in
the
final
rsc.
So
as
lee
says,
it's
still
an
exploration
at
this
stage.
F
D
Two
thoughts
for
you,
one
relevant
to
what
we're
talking
about
one
that
unfortunately
circles
back
on
our
previous
conversation,
and
I
promise
I
will
keep
that
one
tight.
So
we
don't
revisit
or
re-litigate
that
so
first,
this
part
of
the
reason
why
I
want
us
to
kind
of
separate
the
one
argument
from
one
field:
I'm
I'm
a
little
nervous
that
in
an
attempt
to
solve
both,
we
we
weaken
the
power
for
its
primary
use
case,
which
is
for
the
input
objects
and
like
from
a
practical
point
of
view.
D
If
you
decided
calling
this
one
field
is
more
clear
or
maybe
one
of
is
fine,
but
in
the
argument's
case
you
want
to
call
it
one
argument
such
that
the
directive
name
doesn't
align.
Maybe
that's
fine.
Maybe
we
have
like
two
directives
that
describe
similar
behaviors
but
are
slightly
different
and
in
fact
it
might
actually
be
worthwhile
to
clarify
like
this.
Actually,
these
yield
out
slightly
different
behaviors,
and
it's
it's
worth.
D
D
If
we
apply
that
to
literals,
then
this
problem
goes
away
as
well,
which
is
to
say
you
I
this.
D
Maybe
it's
a
rehashing
of
what
yvonne
was
suggesting,
but
it
just,
I
think,
makes
it
a
bit
more
crisp
that
if
you
see
you
know
your
your
pet
input
object,
one
of
input
objects,
and
you
see
it
spelled
out
with
cat
colon
something
dog
colon,
something
that
should
just
be
an
immediate
hard
validation
error,
regardless
of
whether
those
things
are
values
or
variables,
because
you're
seeing
two
fields
in
a
one
of,
and
don't
do
that
and
that
limits
our
ability
to
put
variables
a
layer
deeper
in
there,
but
it
also
circumvents
that
entire
landmine
problem,
and
so
that
might
be
a
way
to
do
that
that
doesn't
apply
for
one
argument.
D
So
one
argument
you
buy
that
problem
right
back
where
you
could
put
multiple
variables
in
your
arguments,
but
it
at
least
solves
it
for
the
field
problem
and
maybe
all
the
more
reason
to
narrow
focus
down.
F
F
I
I
like.
The
idea,
though,
is,
is
a
cunning
way
of
solving
the
problem,
but
no
I'm
already.
We
have
the
situation
with
variables
where,
when
you
specify
them
as
part
of
input
objects,
the
variables
can
still
differentiate
between
not
present
and
not,
and
I
think
we
should
just
continue
that
through.
F
I
see
no
reason
to
break
that
and
to
add
the
additional
code
that
is
required
to
break
that
and
to
then
explain
to
people
over
and
over
again
why
we
broke
that,
like
once
it's
out
in
the
world
I'd
rather
it
just
behaved
the
same
broadly.
D
Do
you
feel
like
we
have
clear
next
steps
and
feedback
collected
concerns
raised
syntax?
I
I
don't
think
we
should
live
like
shed
syntax,
that
we
should
like
such
since
that
bike
shed
syntax,
but
we
should
do
that
in
a
place
where
we
can
write
out
code
and
evaluate
it,
which
is
in
the
context
of
that
rfc
100
agree.
D
Thank
you
for
your
hard
work
on
this
benji.
I
know
it's.
We've
been
working
this
space
for
a
long
time
and
followed
many
paths
and
snipped
them
all
off
and
have
come
back
to
this
path.
So
it's
giving
us
a
lot
of
confidence
that
we're
in
the
right
direction.
Even
though
there's
still
a
couple
problems
left
to
solve.
D
I've
marked
this
one
as
proposal
rfc,
one
just
so
that
we
keep
track
of
it.
F
Cool
sounds
good,
so
I
guess
primarily
the
next
steps
are
people
contribute.
What
do
you
think
of
the
syntax?
What
do
you
think
of
the
rfc
text
itself?
F
D
That's
our
last
topic
on
the
agenda.
Anything
else
we
need
to
cover
or
announce
before
we
wrap
up
for
the
day.
F
D
No
problem
huge
thanks
to
you
for
doing
that
every
month.
So
it's
very
much
appreciate
it.
H
E
R
H
D
Okay
feel
free
to
proactively
tag
those
before
benji
gets
them.
If
you,
if
you
want
I'm
going
to
be
reviewing
those
over
the
next
week
or.