►
From YouTube: GraphQL Working Group - June 2, 2022
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).
A
A
Good
good,
almost
ready
for
texas.
A
A
But
they
are
cool.
Did
you
see
the
topics
yeah,
I'm
looking
forward
to
what
matt
will
be
talking
about.
A
A
A
A
C
Yeah,
that
was
the
original
proposal,
for
this
right
was
that
it
was
just
going
to
be
a
here's.
The
status
quo
here
is
how
people
generally
do
things,
but
then
the
question
came
up
which
it
may
have
been
my
fault
for
the
the
content
type
yeah,
and
what
we
figured
then
was
actually
the
content
type
is
without
the
content
type.
Then
you
can't
really
do
the
status
codes
like
it's.
C
You
can't
reliably
interpret
it
right,
so
we
basically
we
wanted
to
make
it
as
if
it
was
required-
and
I
think
lee's
opinion
on
it
was.
It
doesn't
have
to
be
just
a
reflection
of
the
status
quo.
It
can
also
say
what
the
situation
should
be,
but
I
also
like
it's.
I
think
it's
pretty
critical,
that
we
don't
you
know,
go
overboard
and
start
specifying
how,
like
you,
know,
websockets
work
and
how
it
works
over
sse
and
things
like
that,
like
we
need
an
initial
1.0
that
is
basically
the
status
quo.
C
I
had
to
step
back
from
it
for
a
while,
because
I
was
just
too
busy
with
other
things,
but
I
I
am
actually
keen
to
start
getting
getting
going
again
on
that,
so
it's
possible.
Maybe
maybe
we
can
start
setting
up
some
working
groups
again.
B
A
E
E
A
C
Well,
the
clients
are
the
ones
that
perform
content
negotiation
right,
so
they
the
client,
should
be
indicating.
I
want
the
graphql
http,
the
graphql
mime
type,
but
failing
that
I
want
jason
and
the
server
should
look
at
that
automatically
and
if
it
only
supports
json,
then
it
will
just
respond
with
json.
It
should
just
work,
it
shouldn't
be
breaking.
I
think,
unless.
A
C
C
Yeah,
that
is
true,
but
also,
if
you
don't
set
an
accept
header,
it's
unlikely
that
you
are
interpreting
the
content
type
header
on
the
response.
So
in
that
case,
if
you're
ignoring
headers
on
the
way
out,
you're,
probably
ignoring
them
on
the
way
in,
in
which
case
it's
not
a
breaking
change,
either.
A
Yeah,
but
the
status
quo
are
then
I
said
so
so,
like
the
specification
is
today,
it
will
then
use
the
status
code
behavior.
C
A
C
C
And
yeah
yeah,
I
think
we
should,
as
best
we
can
to
support
basically
all
the
legacy
setup
that
everyone
has,
while
still
seriously
encouraging
the
use
of
this
content
type,
because
without
it,
as
I
say
that
the
status
codes
aren't
useful.
So
if
we
can
start
encouraging
people
to
use
them,
but
do
it
in
a
way
where,
if
you
don't
use
the
accept
header,
then
we
just
fall
back
on
the
legacy
behavior.
But
you
should
send
an
accept
header
yeah.
I
think
that's
sufficient.
A
Yeah
because
the
issue
that
andy
had
was
that,
I
don't
remember
which,
but
I
think
the
the
jetbrains
plug
in
for
I
don't
know
if
it
was
not
ryder,
but
for
for
their
java
suite,
they
started
implementing
the
the
client
specification
and
then
it
didn't
work
with
the
graphical
java
server
anymore.
C
We
should
hop
off
of
this
now,
because
this
time,
it's
ticked
over.
B
A
B
B
Unfortunately,
just
bad
timing,
but
there's
a
good
number
of
folks
going
from
apollo
for
sure,
which
is
exciting
everybody's
looking
forward
to
it
a
lot.
F
C
Yeah,
I
I
also
have
this
this
issue.
C
C
C
H
So
so
I
understand
it's
it's
also
available.
Virtually
is
that
I
think
that's
what
you
said
on
twitter
lee.
F
That's
my
understanding,
yeah
is
that
they're
gonna
have
a
live
stream.
H
B
F
Yeah,
it's
it's
free!
Now,
it's
also
they're
gonna
have
the
in-person
tickets
be
free,
like
the
basically
the
week
before
they're
gonna,
go
to
the
ut
and
offer
a
bunch
of
college
kids?
Oh.
F
Yeah
always
good
to
do
that.
Anyhow,
we've
got
quite
a
lot
of
things.
Our
agenda
doc
today
super
excited
to
get
into
it
all.
So,
let's
kick
things
off.
We've
got
16
folks,
here
too
so
healthy
crew.
Today,
all
right
welcome
everybody
to
the
june
2022
edition
of
the
working
group
meeting,
of
course,
as
per
usual
by
us
all
showing
up
here.
That
means
we
agree
to
the
membership
agreement,
participation,
guidelines,
contribution
guide
and
code
of
conduct,
links
to
all
of
those
in
the
agenda
always
worth
the
read.
F
I
wrote
them,
I
think
they're
pretty
reasonable.
Some
of
them
are
dry.
Some
of
them
have
a
little
bit
of
creativity.
Swirl
to
them
always
always
useful
to
take
an
extra
look.
There's
links
there
for
your
perusal,
but
as
we
usually
do,
let's
do
a
quick
round
of
just
quick
names
to
faces.
F
I
think
most
of
the
folks
here
are
familiar,
but
you
know
every
every
meeting
there
always
ends
up
being
a
handful
of
folks
who
are
new
faces,
so
it's
always
good
to
get
names
to
faces.
We
will
go
in
the
order
that
it
appears
in
the
agenda
markdown
file
and
I'm
at
the
top
of
that
so
hello,
everybody.
My
name
is
lee.
J
K
Hi,
I'm
bernard.
I
work
with
martin.
C
D
F
B
K
Hugh
here,
hi
hi
evan.
H
Okay,
I'm
with
postman
and
I
was
going
to
make
an
announcement,
but
I
better
not
do
it
if
it's
going
to
be
public.
F
I
don't
know
how
many
readers
or
viewers
we
get
that
it's
mostly
for.
B
H
Well,
so
yeah
all
right,
I'm
gonna
go
ahead
and
do
it
I'm
gonna
take
so
they
asked
us
not
to
to
post
this
on
social
media.
So
technically,
that's
not
what
I'm
doing.
H
I
am
a
member
of
the
first
cohort
of
rust
foundation
fellows.
I
just
found.
N
H
F
That's
fantastic,
thank
you.
Did
we
miss
anybody
else.
F
Welcome
matt
for
those
of
you
who
did
an
intro
and
your
name
doesn't
appear
on
the
agenda.
Yet,
please
just
send
a
pull
request,
we'll
make
sure
we
get
emerged,
it's
always
good
to
make
sure
we
have
a
good
roster
of
who
we've
got
to
show
up,
awesome,
well,
fantastic,
to
see
many
familiar
faces
and
a
handful
of
new
ones.
Welcome.
F
F
Roman's
got
some
some
general
spec
issues
to
dig
into
and
then
metafields
on
the
sdl.
That's
a
fair
amount
of
stuff.
Is
that
the
right
set
of
things?
Are
you
missing
anything?
Does
that
order
sound
right
to
everyone.
F
Sounds
good
cool
silence
is
golden.
Looks
like
we've
got
the
right
side
of
things
all
right
before
we
dig
into
that
agenda.
Let's
make
sure
we
have
any
action
items
that
need
dealing
with.
We
can
deal
with,
looks
like
we
have
three
that
are
tagged
ready
for
review.
Thank
you,
benji
for
the
grooming
as
per
usual,
all
right,
adding
non-normative
note
that
graphql
requests
are
not
the
same
thing
as
http
requests.
C
I've
addressed
that
with
a
very
minor
pull
request
to
the
spec,
so
it
needs
some
review,
but
at
least
the
initial
action
there
has
been
taken.
So
now
it's
just
at
the
review
stage,
so
please
feel
free
to
chime
in
there.
F
Fantastic.
Thank
you.
I
marked
the
pull
request
as
an
editorial
change,
since
that
seems
to
be
what
it
is
we'll
close
the
action
item
since
we've
got
stuff
going
on
and
we'll
review
that,
one
at
a
later
date,
adding
the
security
document
to
the
github
repo.
I
think
I
merged
that
one
for
you
already,
which
means
we're
done
right,
correct.
F
Fantastic,
thank
you
for
doing
that
very
cool
that
we
can
have
the
top
level
github
repo
that
just
scatters
those
things
all
the
right
places
very
cool
feature.
We
wanted
to
have
a
discussion
thread
on
naming
conventions
for
client,
controlled,
nullability
and
you've
created
such
a
thread
so
fantastic.
F
I'm
sure
you'll
tell
us
about
that.
A
little
bit
later
awesome
happy
to
see
three
of
our
previous
action
items
closed.
We
still
have
a
handful
of
open
ones
from
last
meeting,
just
looking
at
them
final
editorial
review.
I
think
that
one
is
on
me
intersection
pro
type
proposal:
refining
tests,
yakov
that
one's
on
you
stream
and
defer
intruding.
Our
spec
wording
is
accurate,
perhaps
I'll
hear
a
little
bit
about
that
later.
F
Client
controlled
null
ability
then
has
two
other
open
ones:
a
feedback
on
alphas
and
digging
into
the
ast.
But
those
may
not
be
urgent.
G
And
I
I
think
we
can
close
the
one
about
adding
more
tests.
Also,
I
think
it'll
be.
F
Which
one
was
that
intersection
type
so
you're
talking
about.
G
C
There's
just
one
other
thing
that
I
wanted
to
raise.
I
don't
want
to
discuss
it
here,
but
I
just
want
to
make
you
all
aware.
I've
opened
an
issue
asking
whether
two
hours
per
two
hours
once
a
month
is
long
enough,
because
we
keep
having
some
long
meetings
and
I
suspect
this
one
is
going
to
be
a
long
one
as
well
so
by
all
means,
engage
on
that
issue,
but
not
for
discussion
right
now.
F
Let's,
let's
tack
that
one
to
the
end
and
if
we
run
out
of
time
to
not
talk
about
it,
then
maybe
that's
another
feather
in
your
cap
for
why
this
is
a
worthwhile
thing
to
talk
about
so
happy
to
toss
in
that
bit
of
recursion.
But
yes,
thank
you
for
opening
that
benji.
These
meetings
used
to
be
three
hours
and
we
talked
about
them
being
a
little
too
grueling
and
cut
them
back
to
two,
but
always
worthwhile.
To
have
conversation
about
that.
L
F
I,
like
it,
keep
an
eye
on
the
clock
all
right.
Well,
what
you
say
is
true.
We
have
quite
a
lot
of
things
to
dig
into
so,
let's
dig
into
them
and
we'll
try
to
hold
ourselves
to
the
the
timing
here.
The
first
one
up
is
yours,
benji,
so
floor
is
yours.
C
Cool,
thank
you.
Okay.
So
there
are
a
lot
of
different
ways
of
taking
multiple
graphql
schemas
and
merging
them
into
one
larger
graphql
schema.
Sometimes
these
graphql
schemas
are
just
in
different
files
on
your
file
system,
sometimes
they're
on
remote
network
locations.
Sometimes
there
are
other
services,
there's
lots
and
lots
of
different
things
that
are
going
on,
but
it
is
quite
common
in
the
ecosystem
to
try
and
build
one
larger
graphql
schema
from
a
lot
of
smaller
ones.
C
There
are
approaches
like
apollo's
federation,
there's
schema,
merging,
schema,
stitching
graph,
kill
modules.
Pazura's
got
the
graph
kill,
joins
I've
forgotten
for
a
moment
what
the
there's
a
there's,
a
number
of
other
ones
as
well,
so
there's
loads.
C
So
I
thought
it
would
be
quite
neat
if,
for
the
common
functionalities
that
all
of
these
different
things
depend
on
or
where
they
are
relatively
common
between
them,
if
it
was
a
if
we
were
to
able
to
define
like
a
specification
so
that
everyone
can
use
this
commonality
and
then
really
add
value
in
the
places
where
things
actually
differ,
rather
than
everyone
reinventing
everything
every
time.
C
So
what
I
thought
I
would
do
here
is
say
here:
I've
got
this
idea.
What
do
you
all
think?
But
in
the
interim
I
opened
the
issue
and
we've
had
so
many
so
many
people
interested
in
this.
There
is
currently
43
comments
on
the
threads.
We've
got
lots
and
lots
of
the
different
companies
that
are
using
these
things
or
building
these
things
involved,
including
the
likes
of
azura
apollo,
the
guild
and
various
other
people
as
well
key
players
and
also
key
users
of
these
technologies.
C
So,
basically,
I
propose
that
we
open
a
working
group
to
explore
this
to
see
where
there
is
commonality
and
to
see
if
we
can
build
some
kind
of
shared
specification
for
some
kind
of
foundations
that
we
can
all
build
on.
F
I
dig
this
a
lot
by
the
way
I
thought
occurred
to
me
relevant
to
what
you're
talking
about
before
about
whether
or
not
he
did
more
time.
F
We
have
a
handful
of
these
things
that
are,
we
kind
of
run
like
parallel
working
groups,
and
I
think
I
mentioned
before
I'd
like
to
start
thinking
about
these
like
subcommittees.
So
there's
one
working
group,
that's
us
a
lot
and
we
have
a
handful
of
things
that
sort
of
spin
out
and
demand
more
time
and
one
of
the
like
a
nice
operating
mode
that
I'd
like
for
us
to
get
into
is
for
these
things
that
really
do
deserve
more
than
15
minutes
once
a
month.
F
They
ought
to
be
breakout
sort
of
subcommittees
with
the
set
of
folks
who
care
the
most
about
it
to
get
into
the
weeds
together
and
go
through
all
of
the
like
sub-topics
involved
here
and
use
these
monthly
meetings
to
basically
report
progress
and
then,
basically,
what
you're
doing
benji
like
ask
for
those
who
are
interested
to
come
join
the
next
handful
of
meetings,
and
then
you
can
kind
of
decide
whether
you
want
to
meet
monthly
or
twice
monthly
or
whatever.
Cadence
makes
sense.
Whatever
phase
that
that's
in.
C
I'm
very
much
in
favor
of
that
one
thing:
one
key
thing
that
you
said
there
was
about
the
reporting
back
and
I
think
that's
what
we
lack
a
little
bit
at
the
moment.
I
think
some
of
these
subcommittees
feel
uncomfortable
like
bringing
their
topics
to
the
working
group
meet
because
they
don't
want
to
like
cloud
up
the
agenda.
C
So
if
we
had
a
way
of
basically
like
time
boxing
that,
like
this,
isn't
a
period
for
discussion
of
this
stuff,
unless
they
need
a
discussion,
in
which
case
by
all
means
file,
a
discussion
topic
but
just
status
updates
of
here
is
where
we're
at.
If
you're
interested.
If
you
agree,
if
you
disagree
here,
is
how
to
get
involved.
N
F
F
Is
what's
your
what's
your
action
here,
benji,
do
you
just
want
people
to
be
aware
of
this?
Are
you
do
you
want
to
look
to
set
a
time
to
dig
into
this?
What's
next.
C
F
Sounds
good
to
me,
I
think
you've
identified
a
real
problem
domain.
At
least
I
mean
it's
entirely
possible
that
you
dig
around
and
you're
like
never
mind.
There
isn't
actually
enough
overlap
ground
here
to
standardize
something,
but
you
can
only
do
that
after
seriously,
considering
the
space
so
seems
very
worthwhile
to
have
a
set
of
crew
come
together
and
talk
about
it.
C
Excellent,
in
which
case
I
guess
the
next
step
would
be
to
merge
that
document
that
I've
raised
and
then
we
can
get
other
people
adding
themselves
to
it,
and
I
will
set
about
organizing
an
initial
time
which
I'll
try
and
do
based
on
the
locations
that
people
put
in
there
see.
If
I
can
find
a
small
window
that
overlaps,
I
imagine,
that's
going
to
be
quite
challenging,
but
we'll
do
our
best.
L
Can
I
suggest
something
so
probably
to
make
it
clear
this
way
or
the
other
way
so
that
the
result
of
this
of
the
work
of
this
group?
It
would
not
be
some
sort
of
standardized
apollo
federation
kind
of
thing
for
runtime
and
so
on,
but
no
changes
no
suggested
changes
to
this
to
the
official
spec.
What
I
feel
like
this
kind
of
effort
might
actually
result
in
recommendation
to
this
group
to
add
something
modular
features
to
the
main
specification.
F
I
think
it's
definitely
a
possibility
yeah.
I
I
put
the
realm
of
potential
output
of
this
being
either
or
or
both
of
a
sort
of
companion,
spec
of
if
you
are
doing
composite,
schemas
or
schema,
merging
or
federation.
Here
are
the
building
blocks
by
which
you
should
do
it.
That
is,
you
know
you.
You
could
completely
abandon
that
and
still
call
your
think
graphql.
It's
an
additive
spec.
L
Module,
let's
say,
keyword
or
something
right:
okay,
so
just
just
to
say
that
this
is
a
possibility
as
well,
because
from
the
text
it
looks
like
it's
mostly
about
runtime
kind
of
merging
from
existing
yeah.
You
know
apollo,
like.
F
The
framing
that
I
would
say
is
that
I
I
don't
want
to
apply
any
constraints
at
this
phase.
I
would
want
to
wait
for
a
recommendation,
so
if,
if
the
subcommittee
comes
back
and
feels
strongly
that
the
right
way
to
go
about
this
problem
is
with
key
additions
to
the
core
grammar,
then
fantastic,
like
we'll,
have
a
conversation
about
that.
G
I'll
I'll
throw
in
one
one
thing
here:
well,
where
you
can
feel
frida,
but
the
topic
of
you
know,
merging
multiple
schema
forming
composite
schemas
is,
as
benji
showed,
has
a
lot
of
very,
very
interesting
subtopics
that
are
useful,
but
also
could
be
even
thought
of
their
own
kind
of
things
like
identifying.
G
A
way
to
you
know,
identify
objects,
you
know
for
caching
that
might
be
useful
for
caching
relay
and
all
sorts
of
different
things
as
well
as
transforming
schemas.
That's
also
pretty
interesting
on
it
in
its
own
right,
so
it
could
be.
It
could
be
that
this
could
get.
G
You
know
super
interesting
and
I'm
not
you
know
and-
and
I
think
it's
great
to
to
explore-
you
know
to
explore
that,
but
we
might
end
up
maybe
having
a
couple
different
add-ons
that
sort
of
fit
together
in
some
way,
and
that
could
be
exciting
too.
C
Yeah,
I
completely
agree
with
that
interpretation
yeah
and
from
from
my
point
of
view,
like
I'm
particularly
interested
in
ivan's
topic
at
the
end
of
today,
the
the
metadata
stuff,
because
I
see
that
that
may
well
be
a
precursor
that
we
need
for
any
composite
schema
spec.
I
do
like
at
the
moment
I'm
thinking
it's
going
to
be
one
or
more
separate
specifications,
but
we
will
be
contributing
back
to
the
main
spec
for
functionality
that
we
need.
So
I
think
it
aligns
with
everything
that's
been
discussed
so
far.
F
Awesome
well
seems
like
we
have
a
pretty
clear
next
step.
Thank
you,
benji
for
leading
the
charge
here
and
I'll
leave
it
to
you
to
set
some
times
for
that
subcommittee.
Let's
get
to
the
next
piece.
Martin,
that's
yours!
Experimental
directive,
voicers.
J
It's
not
going
to
take
long.
I
I
can
really
show
you
it's
only
five
minutes
to
to
set
up
the
stage,
I'm
here
to
talk
about
at
experimental,
which
is
the
counter
part
of
the
created
for
new
fields
in
your
graphql
api.
This
is
issue
number
943.
If
you
haven't
checked
it
out
yet
it's
on
the
graphql
spec
repo
and
you
cannot
click
my
presentation.
J
I
guess
you
can
find
it
on
the
graphql
spectrum
before
diving
into
the
the
details,
a
little
bit
of
concept,
context
of
one
use
case
why
this
came
up.
I'm
a
client
developer.
I
work
for
apollo
kotlin,
so
I
do
a
lot
of
mobile
apps,
mainly
in
addition
to
obviously
a
lot
of
libraries
and
I'm
working
on
this
small
app.
That's
a
conference
app,
so
it
has
a
very
simple
schema.
J
Each
session
has
an
id
a
title,
description,
lots
of
fields
and
we
wanted
to
add
a
start
date
and
an
end
date
and,
as
you
know,
time
is
odd.
So,
as
we
were
working
on
this,
we
had
a
lot
of
questions
about
whether
it
should
include
the
time
zone
or
whether
it
should
be
just
local
date.
How
do
we
format
this
everything
and
everything?
J
We
ended
up
naming
that
start
instant
and
instant,
and
we
were
feeling
kind
of
okay
like
this
could
work,
but
we
were
not
100
sure
it
will
scale
and
it
will
work
in
the
long
run,
but
we
still
wanted
people
to
be
able
to
build
apps
with
that,
but
not
send
them
to
production
abuses.
So
we
were
like
what,
if
we
could
signal
something
like
this
to
the
front
and
developers
that
feel
the
given
field
is
experimental,
so
entering
experimental.
J
Look
at
the
proposed
definition
for
the
directive:
it's
really
the
deprecated
counterpart.
So
it's
a
directive.
You
can
put
it
on
field
arguments,
input,
fields
in
values,
and
it
also
has
a
reason
as
far
as
I'm
concerned,
I'm
always
using
experimental
or
something
like
this,
but
as
we'll
see
later,
there
might
be
other
other
usages
there.
J
And
the
nice
thing
is
that
it
allows
a
lot
of
nice,
tooling,
like
in
addition
to
signaling
in
the
api,
that
the
field
is
experimental
in
kotlin
we
can
do
code
gen
and
we
can
add
quickly
annotation
representing
the
graphql
variety.
So
this
experimental
here,
it's
an
apollo
annotation.
It's
an
apologization
that
says
if
you're
using
this
field
be
aware,
it
might
change
backwards.
J
Incompatible.
Curtin
has
all
these
nice
opt-in
requirements
which
are
themselves
experimental.
So
it's
a
lot
of
experiment
all
over
the
place.
But
the
important
thing
to
remember
is
that
if
you're
using
an
experimental
field
inside
your
code
and
you're
using
coaching,
you
will
have
the
warning
directly
inside
your
id.
Something
like
this.
J
Tooltip,
you
will
also
have
it
if
you
combine
from
the
command
line,
so
you
can
think
of
use
cases
where
you
have
a
given
build
for
production
and
this
build
fades
whenever
a
warning
is
triggered,
so
that
make
sure
that
you
never
ship
an
app
with
experimental
fields
in
production,
and
if
you
really
really
want
to,
you,
can
remove
the
warning
by
adding
another
experimental
annotation
in
the
code.
J
There
are
a
few
people
are
already
using
something
similar
in
the
wild
and
critical
are
more
than
this
list.
But
github
has
something
called
schema
preview
where
you
can
get
a
subset
or
you
get.
You
can
get
different
version
of
a
schema
by
using
the
http
accept
header.
So
if
you
want
to
have
the
merge
info
for
an
example
which
is
not
stable,
yet
you
you
just
send
the
http,
I
don't
know,
there's
a
long
line
with
with
my
type
and
you
get
the
extra
fields.
J
I
think
someone
mentioned
the
netflix
fuse
is
deprecated
for
this
reason
to
filter
them
out
from
from
introspection
with
a
reason
experimental,
which
is
kind
of
fun.
I'm
pretty
sure
there
are
other
other
places
which
I'm
forgetting
about
here,
and
that
leads
me
to
the
last
slide,
which
is
questions
so
first,
one
is
for
me
the
winning
and
experimental
reason.
J
I'm
I'm
myself
always
going
to
put
something
like
this
field
may
change
without
warning
in
the
backwater
incredible
way,
or
something
like
this
and
second
question,
which
is
actually
linked
to
the
first
one
is:
do
we
need
to
put
more
metadata
to
this
directive
to
accomplish
something
like
the
gita
previews,
where
you
can
have
several
set
of
fields
grouped
together?
J
Third
question
and
first
question
are
also
linked,
and
I
think
this
is
a
big
one.
It's
about
introspection,
and
this
is
why
I'm
also
super
curious
about
the
presentation
from
ivan
later
today
is
how
do
we
filter
these
experimental
fields
in
introspection?
Do
we
include
them
by
default?
Do
we
not
do
we
make
a
parameter
like
for
deprecated
fields
and
more
generally
like
how
do
we
communicate
this
to
the
client,
and
that
was
it
for
my
small
presentation?
It
was
my
last
night,
so
thank
you
for
listening.
N
I
feel
like
that
is
a
highly
needed
directive,
but
I
wonder
if
we
could
create
one,
that's
more
broad,
more
flexible,
something
for
lack
of
a
better
name
like
a
with
comment,
so
that,
although
you
could
add
whatever
text
you
wanted
and
it
could
apply
to
experimental,
it
could
also
apply
to
anything
else
that
we
hadn't
thought
of
today.
N
F
Yeah,
that's
my
sense,
too,
is
like,
let's
start
with
the
mechanism
that
we
want
and
then
how
to
describe
it.
So
you
pointed
to
kotlin,
I
think
that's
actually
really
interesting,
because
thank
you
for
having
a
another
reference
of
where,
where
this
kind
of
behavior
is
happening,
interesting
happening
thing
happening
in
kotlin,
is
they
started
with
an
experimental,
annotation
and
then
deprecated
it
in
favor
of
opt-in,
for
the
same
reason
that
gabe
you
just
mentioned
right.
That
experimental
is
too
specific
and
they
wanted
to.
F
Instead
talk
about
the
mechanism
which
maybe
then
would
imply
some
behavioral
changes
that
you
might
want,
which
is
you
know
the
this
is
how
deprecation
works
as
well.
It's
like
they
do
not
appear
in
introspection
unless
you
explicitly
ask
for
them,
and
and
maybe
that
we
would
want
a
similar
behavior
here.
I
had
one
thought,
which
is:
you
know
with
deprecated
stuff.
It
kind
of
makes
sense
that
there's
like
a
list
that
is
constantly
added
to,
but
with
opt-in
or
or
experimental
you
you
might.
F
It
may
be
the
case
that,
especially
for
a
larger
schema,
there
could
be
like
many
different
experimental
things
happening
simultaneously
and
it
might
be
dangerous
to
say.
Okay,
I
want
to
include
all
that
experimental
stuff,
but
only
to
use
this
one
very
specific
feature,
and
now
I've
opened
up
this
whole
surface
area
of
potential
problems.
For
you
know
my
huge
imagine,
you're
a
company
with
100
fronted
engineers
using
your
your
stack
and
they've
got.
You
know
dozens
and
dozens
of
experimental
features
available.
F
It's
like
you
either
have
all
of
them
or
you
have
none
of
them.
That
doesn't
seem
like
the
right
mechanism,
so
it
could
be.
You
know,
rather
that
you
have
this
open
question
about.
F
Do
we
need
a
like
an
experimental
reason,
or
maybe
that's
actually
just
like
flag
name
or
something
it's
like
I
want
to
opt
into,
and
then
you
list
the
feature
name
and
so
that
you
know
you
only
turn
on
the
features
that
you
asked
to
opt
into,
and
so,
rather
than
it
being
purely
a
a
symmetrical
accompaniment
to
deprecation,
it's
actually
a
different
behavior,
where
you
actually
supply
the
list
of
opt-ins
that
you
want
to
be
included.
A
Wasn't
that
something
that
graphical
ruby
has
like
these
feature
flags,
I
remember
they
had
something.
E
Like
this
comment
on
that,
michael
martin,
you
also
had
like
the
github
preview
stuff,
one
of
the
reasons
we
did
that
was
to
group
experimental
stuff
together.
As
one
feature
we
used
feature
flags
as
well
from
the
graphql
ruby
implementation,
and
that
worked
well.
That
worked
well.
So
I
definitely
agree
with
lee
there
about
experimental
or
opt-in
on
one
field
might
be
yeah
not
so
optimal,
but
I
also
did
want
to
say
something
weird
about
those
kind
of
mechanisms.
E
Is
there
is
kind
of
a
catch
22,
sometimes
where
you
mark
something
as
hey
be
careful,
we
could
remove
this
at
any
point
and
then
clients
will
be
like
well,
I'm
not
necessarily
interested
in
that
that
feels
dangerous
and
those
who
do
end
up
using
it.
Well,
you
won't
remove
it
later
if
they
start
using
it
heavily.
So
I
will
say
in
practice
and
that's
not
related
to
the
spec.
It's
actually
very
hard
to
manage.
E
F
I
have
seen
a
not
grouped
by
feature,
but
just
like
the
another
angle
on
this
problem
is
to
have
an
internal
only
api.
It's
like
you
need
to
be
in
your
company's
vpn
or
something
to
access
it,
which
all
of
your
local
developers
are,
that
exposes
all
the
experimental
stuff,
which
means
you
can
start
developing
it
against
it,
but
you
couldn't
ship
it
and
that
limits
the
pain
that
you're
talking
about.
Mark
andre,
like
you,
couldn't
end
up
shipping
it
and
then,
depending
on
it,
because
it's
employee
only.
N
And
I'll
add
mark
andre.
The
deprecated
has
that
similar
feel
that,
even
though
it's
marked
as
deprecated
and
it
could
be
removed
at
any
time,
you're
still
have
having
a
difficulty,
because
you
have
to
time
the
removal
with
all
your
users.
I
feel
like
of
all
things.
N
Your
schema
is
about
communication
and
deprecated
does
still
have
value
in
that
way,
because
you're
communicating
that
you
are
working
on
it,
but
experimental
does
that
as
well,
and
I
think
that
there
is
a
wide
variety
of
things
that
you
would
like
to
communicate
about
a
field
or
about
a
type
that
something
that
just
adds
to
introspection
some
text
and
it
could
be
whatever
you
want,
or
you
can
group
them
in
certain
ways.
I
think
that
has
great
value.
L
So,
for
example,
we
decided
to
try
something:
I'm
server
a
guy
and
there
are
a
couple
of
client
guys
and
we
want
to
try
something
new
and
I'm
adding
some
field
and
they
are
trying
at
the
same
time
there
are
other
clients
and
they
suddenly
see
this,
and
we
need
to
give
them
a
hint
hey.
This
is
for
special
stuff,
it's
experimental,
don't
do
this,
and
so
basically
regarding
removing
it
it's
it's,
it
should
not
be
a
problem
or
a
question.
We
want
you.
This
will
be.
This
is
experimental
for
somebody
else.
L
What
I'm
saying
is
that
when
there
are
multiple
teams
using
the
internal
api,
this
is
a
good
way
to
communicate
to
those
who
are
outside
and
say
close
circle
about
this,
that
this
is
something
that
might
not
be
there.
So
this
is
one
thing.
The
second
thing
I
think
the
experimental
message
is
also
good,
because
we
might
identify
there
that
this
is
for
this.
This
team
for
this,
this
don't
use
it.
L
So
the
last
question
is
why
it
should
be
in
the
main
spec-
and
I
think
this
is
a-
can
be
a
perfect
standalone
directive
with
all
this
usefulness,
and
it
will
be
fine,
except
that
it's
not
visible
to
introspection
and
that's
again
we're
coming
to
this
problem
about
that
directive
or
not
all
stuff
is
visible
to
introspection.
That's
why
I
guess
the
main
reason
we're
discussing
it
here
and
I
would
just
say
that
this
is
a
big
problem,
long-standing
problem
and
I'm
about
to
discuss
it
in
my
presentation.
L
So
basically,
if
we
had
this
that
the
directives
the
list
of
directives
is
returned
through
introspection,
then
we
wouldn't
even
need
this
conversation
at
all.
C
Is
an
understatement:
there
is
value
in
standardizing
these
these
directives,
though
right
because
tooling,
such
as
graphical
and
various
other
tooling,
like
that
they
can't
make
use
of
an
experimental
directive
if
they
don't
know
what
that
is,
so,
whether
it's
specified
in
the
graphql
spec
itself
or
whether
there's
like
a
secondary
specification
that
is
shared
across
the
community.
L
F
Yeah,
I
think
the
introspection
piece
is
the
key
one.
Is
there
actually
a
behavioral
change
happening
and
if
the
answer
is
yes,
then
obviously
it
must
come
through
introspection
and
if
so,
then
it's
it
clearly
must
be
standardized,
because
introspection
isn't
something
that
we
are
typically
extending
and
if
it
is
purely
metadata,
then
I'm
I'm
with
roman
that
this
is
pretty
easy
to
just
add
and
there's
a
separate
conversation
about
how
to
expose
metadata
in
a
generalized
way,
which
is
come
up
a
few
times.
But
stephen,
you
got
your
hand
up.
M
Yeah
I
mean,
I
think,
benji
articulated
it
well
as
far
as
the
value
of
having
it
in
the
spec,
but
I
mean
I
think
it
is
just
metadata
in
a
sense,
as
far
as
how
it
gets
transmitted
in
introspection,
it
probably
could
be
fine
to
do
that
in
a
generic
way,
but
also
having
it
standardized
in
the
spec.
M
Just
as
far
as
like
this
is,
you
know
it's
called
experimental
or
opt-in
or
whatever,
and
this
is
what
it
means
you
know
it
does
allow
tools
like
graphical
to
incorporate
some
default
functionality
for
it
and
there
there
is
a
lot
of
value
in
that,
and
so
then
the
trick
is
that
you
know
exactly
how
you
handle.
This
type
of
thing
is
going
to
vary
in
different.
M
Even
we
found
with
within
netflix
we've,
we've
had
a
directive
called
experimental
for
several
years,
and
what's
interesting
is
that
it
is.
You
know
the
subtleties
of
of
how
you
do.
Experimentation
stuff
are
very
different
for,
like
our
enterprise,
apps
and
everything
using
graphql,
and
then
like
our
consumer
apps,
where,
on
the
consumer
side,
we're
doing.
You
know
like
a
lot
of
different,
a
b
tests
in
production.
You
know
that
are
kind
of
a
form
of
experimental
and,
and
so
the
answer
of
like
is
is
this.
M
You
know
you're
allowed
to
use
this
in
production.
It
might
depend
on
on
your
your
company,
and
so
you
know
just
expressing
and
respect,
though
still
that
experimental
implies
a
contract
which
is
different
than
the
normal
contract.
In
that
you
know
this
is
this
is
likely
to
to
change,
whereas
normally
you
introduce
introduce
something
in
graphql
schema
you're.
You
know,
you're,
saying
that
this
is
normally
not
going
to
be
just
arbitrarily
broken
and
then
kind
of
like
deprecated
the
details
of
how
you
do
that
flow,
you
know,
can
can
vary.
F
J
I
I
have
the
questions
yeah
for
sure.
What
are
the
next
steps
there,
like
should,
should
I
proceed
and
try
to
make
appear
on
the
specs?
Is
he
where
the
texas,
or
or
should
I.
F
Yeah,
my
read
is
that
you're
you're
hearing
interest
that
this
is
a
problem.
You
pointed
out
a
handful
of
existing
cases
where
people
are
showing
this
behavior,
but
you
know
we've
heard
from
folks
where
those
have
left
folks
feeling
shortchanged
in
the
past
and
some
of
the
pitfalls.
So
I
think
coming
at
this.
F
Rather
rather
than
coming
at
it
with
like
hey,
we
ought
to
have
an
experimental
directive,
but
like
hey,
here's,
the
problem
and
here's
the
missing
mechanisms
that
we
ought
to
have
and
then
here's
the
additions
to
the
language
that
will
enable
those
mechanisms
and
then
hey
last
time
we
talked
about
this
here-
were
a
handful
of
questions
that
arose
and
here's
the
stab
at
answering
them.
F
Maybe
the
right
next
path
forward,
which,
if
it's
useful
to
do
that
in
terms
of
a
pull
request,
then
fantastic,
but
it
doesn't
necessarily
have
to
be
that
form.
Whatever
is
useful.
L
L
A
L
A
J
And
what
I
am
taking
from
this
discussion
is
that,
whether
it's
going
to
be
an
at
experimental
or
at
opt-in
directive
is
a
big
question.
So
I
can.
I
can
make
a
proposal
for
an
ad
opt-in
and
a
mechanism
to
group
experimental
directives
together
a
group
of
experimental
stuff.
I
don't
know
how
to
say
it,
but
yeah.
I
can
come
back,
come
back
with
something
with
a
couple
of
proposals
to
model
this
metadata,
and
then
you
can
tell
me
what
you
think.
F
Sounds
great
thanks
for
the
presentation
super
interesting?
Okay.
Next
up
on
our
list,
ben
clarification
for
root
operation
types,
yeah,.
I
So
hopefully
this
will
be
quick.
The
the
basic
problem
here
is
that
if
you
have
a
schema
and
it
doesn't
define
mutation
or
it
doesn't
define
subscription
the
spec
and
common
sense
say
you
know,
that
means
the
schema,
doesn't
support
mutations
or
subscriptions,
but
there's
not
actually
a
validation
rule
to
check
that
and
a
lot
of
a
lot
of
graphql
libraries
surprisingly,
will
validate
any
such
query.
Even
if
the
fields
are
like
totally
bogus
and
and
certainly
they
should,
they
should
reject
it.
I
So
this
is
a
pr
to
add
some
explicit
validation
language,
it's
number
955
in
the
in
the
spec
repo
and
it
just
it's
just
the
explicit
language
that,
like
if
you're,
if
you
have
a
query,
its
root
operation
type,
has
to
exist.
There
are
a
couple
of
of
details.
We
can.
I
don't
know
how
how
deep
we
want
to
get
into
these
exact
bikes
by
chatting
the
exact
language.
But
that's
that's
the
idea.
F
F
I
I
I
did
not
include
that
for
two
reasons.
One
is
because
the
schema
side
is
a
little
less
consistent
in
where
it
includes
validation,
rules
in
the
first
place,
and
two
is
I
I
don't
know
if
that's
likely
to
I.
I
would
think
that
real
schemas
are
going
to
have
a
query
type,
but
I
don't
know
how
many
you
know
when
I
tried
in
in
one
of
the
libraries
I
was
making
a
pull
request
for
when
I
tried
introducing
that
it.
You
know
it
broke
a
bunch
of
tests.
I
was
kind
of
like.
I
Is
this
really?
Is
this
really
even
worth
it?
So
that's
something
to
think
about
is
whether
to
make
that
explicit
as
well.
I
But
of
course,
if
you
validate
the,
if
you
validate
on
the
query
side,
then
at
least
you
know
you're
not
getting
a
query
or
on
the
operation
side,
you
at
least
know
you're,
not
getting
a
query.
If
the
schema
doesn't
support
it.
Yeah.
A
But
but
there
actually
is
a
there's:
a
graphical
schema
must
itself
be
internally
valid.
This
section
describes
the
rules
for
the
validation
process
and
then
down
there.
We
will
describe
that
type
names
have
to
be
unique
and
stuff
like
that,
and
you
have
a
have
to
have
a
schema
typo,
so
I
that's
at
least
how
we
implemented
it.
Also,
oh.
A
I
D
F
Yeah,
I
think
we
do
validate
that
a
query
type
exists
but
you're
pointing
out
an
important
gap
which
is
not
about
query
validation,
but
about
schema
validation
or
sorry,
not
about
schema
values,
but
query
validation.
That
if
you
write
a
query,
then,
if
it's
mutation
or
subscription,
then
such
a
type
must
exist
in
the
first
place,
I'm
kind
of
surprised
that
something
else
doesn't
catch
that
but
okay.
O
I
think
there's
also
the
the
point
you
were
making
about
even
query
like
it
might
be
reasonable
to
have.
The
validation
include
like
if
your
schema
does
not
have
a
query
type
it
also
at
execution.
Time
is
invalid,
even
if
that
should
be
an
impossible
state
to
be
in
because,
like
there's
a
difference
between
execution
level,
validation
and
schema
level
validation
and
like
once,
you
join
the
two.
Then
it's
impossible
to
be
in
that
state.
But
there's
an
intermediate
state
where
that's
possible.
I
Yeah
and
the
way
it's
written,
it
would
actually
cover
that
if
you
somehow
have
a
schema
without
a
query
type.
I
Only
reason,
I
even
believe
that
this
that
I
wasn't
just
missing
this-
is
that
a
bunch
of
different
libraries
also
miss
it
and
a
lot
of
them
just
really
copy
the
validation
logic
pretty
directly,
including
graphql
js,
which
there's
also
a
pr
for.
F
Nice
work,
okay,
so
I
I
marked
the
pull
request
on
the
spec
as
rc1,
which
means
we
agree
that
this
is
a
reasonable
problem
to
solve
and
we've
got
early
text.
Rc2,
I
think,
is
making
sure
that
the
implementation
is
the
right
one
and
getting
that
fully
reviewed
and
landed
I'll.
Do
a
read
through
of
the
spectex
that
you've
gave
to
so.
Hopefully,
we
will
be
able
to
advance
this
one
relatively
quickly,
thanks
for
catching
this
and
digging
into
it.
Great
thanks
all
right.
P
One
is
the
this
one
that
I
just
linked
is
discussing
how
we,
what
we
call
the
syntax
that's
being
introduced,
and
this
one
is
discussing
the
name
of
the
proposal
itself.
I'm
I'm
speaking
at
the
at
the
upcoming
conference,
and
I
got
to
call
this
proposal
something
so
I'm
I'm
just
gonna
close
the
polls
24
hours
from
now
and
and
call
it
whatever
gets
selected
yeah.
I
don't
know
we're
we're
kind
of
running
out
of
time
here.
P
So
have
a
have
a
read
through
those-
and
you
know
take
your
time
just
in
24
hours
at
noon
tomorrow,
I'll
close
it
and
then
the
other
thing
is.
I
saw
that
graphql
17
was
opened
up.
Should
I
be
targeting
that
instead
of
16
or
should
I
keep
targeting
16.
K
So
so
we
decided
to
to
start
version
17,
and
we
decided
that
most
of
the
time
we
don't
do
bug
fixes
most
of
the
time
we
either
like
at
stuff
or
like
at
additional
things,
experimental
things
so
what's
what's,
my
idea
now
is
to
have
have
like
forward
version
in
like
development
version,
stable
version
and
idea
to
blackboard,
so
first
add
into
version
17
allow
people
to
try
it
up
if
you
or
somebody
else
need
it
in
version
16,
we
can
backport
that
and
right
now,
code
base
is
very
similar.
K
K
P
Got
you
yelp's,
probably
gonna,
want
it
on
16.,
so
I'll
see
about
backporting
it.
The
other
update
is
that
we're
pretty
close
to
merging
merging,
lexing
and
parsing.
Sorry,
a
bunch
of
noise
outside
pretty
close
to
merging
lexington
parsing.
We
just
need
to
solidify
syntax
names,
so
that'll
that'll
happen
shortly
after
we
close
the
polls.
P
For
the
the
js
implementation.
D
P
Yeah,
I
think
that
was
everything.
That's
that
I've
been
working
on.
D
F
P
Yep
yeah
yeah
vote
read
stuff
talk
back
and
forth
and
then
the
other
action
item
I
had
was
to
open
up
a
feedback
thread
for
the
alpha
and
I'll.
Do
that
once
we
have
like
an
alpha
of
the
server
up.
F
F
Let's
use
the
reactions
tool
thumbs
up
for
take
a
break
party
party
popper
for
power
through.
F
All
right,
it's
equally
split
nope
the
thumbs
ups.
Have
it
we're
taking
a
break
I'll,
kill
my
video
and
mute
and
we'll
come
back
here
in
four
minutes.
So
two
minutes
past
the
hour.
F
C
C
One
is
that
ivan
did
a
thorough
review
of
the
graphql
js
implementation
and
in
doing
so
made
the
recommendation
that
we
change
the
introspection
field
from
one
of
to
is
one
of
in
order
to
match
the
is
deprecated
that
we
already
have
for
that,
so
that
small
naming
has
changed
that
another
thing
that
we
changed
is
that
you
can
no
longer
apply
the
one-off
directive
to
an
input,
object,
extension
and
the
reason
for
that
is
because,
when
you
validate
an
input
in
the
graphql
spec,
it
says
here's
what
happens
when
you
define
an
input
and
here's
what
makes
it
valid
and
then,
when
you
have
an
extend
input,
it
has
its
own
rules.
C
Those
rules
do
not
retroactively,
apply
to
the
previously
defined
fields.
So,
rather
than
introducing
something
that
says,
and
now
all
of
the
previous
fields
that
are
already,
there
cannot
be
non-null
and
you
know
so
on
and
so
forth.
It
was
easier
just
to
forbid
it.
So
the
only
place
that
you
can
add
the
one
off
is
on
the
input
type
itself
and
not
on
any
input.
Object.
Extensions
thanks
to
lauren
for
just
for
spotting
that
one.
C
The
other
question
revolves
around
the
idea
that
there
are
people
in
the
ecosystem
already
that
are
using
at
one
of
because
you
know
it's
been
around
for
a
little
while
now
over
a
year,
I
think-
and
so
we
have
said
before.
I
believe
that
we
can
introduce
new
directives
and
we
actually
put
a
note
into
the
graphql
spec
recommending
that
people
use
prefixes.
C
C
C
A
C
D
A
C
C
So
from
a
graphql
js
point
of
view,
like
question,
is:
if
we
suddenly
introduce
this
directive
like
it,
may
well
break
people's
schemas
where
they
are
defining
a
directive
themselves.
That
is
called
one
of,
and
this
isn't
just
specific
to
one
operate.
This
is
any
directive
that
we
add
to
graphql.
F
F
Saying
so
the
we
we
certainly
in
the
spec,
recommend
that
people
choose
names
that
are
unlikely
to
be
clobbered
by
spec
change.
This
one
is
also
highly
likely
to
be
clobbered,
because,
probably
the
reason
people
are
using
it
is
because
they've
been
keying
into
the
discussions.
We've
been
having
around
adding
it,
so
I
don't
feel
a
ton
of
remorse
by
stomping
on
people.
Who've
made
that
particular
decision,
but
there
are
real
ramifications
here
whether
it
needs
to
be
a
major
version
or
not.
F
I
don't
know,
maybe
we
can
if
we
know
from
a
practical
point
of
view
who
that
set
of
users
are
if
this
is
like
a
a
abstract
like
we
know
that
they
they
could
exist
or
if
there's
like.
Truly
a
list
like
here
are
the
exact
people
we're
about
to
go
break
then
we
ought
to
be
able
to
have
a
conversation
about
it.
Otherwise
I
think
it's
reasonable
to
say
you
know.
Maybe
we
want
to
get
this
in
in
alignment
with
one
of
the
next
major
version
bumps.
F
C
Other
than
that,
I
think
that
the
proposal
is
is
basically
good
to
go
so
I'd,
be
I'd,
be
happy
elevating
it
to
rfc3.
Now
I
think
I
don't
think
there's
any.
K
C
Thanks
so
in
order
to
experiment
with
what
one
off
would
look
like
in
output
to
see,
if
that
would
have
any
effect
on
input,
I
have
also
raised
the
one
of
objects
rfc
to
be
clear.
This
is
marked
as
a
draft
because
it
is
not
like
final
spec
edits
or
anything
like
that.
I'm
not
even
proposing
that
we
move
this
to
rfc
one
or
anything
like
that.
C
So
it's
it's
this
question
of.
Do
we
require
that
one
field
is
non-null
or
do
we
require
that
one
field
is
present
and
all
the
other
fields
are
not
present.
So
in
a
one
of
output
objects,
the
fact
of
removing
fields
that
you've
specified
is
quite
a
significant
divergence
from
the
status
quo.
It
has
precedent
in
things
like
the
skip
and
include
directives,
but
those
are
chosen
by
the
user
rather
than
chosen
by
the
the
server
effectively.
C
The
directive
does
say
that
this
thing
is
going
to
happen,
so
it's
kind
of
okay,
but
it's
also
less
okay.
So
the
main
question
around
that
is,
if
we
were
to
decide,
for
example,
that
it
was
okay
or
that
we
should
keep
those
fields
in
then.
Does
that
mean
that
for
input
objects,
we
should
also
allow
those
fields
to
be
present,
but
null.
C
I
think
that
we're
good
to
continue
the
way
that
we've
currently
proposed,
which
is
that
all
other
fields
are
forbidden,
because
we
can
allow
that
to
change
in
future,
but
we
can't
go
the
other
way,
so
we
can
allow
additional
nulls
to
be
added
in
future
if
we
want
to
change
that
behavior
from
what
is
currently
proposed,
but
I
don't
think
we
can
go
the
other
way,
but
I
may
be
mistaken.
So
if
anyone,
if
anyone
thinks
I'm
mistaken
on
that
speak
up.
F
I
mean
honestly
the
for
the
input.
One
of
the
one
remaining
thing
that
I
still
feel
some
nervousness
around
is
how
we
are
treating
nullability,
that
the
fields
themselves
do
not
express
that
they
are
non-null.
F
However,
the
addition
of
this
directive,
all
of
a
sudden,
requires
them
to
not
allow
null,
is
a
little
confusing
and
excludes
potential
space
where
you
actually
want
to
say
like
yes,
I
intend
for
this
to
be
this
branch
of
the
one
of,
and
the
appropriate
value,
for
it
is
null
it's
like
cannot
be,
cannot
be
represented
in
our
current
one
of
because
of
the
way
that
we're
treating
null
and
so
like.
If
this
is
causing
us
to
gut
check
that
decision,
I
think
that's
a
reasonable
thing
for
us
to
take
seriously.
G
A
L
For
separate
arguments,
we
have
explicitly
state
that
it's
a
different
situation
now
or
absence
for
arguments
with
defaults,
so
we
do
distinguish
when
the
json
has
the
value
and
it's
now
or
the
the
value
is
missing.
At
least
that's
standalone
arguments.
D
A
That's
why
I
mentioned
we
are
in
the
validation.
We
are
explicitly
looking
if
something
is
stated
now
or
not.
So
that
means
we
could
also
use
another
as
a
value.
L
C
We
could
do
that,
but
that
is
currently
in
violation
of
the
one-off,
because
the
one
of
explicitly
says
that
there
will
be
one
field
specified
and
that
field
will
not
be
null.
We
do
not
have
the
concept
of
there
being
a
cat
that
is
null.
We
have
a
concept
of
this
is
a
value
either
the
value
itself
is
null
or
the
value
is
a
cat
or
it
is
a
dog
or
it
is
a
fish.
It
is
not
a
null
cat.
C
That
is
something
that
we've
explicitly
disallowed,
because
this
isn't
one
of
isn't
intended
for
setting
like
individual
keys
in
an
object.
It
is
designed
to
represent
a
polymorphic
type,
so
it
is
either
a
cat
or
a
dog
and
having
a
null
cat
doesn't
really
make
sense.
It's
just
a
null
thing.
It's
just.
The
entire
thing
is
null.
F
Yeah
I
mean
it's
a.
I
think
this
is
like
a
a
typical
confusion
of
the
way
that
we
have
expressed
null
ability
in
the
first
place
by
making
nullable
the
default
and
the
concept
of
a
tagged
union
like
it's.
It's
it's
not
completely
uncommon
to
see.
You
know
you
could
imagine
a
it's
a
maybe
cat
or
a
maybe
dog
are
your
two
branches
in
your
union.
F
Where
you
know
either
you
are
a
cat
person
who
doesn't
have
a
cat
right
now
or
you're,
a
dog
person
who
doesn't
have
a
dog
right
now,
I'm
coming
up
with
a
weird
example
that
matches
your
your
example
here.
But
that's
what
I
mean
like
there
may
be
potential.
F
There
may
be
potential
data
modeling
that
we
are
excluding
and
just
we
should
just
got
checked
that
that
makes
sense.
I
think
actually,
the
exclusion
of
data
is
one
piece
and
then
also
like
is
this.
F
A
Yeah
there
was
like
I
did
a
little
short
video
on
youtube
for
that
feature
in
hot
chocolate,
and
that
was
the
first
question.
Actually,
why
can
I
not
send
said
no
like
use
a
kind
of
like
yeah
you
have
to
you
have
to
provide
one
value,
but
this
value
could
also
be
none
like
it's
more
about
user
decision
like
you
set
something
and
you
have
to
at
lea.
You
have
to
set
something,
but
I
also
can
see
that
the
problem
there
is.
A
How
do
you
force
somebody
then
to
to
set
something
like
how
do
you
exclude
null
when
the
field
is
nullable,
and
we
would
allow
null
right
that
that
is
essentially
the
problem
like
if
we
were
to
allow
null?
How
do
we
give
the
user
the
tool
to
say
I
don't
want
it.
That
would
be.
A
L
From
the
point
of
view
of
the
server
you
know,
there
is
a
principle
that
accept
be
generous
on
what
you
accept
and
be
strict
on
what
you
return.
So
here
from
the
server
point
of
view,
I'm
receiving
this
request
and
it's
kind
of
not
clear
something
is
now
you
know
the
only
value
is
now,
and
so
the
best
strategy
for
me
is
not
to
scream
about
not
to
throw
error,
but
let
the
resolver
for
specific
service
figure
it
out.
L
A
F
I
remember
why
we
why
we
did
that
it's
because
us
imagine
a
old
client
but
a
new
server,
so
your
new
server
is
now
aware
of
one
of
and
is
starting
to
take
advantage
of
this
type,
but
you
have
an
old
client,
so
maybe
you're
using
an
old
version
of
apollo,
client
or
relay
or
whatever.
That's
not
not
yet
aware
of
the
one
of
type
and
the
constraints
that
it
applies.
F
F
The
client
that
wasn't
aware
of
this,
yet
would
say:
hey
hey,
you
can't
only
supply
one,
because
all
three
are
required
because
it
wasn't
like
the
addition
of
this
one
of
is
new
concept.
So,
basically
it's
a
backwards
compatibility
thing.
We
just
we
ought
to
assume
that
there's
for
a
significant
amount
of
time.
Gonna
be
this
overlap,
and
this
is
a
easing
of
the
overlap
problem
where
clients
can
completely
ignore
the
fact
that
this
one
exists
for
their
local
validation.
F
There
are
already
servers
that
are
expressing
these
one
of
and
they're
just
doing
under
the
hood
validation
of
your
input,
and
this
is
now
codifying
it
in
the
language
and
therefore
giving
us
the
power
tools
of
graphql
level
validation.
C
That
was,
that
was
absolutely
one
of
the
motivations
behind
that
choice
is
the
one
that
I've
documented,
but
the
other
thing
is,
you
know:
you're
not
going
to
win
either
way.
If
you
make
the
fields
all
nullable,
then
it's
confusing
that
one
of
them
is
required.
M
Yeah
and
there's
definitely
trade-offs
with
you,
know
kind
of
conflating
the
the
absence
with
no
ability
of
things,
but
it
seems
like
that's
a
trade-off.
We've
already
decided
to
make
with
graphql
to
keep
things
a
little
bit
simpler,
and
if,
for
this
we
wanted
to
say
that
that
you
do
have
to
make
a
distinction
between
whether
this
field
is
present
and
whether
the
value
is
null
that
could
have
implications
beyond
being
confusing.
M
Even
for
you
know,
maybe
alternative
types
of
serialization,
where
you
make
an
optimization
to
like
drop
things
that
are
null
and
like
you
can
you
know
get
away
with
that,
since
we're
saying
null
and
presence
or
the
options
are
the
same,
and
this
would
be
changing
that,
if,
if
we
didn't
do
it
the
way
that
g
has
it
here,.
F
Okay,
I
don't
know,
we've
fully
resolved
this,
but
we
are
running
close
to
your
your
time.
I
think
it
has
been
helpful
to
open
the
one
of
objects
and
express
these
pieces
that
feel
maybe
not
in
alignment.
Yet
one
thought
that
we
ought
to
explore
is
not
necessarily
saying
like
hey
if
you,
if
you
really
want
these
to
be
not
noble,
you
have
to
explicitly
mark
them
as
such,
but
just
kind
of
sidestepping
this
whole
thing.
F
Maybe
this
aligns
well
with
roman
suggestion
of
rather
than
this
being
a
new
input,
validation
that
will
reject
null
values.
To
say
like
if
your
type
resolver
under
the
hood
encounters
the
null
it
ought
to
reject
it
and
which
basically
preserves
some
future
point
where
you
could
in
fact
mark
them
all
as
explicitly
normal.
But
I
don't
know
to
your
point
that
may
be
confusing,
but
we
ought
to
give
it
a
a
fair
shake.
C
And
just
before
we
move
on,
there
is
also
one
complete
alternative
that
we
can
do
to
this,
and
I'm
not
suggesting
that
we
change
very
much
of
the
spec
text
itself
that
is
proposed.
But
instead
of
using
a
directive
to
represent
this,
we
could
just
use
an
alternative
syntax.
C
So
in
the
introspection
it
would
look
exactly
the
same
as
it
does
currently
and
for
clients
that
don't
understand.
One
of
it
would
look
like
an
input
object
with
all
nullable
fields,
but
in
sdl
we
could
represent
it
more
like
a
union
or
more
like
a
a
list
of
object
types
with
a
defined
field,
and
maybe
that
would
work
around
our
discomfort
of
this.
But
I'm
not
sure
whether
that
does
address
your
concerns
or
not.
F
I
don't
know,
I
don't
know
if
it
addresses
it,
it
reshapes
it,
but
then
you
get
into
the
slightly
separate
problem
of
having
the
a
new
thing
to
parse
and
that
being
sort
of
a
higher
burden
for
tools
which
would
encounter
this
and
not
know
how
to
deal
with
it.
C
I
mean
I
mean
the
fact
that
one-off
isn't
a
directive
right.
What
is
one
of
is
just
a
field.
It's
a
boolean
field
in
introspection.
How
that's
represented
in
the
in
the
schema
in
the
stl
sorry
is
up
to
us.
We've
at
the
moment
proposed
that
we
represent
this
with
a
directive
because
it's
the
least
work.
C
We
can
already
use
the
schema
passing
the
the
passing
of
directives
to
indicate
that
yeah.
But
really,
we
can
just
say
it's
an
input,
object
type
that
is
a
one-off.
It's
a
one-off
input,
object,
type
and
the
syntax,
for
that
could
be
one
of
input
and
then
something
else,
some
other
syntax,
the
fact
yeah,
it's
not
a
directive.
It
just
is
using
directives
right
now.
L
No,
I
think
syntax
change
should
be
the
last
resort.
The
first
choice
should
always
be
directive,
and
then,
if
it
cannot
be
in
any
way
implemented
as
a
directive,
then
we
go
for
syntax
change.
L
L
C
Let's,
let's
move
on
from
this
discussion
to
the
next
one.
F
Yep
yeah,
I
think
you've
got
the
right
next
steps:
benji,
okay,
next
up
yakov4
is
yours.
Talk
about
unions
and
interfaces.
G
Hey,
okay,
so
we're
moving
from
something.
That's
probably
much
more
gonna
be
much
more
useful
to
something
a
little
bit
or
very
esoteric,
but
we
we're
making
some
advancements
toward
being
able
to
to
express
that
a
union
implements
an
interface
so
that
if
a
union
is
a
field
on
an
object,
then
that
object
can
implement
an
interface
we.
I
basically
went
through
from
the
last
meeting.
G
I
went
through
and
tried
to
make
sure
as
best
as
I
could
that
the
tests
were
up
to
date
and
then
we
we
talked
about
how
we
want
to
see
with
the
impact
on
introspection
so
and
we
decided.
We
decided.
Definitely
that,
because
the
union
implements
the
interface,
you
should
be
able
to
query
fields
directly
on
the
union
that
you
know
the
because
it
you
know
it
should
honor
that
contract.
So
we
did
a
benji
raised
interesting
point.
G
I
had
assumed
when
we
were
talking
about
last
meeting
the
effects
on
introspection,
and
that
would
mean
that
if
you
introspected
a
union
that
implements
an
interface
and
you
ask
for
fields
the
field's
key
on
introspection,
it
should
now
give
you
the
fields
that
that
that
are
that
are
valid
to
query
directly
on
the
interface
and
I
ran
into
some
trouble
in
in
actually
trying
to
implement
that.
Then
benji
wowed
me
by
saying:
maybe
that's
not
what
we
meant
at
all.
So
I
guess
that's
the
question.
G
The
immediate
question
for
the
working
group
is:
do
we
want
do
we
want
introspection
to
return
fields
for
this
union,
so
a
union
that
implements
an
interface
is
basically
like,
like
an
interface
that
just
that
specifies
no
additional
new
fields
but
adds
a
constraint
limiting
that
interface
to
only
a
few
types.
So
the
question
is,
you
know,
do
we
want
introspection
to
you
know?
G
Benji's
point
was
basically
the
union
doesn't
add
any
new
fields,
and
so
it
doesn't
define
any
in
the
sdl
there's
a
car
and
so
the
introspection
shouldn't
either.
I
don't
know
if
anyone
has
any
strong
feelings
on
the
matter.
F
It's
interesting,
it
is
a.
It
would
be
the
first
place
where
those
things
become
decoupled,
where
currently
anything
that
says
it
implements.
A
particular
interface
is
actually
required
to
specify
the
fields
that
it
implements
because
they
may
be
equivalent,
but
they
may
actually
have
subtype
and
so,
rather
than
having
to
crawl
the
chain
and
figure
it
out,
they're,
just
all
there.
You
know
you
can
just
ask
for
all
the
fields
for
that
particular
type
where
you're
at.
D
G
So
and
another
wrinkle
just
to
think
about,
is
that
if
we
say
that
it,
you
know
if
we
say
that
we
do
have
to
return
those
fields,
it's
not
actually
clear
a
hundred
percent
clear
when
you're
writing
the
schema.
So
this
is
I'm,
hopefully
I'm
sharing
a
screen
and
I'm
showing
a
whole
bunch
of
types
and
interfaces.
I
just
want
to
point
your
just
run
through
it.
Basically,
the
name
should
be
pretty
explanatory.
You
have
one
interface
on
top.
You
have
another
interface,
then
now
it
can
get.
G
You
have
a
common
interface
that
implements
both
of
those
and
then
you
have
a
few
types
that
you
know
that
implement
that
common
interface.
Okay,
so
we
have
like
a
hierarchy
of
of
of
types
and
then
we
have
our
union,
that's
implementing
the
oh.
You
know
that
common
interface
and
therefore
it
also
includes
those
other
interfaces
and
it's
restricted
to
those
types.
So
that's
basically
the
scenario
that
we're
that
we're
that
we're
talking
about.
So
what
is
the
shape?
G
I
mean
if,
if
that
union
has
fields,
the
shape
is
obviously
going
to
be
defined
by
these
interfaces.
But
it's
not
100
percent.
Clear
like
we
know,
because
we
have
this
example-
that
the
common
interface
basically
includes
everything
else
and
that's
going
to
be
like
the
key
type.
That's
actually
the
shape
that
we
want
and
that
we
would
want
to
return
with
introspection.
G
But
just
looking
at
that
one
line,
it's
not
directly,
you
know,
you
know,
require
some
some
algorithm
and
maybe
some
proving
like
I
actually
ran
into
a
whole
bunch
of
confusion
on
on
my
part,
so
the
implementation
might
be
a
little
challenging
and
that's
not
necessarily
a
reason
to
you
know
avoid
it,
because,
first
of
all,
you
know
we
should
embrace
challenges,
but
also
because
we're
going
to
have
to
sort
of
figure
out
how
to
validate
it
unless
we
just
yeah.
So
so
that's
another
wrinkle.
G
So
you
know
it's
just
it's
food
for
thought.
This
is
like
not.
We
have
a
definitely
a
lot
of
items.
You
know
on
the
agenda
today,
so
I
basically
wanted
to
raise
that.
As
sort
of
you
know
the
update,
you
know
where
I
am
with
this
pr
and
we
sort
of
stalled
out
over
here.
You
know,
I
think
it's
an
interesting
question
where
there's
not
a
burning
desire
in
the
community
for
this
feature
and
I'm
sort
of
feeling
to
myself
that
it
may
raise.
G
You
know
some
interesting
problems,
but
not
necessarily
problems
that
we
want
to
solve
right
now.
That's
basically
where,
personally,
I
am
with
this.
If
anyone
has
any
strong
opinions,
they
can
definitely
weigh
in
though
or
any
opinions
at
all
or
on
the
issues.
You
know
that
you
know
that
are
obviously
going
to
stay
open,
but
this
is
not
burning
questions,
but
I
figured
I'd,
bring
an
update
back
to
the
working
group.
F
G
And
that
also
quickly
covers
basically
the
next
issue
I
mean,
unless
anyone
wants
to
spend
more
time
on
this
one.
I
know
we
got
a
packed
agenda.
G
Let
me
just
quickly,
I
think
I
can.
I
think
this
one
is
on
the
spec
itself,
so
I'm
going
to
just
pull
up
that
pr
bear
with
me,
but
basically
the
idea
here
was
what
was
the
idea?
Why
do
we
want
a
union
to
implement
an
interface
like
explicit?
You
know,
with
with
additional
text,
we
basically
wanted
to
allow
you
to
define
an
object
type
that
has
a
union
field
and
then
say
it
can
implement
a
an
interface
where
the
interface
had
a
interface
type
for
that
field.
G
So
that's
the
same
thing.
Basically
we're
trying
to
unlock
things
like
like
this
over
here,
where
you
have.
You
know
two
potential
types
that
want
to
interface
and
inter
they
want
to
implement
an
interface,
but
currently
they
can't
because
the
the
type
of
that
interface
is
a
union
and
right
now
you
can't
do
the
only
types
that
right
now
you
can
include
within
that
union
are
object
types.
So
in
this
schema
it's
types
like
cow
and
wolf,
but
not
an
interface
or
not
these
other
union
types.
G
So
right
now
you
can't
do
the
here,
I've
labeled!
These
are
unlocked
by
this
pr.
You
can't
do
you
can't
do
this,
and
so
it's
not
valid,
so
you
can't
really
have
like
a
full
complex
type
hierarchy
right
and
we
know
that
graphql
type
system
is
not
you.
N
G
Favor
simplicity,
over
completeness,
for
the
reasons
we're
just
saying
so
so
again,
sorry,
I
basically
sketched
here
one
option
for
how
you
might
you
know
allow
this.
I
happen
to
think
that
unions
of
interfaces,
as
opposed
to
unions
of
unions,
is
the
most
you
know
has
the
most
value
add
because
I
think
we
often
run
into
trouble
in
adding
new
types
to
unions.
But
if
that
type
implements
an
interface,
then
I
think
that
might
actually
help
us
out
a
lot.
G
So
that's,
basically
you
know
the
same.
This
was
similar
to
the
idea
before,
but
in
terms
of
like
overall
value
to
the
ecosystem.
I
think
this
change
basically
includes
two
changes.
I'm
letting
you
say
you
include
unions
in
here
and
also
interfaces,
including
unions.
As
a
look,
it
gets
a
little
ug
you
know,
might
get
a
little
ugly.
G
You
know
has
to
include
only
members
of
some
larger
union,
and
so
then
you
would
have
the
the
the
child
union-
I
guess
not
be
specified
within
within
this
parent,
but
actually
be
be.
You
know,
be
specified
else
right
on
the
on
the
other
union
and
make
this
definition
simpler.
But
basically
this
is
just
a
sketch
of
how
we
might
you
know
again
complete
the
type
system.
G
Allow
you
to
express
a
few
additional
things,
but
I
would
point
out
that,
as
far
as
I
can
tell
the
easiest,
this
is
easier
than
the
other
change.
You
know
it
doesn't
or
it
doesn't.
You
know,
require
new.
You
know
that
those
complexities
that
we're
talking
about
for
in
terms
of
changes
to
introspection-
and
it
also
may
add
a
lot
of
value
not
for
unions
of
unions,
but
for
unions
of
interfaces.
So
I
just
wanted
to
get
a
that
might
be
something
that
I
might.
F
This
one
actually
also
has
introspection
implications.
There
may
be
non-obvious,
but
we,
when
you
introspect
a
union
and
you
ask
for
its
possible
types
right
now.
We
make
a
guarantee
that
that
list
of
possible
types
are
all
objects
which
right.
So
you
could
imagine
you
know
unfolding
these
and
basically
crawling
the
hierarchy
of
what's
in
the
unions
of
unions
of
unions
and
get
that
list
of
object,
types
yeah,
but
it's
also
the
list
of
things
that
we
would
then
show
in
the
syntax
with
bars
between
them.
F
G
When
I
worked
on
the
intersection,
the
failed
intersection
type,
I
basically
put
forward
a
solution.
I
think
it's
fairly
straightforward.
Basically,
you'd
have
to
introduce
a
new
inspection
field
where
it
was,
you
know,
one
would
be
possible
types
which
would
be
those
crawled
object,
types
and
another
one
would
be.
You
know
I
called
it
member
types
which
would
be.
You
know
how
you
defined
it
here
and
it
would
be
just
them
once
mentioned.
I
mean
that
was
my
solution,
but
at
least
I
know
the
solution.
F
You
know
is
slightly
more
constrained.
It
reduces
a
whole
surface
area
of
complexity.
By
saying,
there's
not
two
things
you
never
have
to
crawl.
You
never
have
to
val,
like
you
can
imagine
a
schema
just
being
wrong
by
its
member
types,
and
it's
allowed
types
just
like
don't
agree
for
some
bizarre
bug
or
reason.
It's
like
that.
Whole
class
of
issue
is
just
gone,
and
so
I
don't
know
it
makes
me
nervous.
G
Well,
how
about
you
know?
I
really
do
think
you
know
this
will
make
unions
easier
for
the
community,
so
I
mean
that's
basically
my
update.
Basically,
I
was
going
to
say
that
I
would
for
the
next
time
I
might
try
to
work
on
this
implementation,
not
of
both
things
not
of
just
the
union's
images
but
just
of
unions
of
interfaces,
and
I
guess
see
where
that
takes
us
and
if
you
know
we're
still,
you
know
uneasy
about
it.
You
know
you
know
I
I
I've
been
able
to
see
from
there.
C
Yeah
echo:
is
there
a
particular
reason
that
this
couldn't
be
done
with
just
build
tooling,
for
example,
like
do
you
want
this
union
that
you
have
here
with
interfaces
and
some
types
to
be
visible
in
a
tool
like
graphical,
or
is
it
just
effectively
a
shorthand
for
listing
out
all
of
the
possible
subtypes.
G
I
think
oh
so
that
is
a
good
point.
Actually
that's
a
very
good
point,
because
you
can
actually
a
query
that
a
query
that
has
you
know
shares
any
possible
types.
I
mean
a
fragment
that
shares
any
possible
types
with
the
base
can
always
be
used
even
without
this
new
syntax.
So
it
would.
This
would
help
you
with
the
type
of
hierarchy,
but
not
necessarily
with
not
necessarily
with
the
queries
themselves.
I
mean
the
queries
should
be
valid
already
as
long
as
any
new
union.
G
So
that's
a
good
point,
so
it
may
not
be,
as
you
know,
in
demand,
as
I
think
it
is,
but
you
know
I
think,
because
it
can
already
be
used.
It.
D
G
Make
you
know
it
might
make
more
sense
to
make
the
titan
more
robust
in
this
one
sense
as
well.
But
again
you
know
the
demand.
F
Yeah,
it
does
seem,
it's
not
just
a
build
time
thing
like
there's
real,
like
the
sort
of
like
diamond
dependencies
of
fields
that
have
implement
interfaces
which,
like
there's
wanting
to
use
unions
to
satisfy
them,
but
there's
like
a
constraint
solved
to
the
type
system.
That's
not
expressible
today
that,
like
you're,
looking
for
a
way
to
express
something
that
would
previously
be
marked
as
not
valid
is,
is
actually
valid,
but
only
if
you
can
kind
of
clarify
that
such
a
constraint
is
being
met.
E
F
Yeah,
I
feel
like
I'm
not
I'm
nervous
about
this.
I
like
your
constraints,
implementing
interfaces
one
one
better,
but
I
appreciate
that.
There's
complexity
under
the
hood
in
each.
G
Yeah,
I
don't
know,
there's
something
on
here.
I
I
think
it's
good
to
like
you
know
we
had
some
questions
in
the
spec
repo.
You
know
why
isn't
this
possible?
So
I'm
just
glad
to
you
know,
put
a
little
color
on
it
and
see
that
could
be
possible.
Here
are
some
things
we
ran
into
and
consider
so
I
might
push
forward.
I
hit
a
roadblock
in
the
other
one,
so
lazy
me.
I
might
move
forward
a
little
bit
more
in
this
one
and
see
where
it
takes
him.
F
Awesome,
thank
you
for
digging
into
it
non-trivial
space,
so
fantastic
exploration,
all
right,
roman
next
agenda
topic
is
yours.
Spec
issues.
L
Okay,
everyone.
So
it's
a
two-part
presentation-
and
I
hope
I
have
enough
time,
but
the
first
part
is
small
things
and
it's
discussion,
link
969
and
I
posted
it
more
than
a
week
ago.
Don't
see
any
feedback
or
any
opinions
or
nothing.
Yes,
so
basically
it
is
small
things,
it's
not
about
how
graphql
works.
It's
how
we
explain
it
and
the
specification
read
one
line
by
line
and
finding
things
like
typos,
some
strange
sentences,
some
repetitions
and
so
on.
L
So
you
might
think
it's
not
that
important
at
all,
but
I
was
suggested
to
take
it
a
little
more
seriously
because
when
you
read
a
book-
and
there
is
such
thing
in
publishing
houses
in
magazines
in
serious
organizations
as
editor
book
editor,
so
his
job
or
her
job
is
to
read.
It
read
the
publication
line
by
line
word
by
word
and
verify
everything,
spelling
grammar
references,
internal
reference,
external
reference,
so
one
so
when
they
did
end
a
good
job,
you
don't
notice
it,
but
sometimes
with
this
self-publishing.
L
F
Have
we
have
a
github
tag
for
this?
You
should
file
these
as
pull
requests.
We
have
a
github
tag
called
editorial
which
any
change
that
doesn't
change
the
behavior
of
the
spec
we
tend
to
handle
asynchronously.
We
do
them
quickly,
but
I
think,
probably
a
better
process
rather
than
listing
them
all
in
one
discussion
thread,
because
it's
difficult
to
sort
of
weigh
in
on
each
of
them
and
have
one
linear
conversation
split
them
up
make
each
one.
F
If
you
have
a
specific
like
for
a
typo,
for
example,
just
send
that
as
a
pull
request,
it
should
probably
get
merged
relatively
quickly
for
something
that's
a
little
bit
more
in-depth.
You
can
at
least
make
a
proposal.
If
it's
straightforward
and
it
doesn't
change
behavior,
then
they
tend
to
get
just
a
little
bit
of
editorial
discussion
if
necessary,
and
then
they
get
closed
for
anything
that
warrants
a
discussion
so.
L
Bring
it
here,
you
said
yes,
okay,
so
I
understand
that
for
typos,
which
no
discussion
I
I
can
just
doom
full
request.
There
are
probably
only
10
of
them.
Total
amount
is
28
or
29.
There
are
a
couple
of
almost
duplicates.
F
F
We
say
that
a
line
break
can't
appear,
and
you
pointed
out
that
one
can
appear
in
a
block
that
was
probably
just
a
miss
so
that
that's
also
an
editorial
change
and
you
should
feel
free
to
send
requests
for
those
as
well.
L
Okay,
but
most
serious
issues,
there
are
probably
10
15
of
them,
which
will
require
kind
of
participation.
So
essentially,
my
ask
here
is
not
to
discuss
every
one
of
them.
It's
just
exactly
what
you're
talking
about
the
pro
the
further
process.
So
I
got
that
simple
things
which
is
no
question.
I
will
just
push
it
right.
What
about
the
other
things?
Should
I
create
separate
discussions.
F
F
Yeah
yeah
yeah.
That
way
we
can
keep
discussion
focused
because
it
may
be
the
case
that
one
of
the
particular
changes
is
straightforward
and
easy
to
merge
with
a
lot
of
agreement.
While
another
one
warrants
discussion
and
you
wouldn't
want
to
hold
up
the
ones
that
are
easy
because
of
the
ones
that
are
require
more
discussion.
L
Okay,
okay,
so
I
will
post
it
please
with
those
items
that
require
discussion
or
input
from
everyone.
Please
take
another
because
again
seeing
this
in
such
a
document
ruins
the
impression
people
you
won't
take
it
seriously,
it's
kind
of
look
a
maturish,
you
know
when
people,
so
let's
fix
this,
that's
it
for
me
for
the
first.
C
Things
just
to
know
I've
added
an
action
item
for
you,
roman
to
file
these
prs
and
discussions.
L
D
L
Ready
go
for
it,
okay,
so
bigger
issues,
so
this
is
something
that
is
not
small
things
and
my
goal
is
not
to
discuss
them
now
and
here
my
goal
is
to
start
discussion
in
the
future.
So
here
that
you,
you
would
probably
think
some
of
many
of
you
would
think.
That's
too
much.
L
That's
the
big
change,
but
let's
sleep
on
this
and
discuss
later-
and
here
is
my
impressions,
recent
impressions
of
the
newcomer
when
you
come
and
start
reading
and
something
just
doesn't
make
much
sense
and
on
the
overall
surface
of
the
entire
spec.
L
So
the
agenda
there
are
basically
five
items
I
want
to
run
through
and
what
is
graphql,
the
definition
chapter
order
and
titles.
There
are
two
chapters
sdl
its
purpose,
algorithms
and
specification
scope.
L
L
It's
not
for
me.
Is
it
like
react,
something
that
you
can
build
the
entire
application
in
your
browser
without
any
server?
It
sounds
like
react
right
and
you
can
create
a
tic-tac-toe
game.
You
don't
need
any
servers,
so
this
is
kind
of
strange
and
the
second
thing
is
it's
the
language,
but
many
things
in
the
spec
are
not
about
language
way.
More
than
simply
language,
and
by
the
way
there
are
two
languages,
if
you
think
about
this,
so
how
I
think
it's
somewhat
can
be
improved
and
look
at.
L
L
So
summary
x,
the
variations
are
framework,
language
and
the
protocol
or
is
a
protocol.
I
think
the
things
they
call
themselves
framework
when
actually
they
provide
some
tool
of
code
executable
code
like,
for
example,
grpc.
They
actually
provide
code
generators
as
part
of
the
whole
thing,
so
it's
ideal
language,
it's
a
protocol
and
plus
it's
actual
generators
that
will
generate
your
code
in
different
languages.
So
that's,
I
think,
the
distinction
when
you
call
yourself
framework
we're
not
framework,
we
do
have
a
language
and
I
think
we
are
a
protocol.
L
They
have
only
one
language
ideal
we
have
to
it
was
it
took
me
some
time
to
actually
realize
this,
as
I
was
going
through
spec
and
through
actual
implementation
of
the
code
that
it's
actually
two
languages,
which
are
quite
different,
now
chapter
order
and
titles,
so
we
have
chapter
language
and
type
system
and
the
the
problem
is
with
the
language
section
most
of
the
sections
11
out
12.
L
They
describe
request
language,
yes,
but
querying
against
what
something
that
is
not
defined,
and
this
type
system
is
defined
actually
in
the
next
chapter,
so
this
order
seems
really
strange
and
after
jumping
back
and
forth,
back
and
forth
what
is
input
object?
What
is
this
types,
color
types
and
so
on?
L
I
I
actually
realized,
aha,
that
that's
that's
the
thing,
so
the
type
system
is
described
after
the
language
or
the
means
to
query
against
this
type
system.
So
basically
they
should
be.
I
think
in
reverse
order.
Second
thing:
the
titles
are
a
bit
misleading.
L
L
So
my
suggestion,
since
we
have
two
languages
so
suggestion
different
order
and
different
titles
first
to
have
a
type
system
and
schema
definition.
Language-
and
next
we
have
requests-
should
be
request.
That's
kind
of
seems
logical
to
me.
L
Now
the
purpose
of
the
sdl
is
quite
unclear
and
was
quite
a
discovery
for
me
that
it's
not
like
in
other
communication
protocols,
so
basically
I
idl
or
sdl
in
our
case
it's
interface
definition
language
and
it
looks
like
it
should
be-
a
complete
disc
description,
definition
of
the
api
particular
api,
like
grpc
for
grpc
protofile,
is
this
complete
source
of
truth,
complete
definition
of
the
language
and
they
generate
server
and
client
stubs?
That's
all
you
need
to
know
to
communicate.
L
I
actually,
when
I
started
getting
into
graphql.
I
expected
this
is
something
like
this
here,
but
was
told
that
that's
not
the
case
actually.
L
The
explanation
was
provided
by
benji
that
introspection
is
the
source
of
truth,
not
sdl,
so
sdl
file
is
built
from
interest.
Introspection
and
sdo
is
not
source
of
truth
and
sdl
is
for
code,
first
schema
whatever
code
generators,
and
there
was
a
mention
in
one
of
the
discussions
that
exposing
everything
from
through
introspection
all
the
this
is
some
security
risk.
L
This
sounds
like
a
really
strange
and
not
matching
expectations
for
a
newcomer,
so
it's
different
from
other
frameworks.
It
is
not
explained
in
the
spec
and
strange
thing:
api,
any
particular
effect.
It
cannot
be
described
before
it
is
built
because
it's
you,
you
gotta,
have
introspection
api
working
in
order
to
describe
the
interface
well
in
many
situations.
You
know
before
you
build
you
actually
like
in
grpc,
you
write
down
by
hand
protofile
or
sdl
for
idl
file,
and
you
share
with
your
other
teams
with
your
team.
This
is
design.
L
So
that's
how
you
describe
the
interface.
You
use
the
textual
representation
of
the
description.
You
share
it
and
then
you
implement
it,
and
then
you
have
introspection
working
so
as
for
and
then
it's
unclear
why
we
will
even
spend
so
much
time
on
sdl
grammar
if
it's
only
for
code
generators.
L
L
L
L
L
L
L
L
L
L
What's
on
the
wire,
it
should
not
touch
how
the
server
particularly
does
this,
which
means
that
all
this
validation
and
most
of
the
execution
things
don't
need
to
be
there,
because
it's
out
of
scope
of
a
communication
protocol,
as
I
said
much
much
of
this
stuff,
is
purely
obvious
things
all
these
algorithms,
I
didn't
find
any,
except
maybe
one
or
two
algorithms
that
actually
add
some
value
and
even
like,
for
example,
collecting
fields
and
merging
fields.
L
F
F
I
want
to
say
that
a
lot
of
these,
I
think,
are
going
to
be
really
interesting,
healthy
discussions,
the
one
that
I
really
firmly
disagree
with
is
the
idea
of
removing
algorithms.
The
spec
is
the
algorithms
they
describe.
What
what
you
should
expect
to
see
the
the
behavior
output
be
the
implementation
doesn't
have
to
literally
line
by
line
mirror
the
algorithm.
We
have
language
in
the
spec
text
that
say
as
long
as
it
appears
to
produce
the
the
behavior
described
by
those
algorithms.
F
It's
accurate,
but
but
that's
actually,
the
you
know,
especially
when
you
get
into
the
sort
of
legal
pieces
of
this,
does
something
comply
or
not.
The
the
algorithms
are
the
way
in
which
you
do
that,
rather
than
just
a
descriptive
paragraph.
All
the
rest,
I
think,
is
very
open
to
discussion
and
you
ought
to
open
a
discussion
for
that
one
as
well,
but
thanks
for
assembling
the
the
content
and
opening
some
spicy
discussions
always
really
worthwhile
to
discuss.
But
anyhow,
I
know
we're
a
couple
minutes
over.
F
Thank
you
all
for
all
the
updates,
the
hard
work
and
the
interesting
discussions.
I
will
see
many
of
you
next
week
for
the
graphical
conf.
I
know
many
of
you
will
dial
into
welcome
you
to
see
you
and
then
we'll
we'll
keep
the
conversation
going
next
next
month.
L
By
the
way,
can
we
for
one
minute
discuss
one
of
my
suggestions
about
the
second
meeting
or
so
to
create
automatically
overflow
meeting
a
week
from
the
main?
So
if
we
have
the
situation
just
like
this,
we
automatically
have
next
thursday
meeting
to
continue
with
this
agenda.
L
So
can
we
just
vote
or
discuss
this
for
one
minute
and
maybe
then
automatically
set
up
next
thursday,
the
meeting
to
discuss
whatever.
F
Is
left,
I'm
gonna
suggest
we
take
that
one
async,
since
this
particular
session.
That
would
be
hard
to
do
since
many
people
are
going
to
be
at
the
live
conference
next
week,
and
so
it
might
be
a
little
challenging
to
get
everyone
together.
There's
going
to
be
conference
talks
going
on
next
thursday.
K
Yeah
one
announcement
so
like
my
topic
was
last
minute,
so
I'm
quite
expected
it
can
be
like
pushed
out.
So
I
shared
like
a
link
in
in
comments.
I
will
check
if
it's
a
good,
transgender
or
not,
I
go
to
notes,
I
will
update
agenda
and
I
will
basically
try
to
rewrite
the
same
thing
into
into
rfc
on
a
spec
repo
or
like
working
group
rip.
I
actually
forgot
where,
where
is
right
now
and
thanks
for
like
discussion?
Actually,
it's
like
some
of
the
discussion
happened
in
comments.
K
I
think,
and
I'm
totally
okay
with
like
waiting
next
month.
For
me,
it's
important
that
all
people
present
and
focused
and
have
like
a
dedicated
time
for
it.
So
it's
not
like
random
or
there
is
like
oh
separate
overflow
meeting,
with
like
different
participation
so
like.
If,
if
you
can
talk
my
my
anecdotal
case
as
evidence,
I'm
like
I'm
totally
for
moving
it
to
the
next
one,
and
I
will
be
ahead
of
wine
in
next.
One
expect
yeah.
F
Awesome
looking
forward
to
it
thanks,
yvonne
all
right
folks,
that's
a
wrap
for
today.
Thanks
again
talk
to
you
next
time.