►
From YouTube: GraphQL Working Group - December 3, 2020
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).
B
C
We'll
give
it
another
minute
or
so
for
folks
to
show
up
if
you
haven't
put
your
name
in
the
attendees
list,
all
the
emerging
pull
requests
as
they
come
in.
C
A
C
Hello,
hello,
hello,
we're
just
waiting
a
minute
or
so
for
attendee
lists,
and
if
your
name
isn't
on
the
agenda
attendee
list,
please
feel
free
to
send
a
pull
request.
I'll
merge
in
a
few
of
those
as
they
come
in
just
in
these
next
few
minutes,
but
I'll
clean
up
the
rest.
After
the.
C
C
All
right
participant
list
looks
pretty
stable.
I
made
it
through
all
the
prs
that
were
just
up
they're,
not
in
any
specific
order
this
time,
but
that's
okay,.
C
Let
me
know
about
them
quick
overview
of
our
agenda
of
oh
actually,
let's
just
start
from
the
top,
as
we
usually
do
so
thanks
everybody
for
joining.
Of
course,
by
joining
here,
we
all
agree
to
the
membership
agreement.
The
participation
guidelines
in
the
code
of
conduct
just
a
usual
thing
at
the
top
there's
links
there.
If
you
forget,
what's
in
those
but
just
a
reminder
that
we
have
those
there
and
let's
get
to
the
intro
of
the
attendees.
Hopefully
I
think
almost
everybody
here
is
a
familiar
face.
C
Maybe
a
couple
new
folks,
so
it's
always
good
to
get
names
to
faces,
especially
for
people
who
watch
the
the
videos
of
these
afterwards.
So
let's
use
the
attendee
list
order
in
the
agenda.
If
you
refresh
that
I've
merged
a
couple
of
requests,
so
you'll
see
the
latest
list
there,
I'm
at
the
top,
so
hey
everybody.
My
name
is
lee
and
I'll
hand
it
to
see
james
has
not
joined
yet
so
michael.
C
A
D
I
think
I'm
up
next
dan
schaefer
and
facebook.
F
Hi,
I'm
benji.
I
work
on
postgraphal
and
various
other
open
source
things
and
have
a
few
spec
things
to
discuss
today.
H
I
K
L
Hi,
my
name
is
alan
shah.
I
work
for
ibm
research,
I'm
working
on
graphql
management
as
well
as
some
open
source
libraries
related
to
graphql.
B
Hi,
I'm
nick
I'm,
the
ceo
founder
of
elemental
and
one
of
the
graphical
co-creators,
along
with
lee
and
dan
and.
L
B
Like
sasha
will
be
a
fly
on
the
wall,
mostly
I'm
here
in
my
capacity
as
a
member
of
the
technical
steering
committee,
which
lee
may
be
able
to
give
us
more
context
on.
I
assume
you're
gonna
mention
that.
C
That's
our
list,
yeah.
I
think
we
talked
about
that
last
time,
so
hopefully
everyone
is
familiar
with
that,
but
the
folks
are
on
our
tsc
anytime.
You
have
something
that
needs
an
official
vote
rather
than
just
me,
ruling
by
dictum.
We
now
have
a
group
of
people
who
can
shine
in
which
is
a
good
thing
and
it
forces
nick
to
attend
our
meeting
and
hang
out
with
us.
C
C
One
from
benji
talking
about
the
dunder
type
name
at
subscription
root
from
mark
talking
about
schema,
coordinates
another
from
benji
on
default
value,
coercion
and
then
I've
moved
the
discussing
previous
meeting
action
items
to
the
end
of
the
meeting.
Usually
we
do
that
at
the
beginning,
but
we've
got
a
little
bit
of
a
backlog
and
then
she's
going
to
help
us
kind
of
turn
through
that
all
so
I
figured
it
might
be
best
to
save
that
for
the
last
anything
else.
You
all
want
to
talk
about
while
we're
all
here.
K
I
will
send
the
link
in
a
minute-
and
it's
related
to
bunch
of
pr
about
like
input
creation
of
default
values
in
like
in
some
ways
so,
and
I
think
like
we,
we
release
it
in
reference
implementation
a
long
time,
so
maybe
we
cannot
quickly
discuss
it
and
manage
it.
C
I
see
andy
mentioned
that
we
should
give
benji
a
gift
for
taking
notes
for
so
long.
I
agree
we'll
figure
out
a
way
to
do
that
for
sure
no
champion.
F
A
F
So
we
discussed
this
previously.
Basically,
it's
not
valid
at
the
moment
like
you
can't
it
validates,
so
I
shouldn't
say
valid
if
you
put
dunder
type
name
in
a
subscription
operation,
it
validates,
but
it
will
never
give
you
a
good
result,
because
dunder
type
name
does
not
return
a
async
iterator.
F
So
basically,
it's
always
going
to
give
you
an
error.
It
also
causes
confusion
with
various
bits
of
tooling
that
think
that
they
can
safely
add
it
at
the
top
of
the
subscription
operation.
In
addition
to
whatever
field
it
is
that
whatever
subscription
field
you
wish
to
add.
So
I
discovered
this
whilst
working
on
the
query,
ambiguity,
stuff
and
I
wanted
to
basically
make
it
explicitly
clear
rather
than
an
accidental
issue.
I
wanted
to
just
explicitly
state
that
this
isn't
valid.
F
So
what
I've
proposed
is
that
we
do
that
with
a
slight
modification
to
the
spec
which
I've
outlined.
I
outlined
previously
got
some
feedback
and
I've
re-implemented
it.
So
it's
now
part
of
the
validation
rule
where
it
says
that
one
field
there
may
only
be
one
field
on
the
subscription
operation.
Now
it
says
there
can
only
be
one
field
and
that
field
must
not
be
an
introspection
field.
F
And-
and
that
is
it,
that's
it
it's
quite
a
small,
quite
a
small
change,
so
my
main
aim
would
be
to
gather
feedback
to
see
what
people
think
and
maybe
to
move
this.
I
have
done
a
basic
implementation
in
graphql.js,
but
I
believe
that
there
is
some
issues
that
I
need
to
talk
to
a
van
about,
and
I
haven't
had
a
chance
yet
so
that
will
come
later.
D
So
my
initial
instinct,
when
I
heard
it
was
like
that's
weird
that
makes
the
subscription
object,
act
different
than
other
objects,
but
the
subscription
object
already
is
different
than
other
objects.
It
like
takes
you
into
async
land.
You
can
only
have
one
field
on
it.
I
was
like
thinking
of
being
like
what
is
like
under
type
name
return
for
subscription.
Should
that
what
does
it
even
mean
to
return?
This
feels
right
to
me.
D
D
C
Benji's
our
resident
deep
reader
of
the
spec,
I
feel
like
you've,
found
the
most
weird
quirk
so
far
any
dissenting
opinions
on
this
or
like
what
what's
the
cost
of
of
making
this
change.
G
Hi
yaakov
here
just
found
out
actually
about
this
meeting,
probably
should
register
in
advance.
I've
been
working
on
the
graphql
tools
repository.
I
think
it's
really
great
to
to
to
really
point
this
out
as
explicit.
I
ran
into
this
as
bug
where
end
users
were
expecting
this
to
work
and
or
my
implementation
of
query.
Wrapping
was
expecting
this
to
work,
and
it
doesn't
so
it's
good
to
make
it
explicit.
G
I
think
it's
fine
to
change
the
spec
now
to
match
the
implementation,
but
I
think
better
would
be
to
change
the
implementation
to
match
the
spec.
I
don't
think
it
harms
anybody
to
allow
type
name
to
be
used
and
there's
you
know
there
is
a
use
case
for
it.
If
you
want
to
get
a
fully
typed
response,
that's
a
little
bit
more
easy
to
automate.
I
think
in
the
future.
We
might
want
to
consider
allowing
multiple
fields
in
subscriptions.
G
If
there's
a
pathway
for
that
going
forward,
I
think
it
makes
sense
to
start
with
just
one
as
it's
complicated
enough,
but
it
doesn't
seem
to
me
to
be
well.
It
seems
to
me
to
be
ideal
for
the
spec
to
match
the
implementation
one
way
or
the
other,
but
going
forward
it's
you
know
again,
it's
a
small
thing
and
it
seems
like
it
can't
it
can't
hurt
to
actually
allow
it
to
work.
G
The
name
of
the
the
type
I
mean
that's
usually
subscription,
you
know
it
can
be
customized.
I
mean
it's
the
same
thing
as
the
type
of
any
of
you
know,
query
a
mutation
it
works
for
those
and
might
as
well
work
for
subscription.
C
Yeah
and
part
of
why
it's
it's
quirky
here
and
why
the
subscription
type
in
particular
is
weird.
Is
that
all
of
those
fields
don't
return
values,
but
they
return
async,
iterators
or
streams
of
values,
and
the
type
name
is,
is
a.
I
guess
you
could
model
that
one
as
a
as
a
special
edge
case,
where
that
one
does
in
fact
return
a
stream
of
string.
That's
only
yields
one
value.
G
It
would
just
be
ignored
during
the
the
first
run
through
and
then
when
it
gets
resolved.
I
think
it
would
work,
it
would
work
there,
but
I
do
have
to
think
about
it
more,
but
I
think
that
would
work.
E
Long
term,
it
probably
it
likely
makes
sense
for
us
to
like
rethink
subscriptions
and
figure
out
how
to
have
multiple
root
fields
on
them,
but
because
that
brings
subscriptions
more
in
line
with
everything
else.
But
given
we
don't
allow
that,
and
it
would
probably
be
a
gnarly
project
to
do
that,
bringing
the
spec
in
line
with
current
expectations
and
just
saying
in
a
type
name
that
doesn't
actually
make
sense
on
subscription.
As
we
originally
wrote,
it
feels
more
right
than
the
current
state.
G
I
definitely
agree.
The
current
state
is
inconsistent.
What
if
I'm
not
sure
if
I
did
have
time,
but
if
I
had
time
to
try
to
get
an
implementation
working
where
it
was,
you
know,
worked
and
was
able
to
donate
that
time.
Would
that
be
something
people
would
be
interested
in?
Seeing
you
know,
I
myself,
I'm
not
sure
if
I
fully
thought
it
through,
but
I
think
it.
I
think
it
could
work
as
a
special
case.
If
that's
something
people
would
be
interested
in
I'd,
be
willing
to
work
on
it.
G
I
think
if
I
had
time,
but
if
not
you
know,
you
know
not
the
largest
of
deals,
there
are
workarounds.
C
It
could
be
interesting.
You
know
we
part
of
the
challenge
here.
Is
that
we'll
have
to
make
sure
that
this
makes
sense
for
for
all
implementations
and
not
just
the
reference
implementation?
So
I
I'd
want
to
make
sure
that
if
we
were
gonna
follow
that
path
that
it's
something
that
would
be
viable
for
for
many,
and
would
the
idea
be
that
this
would
be
an
another
like.
We
would
also
describe
the
edge
case,
but
we'd
describe
it
in
a
different
way.
C
Where,
right
now
the
existing
spec
says
a
that
field
set
has
to
have
exactly
one
entry.
So,
presumably
you
could
have
a
subscription
which
asks
for
one
entry
and
that
entry
is
type
name.
It's
probably
not
a
particularly
helpful
query
to
write,
which
I
think
is
why
benji
is
proposing
blocking
it,
and
we'd
have
to
caveat
that
with
must
have
exactly
one
entry,
except
if
it's
an
introspection
field.
Is
that
what
you're
proposing
yakov.
G
Pretty
much
pretty
much
you
would,
we
would
just
be
allowing
just
the
introspection
field.
We're
really
just
I'm
thinking,
just
type
name,
I'm
actually
not
so
familiar.
Are
there
other
introspection
fields
that
make
sense
on
a
subscription.
G
Yeah
yeah,
I
mean
it's
it's
harder
for
me,
because
my
familiarity
is
with
typescript
much
more
than
flow,
but
I'd
be
willing
to
give
it
a
go,
and
if
it's
not
I
mean
it
might
be
very
gnarly.
But
if
it's
not
too
gnarly-
and
you
can-
you
know
just
be
a
nice
comparison-
maybe
to
what
benji's
already
worked
on
to
bring
the
spec
sorry
to
bring
the
implementation
in
line
with
the
spec.
G
And
then
you
know
we
could
choose
going
forward
like
I
said
there
are
workarounds,
I
don't
prefer
them.
I
prefer
it
working,
but
you
know
whatever.
K
I
can
qualify
a
bit
as
understand
we
limit
subscription
to
one
field
because
it's
one
event
stream
so
like
if
we
have
two
fields.
If
we
subscribe
to
two
filters
like
two
event,
streams
and
button
spec,
we
write
the
subscription
is
like
two
part.
One
part
is
to
registrate
for
subscription.
Another
part
is
every
event
for
event.
Stream
should
pass
through.
K
Basically
through
execute
you,
you
pass
event
and
you
you
resolve
all
the
stuff
deeper.
So
for
this
phase
we
already
have.
We
should
have
schema
anyway.
So
if
we
have
schema
anyway
on
event
resolution
time
we
can
provide,
we
can
provide
inspection
free
fields
for
free.
There
is
no
like
in
what
sense
all
introspection
fields
are
the
goal
of
all
to
power.
Introspection
fields
are
special
because
they
don't
have
a
subscribe
and
not
associated
with
the
one
stream,
so
I
would
say
trade-off
for
logan.
K
What
jacob
proposing
is
that
we
change
a
row.
We
make
it
a
little
bit
more
complex
and
like
instead
of
having
exactly
one
field,
we
say
exactly
one
non-introspection
field
and
we
have
clear
definition
of
what
introspection
and
non-introspection
fields
in
a
spec,
but
we
say
bunch
of
like
jacob
created
pr
for
graphql
tools
for
like
work
around
this
limitation
and
basically,
if
we
reinforce
it
every
new
client.
Every
new,
like
many
new
libraries,
need
to
work
around
the
fact
that
you
cannot
acquire
a
type
name
like
through
entire
graphql
system.
K
It's
like
the
factor
standard
for
especially
for
schema
os
y
clients
to
inject
type
names
on
every
level.
So
basically
people
need
to
add
a
bunch
of
work
around,
so
we
make
it
harder
for
them.
So
it's
like
trade-off
is
a
we
like
to
make
a
little
bit
more
complex
validation
or
we
had
like
special
handling
of
for
subscription
in
every
graph
in
many
graphql
coins.
So
I'm
for
for.
K
Identification,
proposing
is
what
banjo
proposing
is
like
a
resolution
of
ambiguity
and
what
this
alternative
proposal
is
like
adding
kind
of
new
feature,
because
correction
was
about
forbidding
just
underscore
the
score
type
name,
a
wolverine
underscore
underscore
type
name
in
addition
to
fields.
It's
like
a
new
feature.
C
That's
a
really
good
point,
and
it
actually
makes
it
clear
that
we're
not
really
faced
with
an
either
or
situation
here.
We
could
actually
continue
ahead
with
what
benji's
proposing,
because
it's
always
safe
to
go
from
something
not
being
allowed
to
something
being
allowed,
but
the
other
way
around
is
is
not
safe,
so
we
can
start
by
resolving
the
ambiguity
and
and
then
follow
up
yakov
within
with
an
actual
proposal
that
allows
a
case
that
actually
currently
is
not
allowed
right.
Like
you,
you
can't
add
two
rights.
C
G
Spec
says
it's
kind
of
allowed
everyone
you
know
benji's
the
has.
He
is
probably
the
first
one
to
discover
it.
You
know
serendipitously
at
pretty
much
the
same
time
as
I
ran
into
the
bug,
so
I
would
agree
with
that.
It's
totally
I
mean
personally
from
totally
okay
to
just
bring
this
back
back
into
line
and
then
look
at
this
as
a
as
a
change.
You
know
to
take
what
I'm
proposing
or
or
really
what
what
was
proposed
just
now
much
more
eloquently
as
I
would
agree
with
that
as
a
future
request.
G
I
can
help
I
mean
I
would
I
would
right
now.
I
guess
I
think
we
were
talking
about
benji
moving
forward
to
make
the
validation
current
behavior,
and
then
the
spec
would
be
clarified
to
match
that
and
then
once
that's
all
through,
we
would
start
over
again
to
you
know
to
to
to
brainstorm,
I
mean
I
was
interested
only
in
the
type
name,
but
I
think
I
would
agree
with
you
even
that
all
the
introspection
fields,
based
on
what
you
were
saying
would
make
sense
to
be
valid.
C
The
I'm
pretty
sure
the
type
gender
type
name
is
the
only
introspection
field
that
would
be
valid
in
that
spot.
Asking
for
schema
is
only
allowed
on
the
query
type
that
that
one's
already
pretty
clear.
So
I
think
it
would
make
sense
that
we
wouldn't
extend
that
one
into
the
subscription
field.
I
don't
think
you
need
to
wait
by
the
way
for
for
this
change
from
benji
to
kind
of
make
its
way
through
the
paces.
C
If
this
is
something
that
you
think
is
the
right
thing
to
do,
then
you
should
champion
it
and
write
up
a
proposal
or
hack
together,
something
in
a
reference
implementation
to
test
it
out
to
see
if
it's
worth
the
complexity
cost,
especially
for
now.
Looking
at
these
as
two
separate
things,
one
resolving
an
ambiguity
and
one
adding
new
capabilities.
G
Okay,
you
know
my
schedule
depending
but.
F
You're
welcome
yeah
just
to
to
comment
further,
as
you
say,
it's
all
to
do
with
the
one
field,
literally
the
query.
That
only
has
the
type
name
in
it.
I
think
what
you're,
what
you're
proposing
at
the
moment,
with
the
allowing
also
the
the
dunder
type
name
to
be
added,
opens
the
door
for
multiple
fields,
and
then
that
brings
about
the
the
hydra.
That
is
what
happens
when
we
have
multiple
event
streams.
F
C
It
has
to
be
it
has
to
be.
It
has
to
not
touch
that
hydra,
otherwise,
it's
doomed
merging
event
streams
I
mean,
maybe
eventually
we
want
to
get
there.
Matt
was
mentioning
we
might
want
to
get
there,
but
that's
a
much
bigger
effort
emerging
or
merging
those
streams
is
both
the
it's
actually
from
the
spec
point
of
view,
probably
not
that
hard,
but
like
making
sure
that
the
reference
implementations
aren't
overburdening
themselves
by
offering
that
capability.
C
There's
like
the
core
principle
of
not
allowing
things
which
are
inefficient
by
default
right,
and
so
that's
a
potential.
That's
that's
part
of
the.
Why
that
when
it's
really
hard,
I
dropped
a
link
to
the
part
of
the
spec
on
resolving
subscriptions.
I
I
do
think
just
like
a
thought
on
how
we
might
go
about
building
this.
You
could
probably
pull
the
source
part
of
the
reason
why
we
limit
that
selection
set
to
one
is.
It
just
makes
it
really
easy
to
pull
the
event
stream
out.
C
You
could
imagine
you
know
adjusting
that
algorithm
where
you
first
ignore
the
introspection
fields
and
then
require
there's
only
one
remaining
non-introspection
field
and
that's
your
event.
Stream
and
then
mapping
that
those
events
back
to
payloads
you
just
would
treat
under
type
name
like
any
other
field.
C
C
Okay
cool
sounds
like
we
have
a
good
path
forward
for
that
one
benji.
It
looks
like
you've
already
gone
through
some
details
on
on
the
actual
spec
changes
itself
there.
So
I'll
give
you
a
post
review
there.
It's
it's
likely
that
we
can
pass
this.
C
I
Oh,
thank
you
yes,
so
for
those
I'm
familiar
the
elevator
pitch
here.
Is
you
know
that
thing
in
graph,
iql
or
apollo
studio,
where
you
hover
over
a
thing
in
the
document,
and
it
says
that
the
name
field
on
the
user
type
written
as
user
dot?
Name
like
those
things,
so
we
use
them
everywhere,
but
there's
no
formal
specification
or
name
for
that.
So
that's
what
the
spec
proposal
is
doing.
I
I
So
those
are
now
two
poor
requests
and
thank
you
so
much
to
everyone
who
has
kind
of
dived
into
those-
and
I
know
benji
and
lee
have
spent
a
lot
of
time
looking
into
those
as
well.
So
thank
you
there
as
well,
it's
kind
of
looking
like
we're
at
say,
dotting,
the
eyes
and
crossing
the
t's
kind
of
phase
and
now
yeah.
There
was
one
specific
thing
that
I
came
here
to
talk
about
as
well.
I
I
I
Allow
you
to
refer
to
that
argument,
not
not
just
the
field,
so
you
could
write,
query
dot,
search
users
and
you
might
also
want
to
do
query
dot,
search
users
and
then
the
spec
edit
proposes
query
dot,
search
users,
open
brackets,
name
colon,
but
there's
another
scholarly
school
of
thoughts.
That
says
we
might
want
to
refer
to
that
as
query
dot
search
users,
dot
name.
I
So
that's
that's.
What
we're
discussing
today,
yeah
I
for
the
record,
I'm
relatively
you
know
either
way
here
I
want
to
do
what
makes
sense
than
most
people.
I
like
the
fact
that
the
curly
you
know
the
the
parentheses
kind
of
looks
like
what's
in
the
schema
and
it
you
know
it
slightly,
makes
it
less
ambiguous
that
you're
referring
to
arguments
specifically
and
not
just
like
a
directive
or
something
else,
but
yeah,
I'm
totally
happy
to
kind
of
hear
what
people's
thoughts
are.
G
So
I
can
jump
in
a
little
bit
because
I
was
I've
been
the
one
mostly
arguing
for
the
the
full
dots
representation
here,
just
because,
in
the
way
that
my
brain
is
pressing
this,
these
feel
like,
like
a
list
like
and
then
using
different
separators
for
different
parts
of
a
list,
just
seems
unnecessary.
G
But
benji
also
provided
a
really
interesting
example
in
the
in
the
github
comments
of
a
like,
where
that
could
be
ambiguous,
so
I
think
I'm
coming
around
a
little
bit
to
using
parentheses,
although
I'm
still
not
a
fan
of
what
that
colon
is
doing
there.
C
I
Yeah
there
was
some
galaxy
brain
thing
going
on
that
we
might
be
able
to
do
that,
and
also
it
looked
a
bit
like
swift,
which
we
all
liked
as
well.
Yeah,
again,
remember
relatively
unopinionated
there,
but
something
something
future
capability
seems
like
never
seems
like
a
bad
idea.
G
I
mean
if
we
want
to
list
multiple
arguments
there,
then
I
would
think
a
comma
would
be
more
appropriate
because
that's
already
what
we
use
in
graphql
for
deleting
multiple
arguments.
G
I
know
I
was
busting
a
cache
recently
by
just
appending
more
and
more
commas
to
the
end,
it
was
fun
and.
C
Weird
when
I
I
had
a
lot
of
opposition
to
the
idea
of
commas
being
not
not
a
a
part
of
the
real
grammar
they
like,
they
just
exist
as
a
magical
separator
entity
and
someone
in
our.
C
I
wasn't
actually
talking
about
you,
but
you
also
gave
me
some
good
for
it,
but
so
right
after
it
landed,
someone
made
comment
blocks
at
the
top
of
our
graphql
documents
in
ascii
art,
using
commas
and
commas
alone.
So
that
was
that
scott,
it
was
definitely
scott
walchak,
and
that
was
a
very
good
troll.
C
C
G
I
Sorry
mark
no
sorry
I
for
the
record
I'll
go
on
a
record,
and
I
like
commas
as
well,
but
yeah.
That
seems
like
a
something
that
a
future
proposal
could
could
wrangle
because
right
now
we
are
only
talking
about
the
one
argument
that
you
might
want
to
refer
to.
If
you
had
like
multiple
arguments,
then,
like
commas,
obviously,
you
know
visually
makes
sense.
As
a
delimiter
you
can.
You
can
look
at
that.
I
guess
again,
some
original
thinking
was
it.
I
C
That
is
part
of
the
reason
why
I
like
it.
It
makes
it
a
little
a
little
less
ambiguous
like
it
doesn't
look
like
a
value
being
passed
as
a
to
a
function,
that's
being
called.
You
know.
It
clearly
stands
out
as
something
a
little
bit
different,
which
makes
you
stop
and
think
like
wait.
What
is
it
I'm
looking
at?
C
C
C
There's
like
fewer
typings
on
the
keyboard
to
do
that,
but
if
we're
thinking
about
these
as
generated
and
then
displayed
back
to
people
so
that
they
can
understand
reference
points,
then
legibility
is
is
more
important
than
typability,
which
I
my
sense
is
where
most
of
the
the
motivating
use
cases
are
here
is
that
you
know
these
can
show
up
in
documentation
or
in
error
reports.
G
Yeah,
to
be
honest,
most
of
the
places
that
we
ended
up
using
like
referencing
parts
of
the
schema
we've
ended
up
doing
so
with
paths
into
the
queer
into
a
query
or
a
response,
rather
than
schema,
coordinates
and
so
like.
I
know
those
are
very
closely
related
things,
but
we've
been
trying
to
keep
them
separate
because
they
are
separate
things.
That's
I
think.
G
Maybe
the
other
thing
that
I
like
about
dots
is
that
it's
very
easy
to
kind
of
extend
it
arbitrarily
along
enter
into
a
full
path
where
the
parentheses
and
colons
make
that
a
little.
I
mean
it's
still
possible.
It
just
looks
a
little
weirder
if
you've
got
colon
dot.
I
Another
wrinkle,
maybe
so
in
the
screenshot-
that
I
get
that
I
shared
of
the
graph
iql
like
docs
search
tab
thing
that
actually
will
show
you
the
the
type
of
a
thing.
So
when
you
type
in
like
user
and
it
shows
the
query
dot
user,
it
actually
displays
like
create.user
colon
string,
I
believe
so
there's
already
some
sort
of
like
weirdness
there
that,
like
graphical,
might
have
to
figure
out
visually.
It
might
need
to
change
its
ui
yeah.
C
Column,
that's
interesting.
Actually
I
came
to
the
separate
conclusion
on
that
one,
because
if
you
this,
I
think
it's
back
to
it.
What
benji
was
commenting
on
in
that
thread,
which
is,
if
you
just
use
the
dots,
then
you
don't
have
a
separator
to
indicate
if
the
thing
that
comes
after
that
is
referring
to
the
argument
or
referring
to
the
return
type,
and
so
when
you
have
type
dot
field,
colon
type,
that
makes
it
clear
that
you're
referring
to
the
return
value
of
that.
But
if
you
add
another
dot
in
there,
then
it's
like.
C
Are
you
following
a
path
to
a
return
type,
or
are
you
talking
about
the
type
that
that
argument
accepts,
which
is
maybe
a
reason
to
include
the
at
least
the
parentheses
part
of
this?
And
then
I
guess,
if
you
were
going
to
include
the
the
type,
then
you
definitely
would
want
that
that
colon
there,
but
that
doesn't.
I
Yeah,
I
I
don't
think
that
I
don't
think
what
I
said
is
a
blocker
for
the
record
like
you
could
just
have
another
colon
or
the
ui
could
use
an
arrow,
or
I
mean
I
guess
that
would
be
weird
yeah.
I
I
don't
think
it's
a
block,
but
just
like
an
interesting
kind
of
is
what
the
use
cases
were
talking
about
are
actually
doing
today.
F
So
one
of
the
things
that
I'm
trying
to
keep
in
mind
for
this
is
this
is
a
spec
for
schema,
coordinates
and
it
should
address.
Schema
coordinates
specifically,
but
we
should
keep
in
mind
that
others
might
want
to
extend
on
this
syntax
in
future.
So
I
think
if
we
can
make
it
a
syntax
that
we
can
expand
for
other
use
cases,
we
should
do
so,
which
is
why
I've
pushed
back
evan
quite
heavily
on
the
on
the
dots.
F
I
don't
know
what
the
use
cases
are
and,
to
be
honest,
the
ones
that
I've
come
up
with
so
far
haven't
been
that
great.
But
you
know
we've
only
been
talking
about
this
for
a
few
months
and
who
knows
what
someone's
going
to
come
up
with
in
two
years
time:
yeah
yeah.
G
I'm
fine
with
I'm
fine
with
parentheses,
I
think
parentheses
and
and
alone,
and
we
can
leave
the
colon
and
like
sub
dot
stuff
for
a
second
wave
of
discussion
leaves
us
in
a
pretty
good
spot.
At
least
I
see
a
path
forward
for
all
of
these
cases.
I
want
out
of
this
so.
C
I'd
still
propose
keeping
the
trailing
in
just
for
its
ability
to
put
it
in
front
of
someone
and
and
be
a
little
bit
more
clear
about
what
it
is
that
they're
looking
at
like
from
it,
does
nothing
for
the
interpretability
of
of
that
thing.
Right,
like
the
it's
purely
there
as
a
as
a
tool
for
someone
to
look
at
this
and
make
it
clear
that
this
is
not
a
value
being
passed
in,
but
this
is
the
the
left-hand
side
of
where
value
be
passed
in.
I
I
do
think
you
know
for
this
group
of
people.
C
My
my
intuition
is
that,
for
the
vast
majority
of
users
of
the
graphql
system,
who
see
these
things
for
the
first
time,
the
like
a
little
detail
like
that
will
be
the
difference
between
kind
of
understanding,
what's
being
referred
to
and
being
confused
and
hopefully
not
being
confused
in
a
way
that
causes
them
to
lead
to
a
different
conclusion.
G
Yeah,
I'm
just
not
sure
how
the
colon
then
ex
lets
us
expand
this
further
into
paths
in
the
future,
because
you
kind
of
end
up
with
this
weird
colon,
just
in
the
middle
of
your
argument,
path
or
yeah.
That's
that's
the
like.
That's
the
direction
that
I
I
want
to
go
in
with
this
eventually,
because
that's
what
shopify
is
already
using
it
for
basically
and
yeah
the
colon
I
mean
it's,
it's
not
an
unsolvable
problem.
It
just
starts
to
feel
a
little
awkward.
K
K
G
Yeah,
I
can
expand
a
little
bit
on
our
on
our
use
case
right
now,
which
is
we
have
a
tool
that
shows
our
third-party
clients
when
they're,
using
a
deprecated
input
and
right
now
we
give
them
basically
actually
what
what
benji
put
in
that's
actually
a
really
nice
index
ng.
I
like
that
mutation.do
thing
and
then
in
parentheses,
input.user.name
colon
right
now.
We
do
a
slight
variation
on
that
to
show
them
which
thing
that
the
which
part
of
the
input
that
they're
using
has
been
deprecated
that
they
need
to
change.
G
You
know
we
could
do
that
as
like
a
plain
array
of
json
strings
of
the
path
in,
but
that
just
starts
to
feel
a
little
ugly.
I
like
the
right
now
right
now.
Actually
we
just
do
plain
dots,
so
we
just
write
mutation.dothing.input.user.name
and
that's
unambiguous,
because
we
never
refer
to
a
second
field.
We
only
refer
to
like
type
dot
field
dot
as
many
arguments
as
as
we
need
into
the
input
path,
but
I
do
like
the
parentheses
version
for
that.
If
we
can
then
dot
the
inputs
beforehand,.
A
G
Yeah
I
didn't
I
was
thinking
when
we
were
talking
about
the
art
equal,
and
I
was
thinking
that
the
colon
we
would
use
the
cool
one
as
a
delimiter
as
a
delimiter
there,
which
gets
really
weird,
but
actually
just
using
dots
for
that
inside.
The
parenthesis,
as
benji
put
in
the
chat,
is
quite
a
nice
pattern.
G
C
C
So
let's
follow
up
if
we,
if
we
needed
like
this
little
sub
community
meeting
to
kind
of
like
hash
out
the
last
details
of
this,
we
can
do
that.
But
let's
see
how
far
we
can
get
just
sort
of
like
working
it
through
in
the
in
the
actual
rfc.
We've
made
a
lot
of
progress
there
in
the
last
month,
just
in
time
between
these
two
meetings.
So
hopefully
we
can
do
the
same.
C
I
So
when
I
was
writing
the
rfc
I
spent
like
80
of
the
time
I
wrote
in
the
coordinates,
I
actually
just
wrote:
schema
selectors
instead
and
then
like
oh,
no,
we
named
it
schema
coordinates,
so
we
landed
at
coordinates
because
that's
kind
of
what
graphql
java
did
field
coordinates
and
it
feels
right,
but
looking
at
it
now,
I'm
just
wondering
if,
like
if
someone
outside
of
this
group
was
to
look
at
this,
like
schema,
coordinates,
that's
a
whitney.
I
Do
we
want
something
just
like
a
little
bit
more
flashy
or
I
don't
know,
I'm
not
I'm
I'm
super
not
tighter
schema
coordinates,
there's
a
name
for
this
and
if
there's
something
more
intuitive,
like
schema
selectors,
that
people
prefer.
I
think
that
that
could
make
sense.
C
I'm
not
tied
to
the
name
at
all.
I
have
no
idea
how
how
we
would
decide
which
is
the
best
fit
I
feel
like.
We
should
throw
like
a
poll
up
on
twitter
or
something
and
see
if
people
react
to
it,
but
yeah,
I'm
all
about
the
bike
setting.
Let's,
we
should
come
up
with
other
ideas.
If
you
keep
finding
yourself
thinking
about
it
as
schema
selector,
then
this
is
your
proposal.
Man
rename
it.
I
Okay,
yeah
I'll
think
about
it.
Then
yes,.
K
F
F
I
think
one
of
the
interesting
things
about
the
schema
coordinates
at
the
moment
is
that
there
is
a
one-to-one
mapping
like
every
entity
in
the
graphql
schema
has
exactly
one
name,
whereas
when
you
have
the
the
more
path
style,
the
shopify
are
using
then
you're,
effectively
referring
to
a
a
field
on
an
input
type
or
something
like
that
through
a
path
which
is
a
perfectly
valid
thing
to
do,
but
it's
a
different
meaning
to
what
we've
got
here.
F
C
All
right
well
we'll
hash
out
the
last
details
of
this
offline
and
then
we'll
we'll
pull
together.
If
we
need
to
talk
about
something
together,
but
I
want
to
make
sure
we
we
make
it
through
the
rest
of
the
things
we've
got,
but
thanks
for
watching
us
through
this
mark,
I
feel,
like
we've
made
steady
progress
next
up,
benji
default
value
coercion.
This
one,
I
feel
like,
is
going
to
be
fun.
F
Oh,
my
god,
yeah
okay,
so
so
here's
the
thing
I
was
looking
through
the
graphql
spec
and
I
feel
like
this
is
how
all
my
stories
start
there's
some
interesting
things
that
go
on
with
default
value
everywhere.
Really
one
of
the
interesting
things
nick
nodding
knowingly
one
of
the
interesting
things
is,
I
would
expect
I'm
not
sure.
Let
me
let
me
share
specifically
share
my
screen
rather
than
putting
it
here
in
the
webcam.
L
F
Window
cool,
so
basically,
if
we
have
a
schema
like
this,
a
simple
schema
that
has
query
has
an
example
field
on
query
that
takes
an
input
object.
That
object
has
a
default,
which
is
the
empty
object
and
it
references
this
input
type,
which
is
a
number
field
which
also
has
a
default.
F
When
you
look
at
this
and
you
look
at
these
queries,
I
think
that
you
would
expect
them
all
to
have
the
same
result.
So
if
we
take
this
one,
this
is
the
most
fleshed
out
one.
So
we
take
the
example
we
pass
in
the
input
object
and
we
pass
into
it.
A
number
of
three
number
of
three
here
is
the
default
which
goes
in
there.
That's
like
the
fully
specified
version
that
doesn't
use
defaults.
F
F
It
turns
out
that
the
later
three
all
have
the
same
result,
but
this
first
one
does
not,
and
the
reason
for
that
is
that
this
value
is
passed
at
runtime
and
has
then
the
defaults
applied
to
it,
whereas
the
field
here,
if
we
don't
pass
an
input,
object
value
to
it,
then
it
uses
what
is
defined
in
the
schema
as
what
is
resolved
at
the
time
that
the
schema
is
defined,
which
is
literally
well
to
be
honest,
it
isn't
actually
resolved
it
just
uses
literally
that
value
you
could
put
the
number
seven
there
and
it
would
use
the
number
seven
which
doesn't
actually
conform
to
the
schema.
F
I'm
not
sure
if
that's
strictly
true,
but
I
think
it
is
at
the
moment,
so
this
seems
like
a
problem
to
me.
This
definitely
seems
like
an
issue.
I
thought
at
first
that
we
could
solve
this
by
just
you
know
just
coercing
it,
but
it's
not
that
simple.
There
is
significant
complexity
around
this,
which
broadly
comes
from
the
fact
that
these
things
can
be
recursive
right.
Input
objects
can
refer
to
other
input
objects
and
they
can
have
default
values
that
refer
to
themselves.
F
So
when
a
user
specifies
something
we
know
what
the
concrete
value
of
that
is,
so
we
don't.
We
don't,
because
of
the
way
that
we
use
just
the
value
as
it
currently
is.
We
don't
get
that
kind
of
recursive
issue,
but
my
main
issue
is
this:
doesn't
do
what
the
user
expects?
It
definitely
feels
to
me
like
a
bug.
It
feels
like
a
bug
in
the
spec.
F
F
F
Another
thing
to
note
about
it
is:
I
think
it
would
make
sense
to
users
if
you
set
the
default
to
be
an
empty
object,
that
it
shows
up
in
introspection
as
an
empty
object
and
doesn't
show
up
in
introspection
as
being,
for
example,
an
object
with
the
number
equals
three
inside
of
it.
So
that's
that's
broadly
what
what
we're
talking
about
here?
F
There
is
complexity
here
so
yeah
I
have
a
proposal.
What
do
you
think.
C
I
agree
that
this
is
problematic.
I
don't
know
if
I
agree
yet,
but
this
is
the
right
way
to
solve
it,
but
this
doesn't
seem
quite
right.
So
part
of
the
reason.
There
are
a
couple
of
reasons
why
default
values
did
not
go
through
coercion
and
in
fact
we
had
like
a
pretty
major
overhaul
of
the
default
value
system.
I
think
two
years
ago
I
remember
right
that
that
introduced
the
ability
to
kind
of
even
create
this
pattern,
and
one
was
we
wanted
to
make
sure
that
they
were
statically
knowable.
C
So
you
you
did
not
have
to
actually
perform
an
execution
in
order
to
know
what
the
default
values
are
going
to
be
within
a
query.
The
other-
and
I
think
yvonne
mentioned
this
on
the
thread-
was
that
you
should
be
able
to
read
the
query
right,
queries
or
sorry.
Schema
schemas
are
written
to
be
read,
and
if
you
see
that
default
value
and
it
looks
like
an
empty
object,
then
you
might
be
confused
when
you
find
on
the
other
side.
C
In
fact,
it
was
not
an
empty
object,
but
a
an
object
that
had
a
number
field
in
it,
because
the
type
of
that
thing
had
a
default
now,
there's
definitely
a
twist
here,
which
is
either.
That
means
that
we
have
to
repeat
ourselves,
we'll
pretend
it
means
that
we
have
to
kind
of
leave
this
or
follow
something
that
that
you've
proposed
right.
So
an
alternate
proposal
here
would
be.
C
There
is
a
step
you
mentioned.
Maybe
you
could
just
pass
it
straight
up
the
number
seven
and
that's
what
you
would
get
you
can't
do
that,
because
there
is
a
validation
rule
that
says
the
default
value
must
be
a
valid
value
of
the
type
and
seven
is
not
a
valid
example.
Input
object
in
this
particular
case.
C
The
empty
object
is
passing
as
that,
because
this
number
field
has
a
default
and
therefore
it's
not
required
to
be
passed,
and
so
this
is
certainly
a
bug
where,
in
this
particular
case,
it's
deemed
as
a
valid
type,
even
though
this
particular
case
is
not
being
coarsed,
and
so
it's
missing
a
step
with
that
said,
you
look
at
this.
You
know
maybe
another
way
you
could
get
around
this
to
say:
there's
a
there's,
a
different
kind
of
validation
that
we
do
specifically
for
this.
C
These
default
values,
and
that
requires
that
all
values
that
are
required
are
provided,
regardless
of
whether
or
not
they
contain
default
values,
essentially
requiring
manual
coercion
at
the
schema
right
time.
Downside
of
that
would
be,
you
know.
Imagine
you
have
three
examples
that
all
use
example
input
object.
All
three
of
them
say:
there's
a
number
colon
three
in
there
because
that's
the
default
and
then
later
someone
decides.
Oh
actually
the
default
shouldn't
be
three,
the
default
should
be
thirty,
and
then
they
forget
to
update
the
other
one.
C
F
So
I
wanted
to
to
comment
on
what
you
said
about
seeing
what
the
the
default
would
be
from
a
user
expectation
point
of
view
you
mentioned.
If
you
see
that
the
the
object
is
an
empty
object,
it
would
potentially
be
confusing
if
it
were
then
to
actually
be
an
object.
F
That
has
the
number
three
in
it
I'd
like
to
challenge
that
to
start
with,
so
I
don't
think
it
would
be
confusing
because
it
it's
effectively
saying
if
you
don't
specify
this,
it
is
the
same
as
if
you
were
to
type
empty
object
and
that's
what
I
would
expect
from
a
default
value,
and
that
is
what
it
is
doing.
F
I
don't
think
it
is
necessary
for
it
to
have
all
those
extra
things
in,
and
I
think
that
actually
having
those
extra
things
in
may
be
more
confusing,
depending
on
how
deep
it
goes
because
they're
like
well,
why
has
it
got
all
these
things
in
there
and
also
what
happens
if
I
then
specify
it,
but
I
only
give
it
one
of
those
properties
or
those
other
two
properties
still
there
or
not.
F
The
fact
that
it
can
default
to
something
that
is
different
from
the
defaults
of
the
children
is
desirable,
but
we
want
to
make
that
explicit.
The
other
thing
is
this
seems
to
be
a
tooling
issue.
F
So
even
if
introspection
says,
the
default
of
this
is
an
empty
object,
tooling
can
still
say,
but
the
resolved
value
of
it
would
be
an
object
with
number
three
and
I
think,
that's
perfectly
valid,
and
I
think
it's
actually
what
graphical
does
currently,
because
I
have
set
the
the
default
value
to
be
the
empty
object
and
in
graphical
it
still
shows
up
as
value
with
number
three.
So
I'm
not
sure
if
I
did
something
wrong
or
whether
that
is
the
case
but
yeah
that
that's.
F
That
seems
like
that's
a
issue
beyond
the
actual
introspection
itself.
That's
a
display
issue.
So,
to
my
mind,
we
should
make
it
do
what
people
would
expect
it
to
do.
If
you
just
passed
in
an
empty
object,
it
should
be
the
same
as
the
user
typing.
An
empty
object.
C
That
mental
model
makes
a
lot
of
sense
to
me
that
if
you,
if
you
type
this
in
that,
you
will
get
exactly
the
same
behavior
as
the
default
value.
If
you
copied
that
default
value
and
put
it
into
your
query,
you
should
get
exactly
the
same
thing
where
right
now,
you
clearly
are
not,
and
so
that's
obviously
an
issue.
E
I
have
some
thoughts
and,
like
obviously
it's
an
issue
because
number
as
typed
in
the
schema
provided,
is
non-nullable
and
clearly
like
at
runtime
at
execution
time.
It
ends
up
null.
So
very
clearly,
something
is
broken
like
the
client
has
overridden
the
server
contract
in
or
like
the
server
in
client.
Handshake
is
broken,
so
that
seems
obvious
we
like
that
needs
to
be
fixed.
E
I
also
think
the
idea
that
an
empty
input
object
means
that
the
fields
provided
have
a
default
does
make
sense
because,
like
we
need
a
way
for
you
to
specify
some
fields,
but
then
say
I
server
can
decide
the
rest
and,
like
you
need
a
way
for
that.
To
always
be
true.
E
M
I
I
C
K
F
In
the
meantime,
I
think
that
this
is
a
non-breaking
change,
because,
as
you
say,
lee
we
have
to
have
already
put
those
values
in
place
for
the
schemas
to
currently
be
valid,
those
default
values
so
keeping
those
existing
ones.
This
shouldn't
change
that
because
they
should
still
coerce
the
same.
So
I
think
it's
a
non-breaking
change.
C
Yvonne
you
mentioned
in
the
thread
here
that
you
have
some
concerns
with
this.
Do
you
want
to
talk
through
those.
K
K
If
I
remember
correctly,
I
need
to
check
it,
but
if
I
remember
correctly
in
spec
we
don't
care
default
values
of
query
variables
so
and
if
so,
we
cannot
change
with
behavior
and
what
sense
like.
We
already
have
two
types
of
default:
oh,
like
we
already
have
like
different
so
like.
If
we
don't
care,
query
variables,
default
values,
but
requires
default
values
of
execute
of
sdl
inside
the
yield.
So
I
think
it
will
it's
not,
and
we
cannot
change
coercion
of
query
variables.
It
seems
to
be
research,
I'm
not
sure
about
that.
F
We
we
do,
though,
this
this
query.
For
example,
I'm
not
sure
you
can
see
it,
but
query
d
in
the
in
the
issue.
793
is
the
it's
the
pull
request
against
the
the
graphql
spec.
F
K
Yeah,
like,
as
you
point
out
in
my
research
in
graphql.js,
we
I
think
we
do
that,
but
in
spec
we
don't
do
it.
If
I
I
need
to
check
like
but
stuff
that
I'm
totally
sure
about
as
a
potential
problem
is
that
cash
on
rules
for
scours,
so
we're
discussing
most
recursion
rules
for
objects
so
like
adding
default
values.
But
there
is
like
two
other
type
of
question
rules.
K
We
have
a
rules
for
arrays
converting
one
element
to
array
which
is
not
problematic
but
what's
problematic
is
cushion
rules
for
standard
scours,
north
center
for
scours
and
the
implementation
defined.
K
K
So
it's
recommendations
required
in
that
sense,
by
applying
correction
rules
to
default
values
so
like
if
we
send
through,
if
through
introspection,
if
we
send
non-cursed
values
that
is
expect
to
be
coerced
during
execution,
it's
mean
like
server,
a
client
whose
ability
to
to
like
expand
with
value
on
a
client
because
for
expanding
scours
you
need
to
have
like
scholar
implementation,
but
if
we
so,
I
think,
like
there
is
two
issues
in
one
pr's
and
whispering.
K
We
can
handle
them
separately
and
one
thing
is
that
value
is
not
validated
at
all
and
it's
like
really
bad
and
second
thing
is
like
correction,
I'm
like
totally
for
validating.
I
think
if
like
if
we
expect,
I
don't
know.
If
we
expect
this
string,
can
somebody
pass
number
we
forbid
for
for
strings
color
with
four
bit
correction
from
number
to
string,
but
like
technically,
according
to
spec,
you
can
write
it
this
year.
K
J
Can
you
hear
me
no
better?
Okay,
I
just
want
to
say
it's
definitely
a
problematic
area,
and
I
agree
we
have
to
do
something
about
it.
I
think
crafty
java
doesn't
implement
it
exactly
in
the
way
as
craft
beer
gestures.
J
So
it's
it's
just
in
general,
not
easy
to
implement
correctly
and
to
implement
it
even
the
same
way.
I
I'm
not
sure
about
the
consequences
of
what
benji
proposes
so
far
because
yeah
first,
I
need
to
do
more
homework
and
to
read
more
stuff
up
for
myself,
but
also
just
a
general
comment.
What
I,
what
I
don't
really
like
is
the
implicit
nature
of
the
default
values,
kind
of
creeping
up
to
you.
You
define
an
empty
thing
and
then
suddenly
there's
a
default
volume
in
it
defined
totally
somewhere
else.
J
It
kind
of
breaks
a
little
bit
the
mental,
the
boring
mental
model,
the
good
and
boring
mental
model
of
craft
girl
that
you
kind
of
just
read
it
and
know.
What's
going
on,
we
are
very
explicit
with
interfaces
implementing
interfaces,
for
example,
where
we
prefer
repetition
over
kind
of
schema.
J
J
To
be
honest,
because
repeating
everywhere
is
this
also
comes
with
problems,
as
lee
pointed
out
and
and
benji
pointed
out
so
yeah
something
we
have
to
continue
thinking
about,
specifically
the
the
default
value
for
custom
scalars
is
is
problematic,
like
I
pasted
the
example
into
the
chat,
if
you
have
a
custom
scalar
a
complex
custom
scalar
like
json
like
basically
an
type
system
escape
hatch
right,
it
can
be
any
literal
and
what
it
does
and
what
it
means
to
the
scalar
is
totally
up
to
the
implementation.
J
So
there's
not
really
like
a
general
coercion
rule.
You
can
apply
to
this,
so
yeah,
not
really
a
solution,
but
more
problems.
Maybe.
C
Yeah,
that's
a
good
point.
I
I
do
think
it's
part
of
why
my
intuition
was
to
go
towards
repetition
is
thinking
back
to
those
previous
cases.
There
is
a
meaningful
difference
here,
though,
that
with
the
interfaces
implementing
interfaces,
we
preferred
repetition
because
it
made
things
easier
to
read
and
validation
made.
It
made
it
so
that
we
didn't
have
the
maintenance
problem.
If
you
made
a
mistake,
validation,
schema
validation
would
fail
and
it
it
would
make
it
pretty
obvious
that
you
had
to
complete
that
migration,
but
for
default
values.
C
It's
it's
not
it's
like
there.
There
could
be
a
meaningful
difference
if
your
local
default
is
a
different
value.
Maybe
that
was
intentional.
Maybe
that
was
different
and
we
have
to
leave
space
for
that
and
repetition
makes
that
possibility
go
away.
Matt.
Do
you
want
to
say
more
about
this
devex
issue
that
you
mentioned
in
the
shot.
E
Yeah,
so
thinking
through
this,
this
is
actually
like.
I
know
at
least
from
what
I
understand.
We
almost
never
use
schema
level
default
variables
or
default
values,
and
primarily
we
do
that
because
well
like
the
actual
definition
like
the
actual
code
on
the
server,
can
decide
what
the
default
is
and
can
modify
it
if
you
just
pass
in
a
null
right,
so
it
from
a
devex
standpoint
like
the.
E
If
the
server
schema
for
that
argument
has
defined
a
default
value
of
three
and
I
pass
in
null,
I
want
that
to
end
up
being
that
server.
I
want
it
to
be
equivalent
probably
to
the
server
defined
default
of
three,
but
that
doesn't
happen
at
the
graphql
like
that
doesn't
get
resolved
at
the
graphql
level,
whereas
the
default
values
kind
of
assume
that
your
server
is
telling
you
what
the
default
will
be.
It's
not
a
breaking
change.
I
don't
believe
for
a
server
to
update
a
default
value.
E
Which
leads
to
kind
of
weird,
like
I
can't
say
sometimes
when
I
send
this
query,
I
want
to
use
the
server
graphql
defined
default
value,
and
sometimes
even
if
that
updates
in
the
future,
and
sometimes
I
want
to
specify
it
manually,
whereas
with
queries
with
query
defaults,
we
can
do
that
by
just
not
sending
like.
Oh,
I
just
don't
include
that
query
variable
in
when
I
send
it
to
the
server.
C
E
G
J
C
If
it's
optional,
you
can
leave
it
out,
and
the
two
ways
it
can
be
optional
is
if
it's
nullable,
in
which
case
it
just
defaults
to
null
or
if
it
has
a
default
value,
in
which
case
it
will
be
the
default
value.
E
J
If
the
variable
is
not
present,
then
the
default
value
of
this
variable
will
be
used.
Oh
okay,
but
I
think
this
discussion
between
us
already
shows
that
this
is
highly
non-trivial
like
if
we
have
problems
in
our
model
in
our
head
to
to
come
up
with
solutions
like,
I
don't
want
to
think
about
people
who
don't
spend
so
much
time
with
kraftwerk,
so
yeah
yeah,
like
one
fundamental
goal,
regardless
of
what
we
do
should
be
like
simplifying
or
not
and
not
maximizing.
J
Confusion
like
this
should
be
like
some,
some,
some
secondary
or
like
primary
goal
of
whatever
we
do
at
the
moment,
because
it's
really
complicated,
as
we
just
found
out.
F
That
that
was
actually
very
much
one
of
my
goals
of
this
was
to
make
the
simplest
solution
that
I
could,
which
is
why
I've
not
written
anything
about
memorization
actually
into
the
spec
and
I've
just
basically
copied
the
the
same
coercion
algorithm
that
you
already
have
for
values
here
and
just
applied
it
to
default
values
here.
So
it
is
very
straightforward
to
do
it.
F
If
you
were
to
do
it
this
way
in
in
execution,
then
you
wouldn't
be
getting
the
performance
that
you
could,
if
you
were
to
memoize,
but
the
actual
spec
doesn't
really
care
about
that.
So
I
think
very
much
simplicity
is
a
goal
of
this,
and,
and
you
can
see,
the
number
of
changes
in
the
in
this
rfc
are
quite
small.
C
There's
there's
two
different
algorithms,
one
for
coursing
argument,
values
and
one
for
coercing
variable
values,
they're
very
similar.
They
have
notes
below
each
of
them
that
cross-link,
because
they
are
similar,
but
they
are.
C
There
are
distinct
differences
just
because
of
the
presence
of
an
argument,
kind
of
changes
things
I
I'm
pretty
sure
your
your
change
only
changes
the
coercion
of
variable
values,
because
that's
where
this
issue
presented
itself,
but
I
feel
like
we
should
double
check
that
there
isn't
issues
across
both
algorithms,
because
both
of
them
end
up
managing
the
the
relationship
between
provided
values
and
default
values.
F
Oh,
your,
your
pull
request
does
yeah.
I've
certainly
got
changes
in
the
coerce
argument,
values
algorithm.
So
I
think
so.
C
Cool
seems
like
this
is
probably
the
right
path
forward.
It's.
We
should
kind
of
consider
this
a
important
problem
to
solve
relatively
quickly,
for
the
reason
that
matt
pointed
out,
which
is
this,
essentially
breaks
the
contract
between
client
and
server
in
a
way,
that's
potentially
a
security
issue,
not
the
things
that
can
get
leaked.
C
And
if
your
server
doesn't
handle
npe
as
well,
then
you
could
like
create
a
load
issue
or
create
an
outage
issue.
So
this
seems
like
an
important
thing,
at
least
for
folks,
to
go
like
gut
check
that
this
is
not
an
actual
volume
for
your
servers
that
can
take
things
down,
but
at
least
theoretically
it
seems
like
it
could
be,
and
therefore
it
should
be
reasonably
high
priority
that
we
come
up
with
with
a
fix.
C
My
suggestion
for
next
steps
is
to
to
actually
write
this
into
some
of
the
implementations.
It
seems,
like
andy,
has
an
idea
of
where
this
might
land
within
graphql.js,
maybe
yvonne.
You
can
take
a
look
at
this
on
the
js
side
matt.
C
You
might
want
to
take
a
look
at
this
in
the
internal
facebook
server
just
to
see
kind
of
like
if
these
behaviors
are
are
spec
compliant
and
exhibit
this
bug
or
if
they
are
not,
and
there
already
seems
to
be
kind
of
quirkiness
with
the
example
that
you
provided
benji
in
the
query
d
in
your
write
up
actually
seems
like
it's
not
behaving
the
way
that,
like
the
way
the
spec
is
written,
it
sounds
like
that
one
should
actually
be
returning
in
the
whole
or
maybe
I'm
just
kind
of
misunderstanding.
C
C
F
C
It
means
that
in
one
case,
there's
an
issue
with
the
spec,
if
not
both
cases
and
there's
also
a
incompatibility
between
spec
and
reference
implementation.
C
So
I
my
sense
is
the
next
step
here
is:
is
to
get
a
at
least
a
graphical
js,
pull
request
up
that
illustrates
this
and
then
probably
also
making
it
making
it
clear
that
we
can.
We
can
avoid
the
recursion
problem
that
you
framed
up.
I
don't
know
that
I
totally
understand
the
recursion
problem.
Quite
yet,
maybe
a
reference
implementation
and
a
test
will
help
us
tease
out
potential
recursion
issues.
K
K
So,
right
now,
validation
rule
is
to
stop
recursion
rules,
so
we
don't
have
like
validation
rules.
We
have
like
only
coercion.
So
when
we
check
every
value
in
inquiry,
we
check
that
it's
chiros
or
something
we
don't
check.
It's
like
validate
and
it's
for
every
literal.
K
K
So
what
what
is
I'm
not
sure-
but
I
think,
like
one
thing
we
can
do-
is
to
clarify
as
much
as
possible
stuff
like
without
any
feature
that
we
don't
sure
about,
like
version
like
like,
maybe
for
next
next
time,
I
will
work
on
like
alternative
proposal
to
just
add
validation,
just
without
conversion,
and
we
will
see
what
how
it's
implemented
on
graphql,
js
and
what's
simpler
and
how
it's
affected
back.
F
So
so
one
potential
like
it
doesn't,
it
doesn't
fix
the
the
mismatch
of
expectations,
which
is
what
I
think
the
biggest
issue
for
me
with
this
is,
but
one
potential
way
to
solve.
This
is
with
a
schema,
validation
rule
that
is
a
bit
deeper
than
our
current
one.
As
you
say,
it
currently
says
that
it
must
be
coercible
to
the
value,
but
that's
not
enough.
F
I
want
to
write
this
parameter
would
be
the
same
as
passing
an
empty
object,
because
that's
what
I
want
it
to
be
the
same.
As
for
the
user,
I've
got
my
default
values
elsewhere.
I
don't
care
so
much
about
those
like
graphql
should
handle
that
for
me.
So
that's
how
I
feel
about
it.
J
Like
a
related
question,
what
does
the
introspection
return
as
default
value
for
the
argument
here?
Is
this?
Did
anyone
look
into
this.
F
Yeah
it
it
for
what
I've
got
here.
It
returns,
I
believe
the
empty
object,
which
is
what.
F
Really
I
mean
it's
an
invalid:
this
isn't
really
a
valid
schema,
it's
how
we
define
schemas
at
the
moment.
This
is
not
a
valid
schema,
because
the
default
value
doesn't
get
coerced
so
technically
the
default
value
should
have
an
object
with
number
colon
3
as
the
default
value,
and
it's
up
to
the
schema
writer
to
make
sure
that
that
is
the
case,
but
that
introspection
returns
for
default
value.
What
you
have
said
is
the
default
value
to
me
is
the
correct
behavior.
C
C
F
Schema
actually
started
writing
up
an
implementation
of
this
and
then
stopped
because
I
realized
it
was
a
bit
more
complex
and
we
couldn't
just
store
the
the
coerced
value.
One
reason
is,
you
would
want
the
so
in
graphql
js,
where
you
can
get
the
the
like
the
schema
definition
from
the
api.
F
You
would
want
that
to
come
back
out
as
what
you
fed
in
so
you'd
want
to
get
that
empty
object
back
out
again
and
if
we
do
the
coercion
and
we
store
that
and
that's
what
comes
out
of
introspection,
then
the
description
of
the
api
wouldn't
be
the
same
as
what
we
fed
in
effectively.
I'd
want
the
same
out
of
the
sdl
that
describes
the
schema
as
what
I
wrote
in
as
the
sdl
that
describes
the
schema.
J
I
think
this
not
directly
related
to
this,
but
I
think
this
is
a
fundamental
problem
of
how
introspection
default
values
are
defined.
I
think
introspection
default
values
are
just
a
string
and-
and
you
actually
define
here
and
in
not
a
string
value
in
ast
value
like
it's
like
an
ast
literal,
so
you
already
always
have
some
kind
of
conversion
happening
here,
which
is
especially
relevant
for
custom
scalers,
where
you
can
have
like
very
complex
ast
literals
and
you
kind
of
need
to
convert
it
to
string.
J
The
this
is
actually
an
open
issue
in
graphical
java
and
crafter.js
that
you
actually
need
and
want
the
additional
coercion
method
to
do
this
conversion,
because
you
don't
have
at
runtime,
you
can
have
a
schema
which
is
not
defined
at
all
as
scl
as
evan
said,
so
you
have
to
have
kind
of
a
method
to
convert
a
default
value
which
is
not
at
all
represented
in
sdl
back
into
a
string
like
this,
I
I
copied
the
craftwear.js
issue,
which
talks
about
converting
arbitrary
scalia
values
into
asds
and
back.
J
C
Yeah,
ideally,
all
defaults
can
be
represented
in
both,
but
defining
it
first
in
the
native
environment
and
then
backtracking
to
graphical
literals
is
not
always
straightforward,
but
I
I
do
think
it's
a
slightly
separate
problem.
C
Okay,
I
I
think
we
can
move
on
it's
clear
that
we
want
to
fix
this.
I
marked
it
as
as
stage
one
on
this
proposal,
because
this
proposed
direction
seems
directionally
like
what
we
think
is
the
right
thing,
and
we
need
to
kind
of
implement
it
to
double
check
that
we've
we've
covered.
All
the
bases
we
want
to
cover
seems
like
we
have,
but
we
might
find
some
extra
iteration
there
before
we
get
to
stage
two,
but
let's
make
this
one
a
priority
and
fix.
It
seems
like
a
real
concerning
issue.
F
Yeah
no
worries,
I
I
think
there
might
be
a
bit
of
a
gap
in
validation
in
the
spec
as
it
currently
stands
so
lee.
If
I
could
borrow
a
bit
of
your
time
and
pick
your
brains
about
it
later
at
some
point
when
it
was
convenient.
That
would
be
very
helpful
for
sure
awesome.
C
Okay,
next
up,
we
have
action
item
review
benji.
You
had
some
thoughts
on
how
we
would
lead
this
so
I'll.
Actually,
let
you
take
a
first
cut
through
these
before.
K
That
I
submitted
pr
to
add
like
item
to
agenda,
it's
a
quick
item
and
it's
actually
helpful
this
one
so
yeah.
So
I
think,
like
two
years
ago,
community
member
proposed
to
limit
purpose
to
limit
recursion
on
input
types
and
we
agree
with
it.
The
only
objection
was
from
from
james
because
he
was
concerned
that
we
not
a
war
in
circular
circle.
K
So
I
suggest,
like
just
measure,
measured
since
it's
already
here
for
us,
it's
kind
of
related
to
to
like
we
think
about
conversion,
because
if
we
so
right
now
default
values
use
as
is,
and
there
is
no
excursion.
But
if
we
start
conversion
stuff
like
I'm
like
I'm
personally
for
writing
correction
algorithm
because
right
now
we
don't
have
it
and
we
have
a
corrosion
algorithm,
which
we
use
default
values
only
one
layer.
K
F
If
we
can't
do
recursive
input
objects,
then
this
the
pr
that
I've
got
open,
I
think,
is
ready
to
go
so
yeah.
That
would
be
welcome,
but
that
would
also
be,
I
think,
a
breaking
change
right
currently
valid
schemas
would
become
invalid
if
they
use
recursive
defaults
on
input,
object
fields,
this
pr
doesn't
the
way
I've
thought
about
it
is
this
shouldn't.
It
doesn't
require
that,
because
effectively
we
would
handle
it
in
the
same
way
that
we
would
a
runtime
error.
F
K
Yeah
one
thing
to
clarify
it's
already
much
in
the
reference
implementation
and
I
think
other
implementation
implemented
it
and
there
is
no
like
a
position.
So
we,
the
fact,
already
did
the
breaking
change
and
if
you
use
json,
this
value
is
impossible
to
pass.
It's
mean
like
we.
The
only
thing
we
can
potentially
break
is
like
formats
that
support
like
circular
circle
or.
K
C
Yep,
I
think
this
I
was
looking
back
on
that
one
thanks
for
sharing
the
link
yvonne.
This
is
one
that
we
had
approved,
but
we
wanted
to
have
a
waiting
period
before
we
merged
it
in
so,
but
you're
right
that
waiting
period.
C
We
should
consider
up
and
and
close
this
one
out-
I
it
it
does
seem
like
we
want
to
be
like
extra
careful,
especially
when
working
out
the
reference
implementation
of
what
benji
is
proposing,
just
to
make
sure
that
there
aren't
cases
where
there's
like
nested
default
objects
that
either
aren't
being
resolved
correctly
or
or
result
in
infinite
recursion.
C
F
Sorry,
just
finishing
the
notes:
okay,
so
I'll
share
my
show
my
firefox
again.
F
Yeah
cool
okay,
so
we
have
some
boards
from
various
working
groups
from
the
past,
so
I'm
gonna
start
at
the
oldest
one,
and
I
think
we
can
close
a
few
of
these.
So
we
have
an
issue
from
the
middle
of
last
year
saying
schedule
a
graphql.org
meeting,
there's
been
epic
progress
on
graphgial.org
recently,
so
I
think
this
is
no
longer
relevant.
F
Then
there
is
writing
up
her
vision
for
the
code
page.
Equally,
there
has
been
epic
progress
on
the
code
page
and
I
want
to
say
brilliant
progress.
Everyone
who's
been
working
on
the
graphql.org
and
the
code
page.
I
have
seen
so
much
activity
around
that
it's
been
really
really
really
cool
to
see
so
fantastic
work,
everyone-
and
I
think
that
means
that
this
is
also
no
longer
relevant,
agreed
awesome.
F
F
All
right
so
then
we're
on
to
may
of
this
year.
I've
got
two
here
that
are
ready
for
review,
so
update
the
input
union
rfc
after
recent
subcommittee
meetings.
We
did
that
I've
added
the
solution.
Seven,
there
is
probably
still
some
notes
in
this
issue
itself,
this
actual
working
group
issue
that
has
more
notes
on
that,
but
I
think
we're
probably
as
far
as
we're
going
to
get
on
that.
So
I
suggest
we
close
it.
C
F
Okay,
we
also
had
add
input
union
solution
criteria
that
error
messages
are
well
specified
and
I'm
gonna
check
that,
but
I
think
we
I
think
we
did,
that
we
have
that
there
we
go
yeah.
It
was
this
pull
request
15
days
ago,
so
I
think
that
is
again
good
to
be
closed.
F
F
C
I
think
we
can
close
this
one
out
the
we
filed
this
one
because
we
started
having
discussion
about
graphql
scalars
realized
that
that
particular
meeting
andy
wasn't
able
to
join
and
wanted
to
follow
up.
So
I
think
this
one
and.
J
We
had
a
specific
meeting
as
a
follower.
F
L
F
F
J
H
F
I
think
yuri
thinks
that
this
is
ready
to
be
closed.
I
don't
know
what
anyone
else
thinks
about
this,
whether
it's
done
or.
K
K
C
I
would
suggest
closing
this
and
and
in
the
future,
reopen
something
with
something
more
specific,
because
I'm
also
I'm
I'm
dubious
of
separate
repos
for
every
subcommittee
being
the
right
thing
that
we
might
want
to
just
create
a
directory
structure
in
the
main
wg
repo,
so
that
if
people
show
up
here,
they
can
find
all
of
the
various
subcommittees
that
we
have
going
on
for
js
for
http.
There's
like
there's
a
bunch
of
stuff
that
we're
doing
it'd
be
a
nice
thing
to
have
one
place
that
you
can
find
them
all.
K
C
K
C
F
Cool
to
organize
the
the
collaboration
on
typescript
migration
of
graphql.js,
I
see
there's
been
quite
a
lot
of
discussion
ivan
on
that.
Are
you
happy
that
this
one's
been
addressed
now
so.
K
It's
like
woody,
we
like
raise
this
question
and
we
discuss
it
so
right
now.
Two
things
happen.
So
we
have
like
actual
plan,
updated,
pawn
suppressor.
We
have
like
one,
but
we
failed
to
execute
typhoid,
execute.
K
F
F
Yeah
I
I
asked
for
people
to
review
the
query:
ambiguity,
pull
request.
They
have
done
so.
There
has
been
plenty
of
feedback,
so
I
think
this
one
is
done
still
needs
work
done
on
the
query.
Ambiguity
pull
request,
but
that's
on
me,
but
this
particular
issue
I
think,
has
been
dealt
with.
So
I'm
going
to
go
ahead
and
close
that.
E
F
And
this
we've
already
discussed
this
working
group
was
the
dunder
type
name
on
the
subscription
route.
So
I
have
written
the
pr
spec
and
raised
a
pull
request
to
graphql
js,
but
I
need
to
talk
to
ivana
about
that,
but
anyway,
I
believe
that
this
is
also
closable.
F
F
C
K
Yeah
and
so
basically
it
was
a
champion
for
this
proposal,
but
he
disappeared
and
stopped
responding.
Quite
so,
we
decided
to
adopt
pr
and
before
with
working
group,
I
actually
create
a
branch
and
create
pr
against
okay
spike
and,
as
for
graphql
js
changes,
it's
already
machine.
K
There
is
like
some
some
issues
like,
I
think,
javascript
specific
issues
with
this
feature,
but
it's
merged
and
it's
released
and
like
yeah,
and
so
there
is
a
separate
issue
about
updating
a
text,
and
I
still
need
to
call
this,
but
this
one's.
I
think
it's
ready
to
close
okay,
cool
I'll
close.
That
then.
F
So
that's
it
all
of
our
ready
to
review
actions
have
been
dealt
with,
so
we
do
have
still
23
open
action
items,
but
that
now
fits
on
one
page
of
github.
So
I'm
gonna
call
that
a
victory.
C
F
Did
we
talk
about
scheduling,
an
input
union
working
group,
or
do
we
want
to
do
that
as
a
separate
offline
task?
If
so,
slack
may
I
suggest.
K
Another
organizational
issue:
we
need
to
change
the
password
for
this
meeting
to
something
with
numbers
and
like
special
symbol.
So
a
problem
here
is
that
so
previously
we
used
graphql
and
we
still
use
graphql
working
group,
vg
wg,
but
recordings,
and
previously
it
was
the
same
password
for
recordings.
K
So
but
zoom
changer
rules
and
our
password
for
meeting
doesn't
satisfy
them,
but
they
applied
it.
Only
on
recordings,
let's
mean
like
when
recordings,
when
you
try
to
access
recordings,
zoom
use
like
random
generate
password,
so
we
need
to
either
make
it
remove
password
from
recording
in
general,
or
we
need
to
update
our
password
to
satisfy
zoom
rules.
C
All
right,
let
me
let's
take
that
to
brian,
since
he
manages
the
zoom
account
for
us
and
I'm
sure
he'll
be
able
to
that
way.
He
can
also
make
sure
that
it's
represented
correctly
on
all
the
meeting
invites
and
stuff.
C
I
L
I
Jump
back
like
a
minute,
but
we
seem
to
have
a
little
bit
of
time
just
going
back
to
the
schema
thing
just
for
like
one
second,
what
what
are
the
I
was
slightly
unclear.
Sorry,
I
forgot
to
mention
like
who
who
would
be
like
dissenting
opinions
like
who
do
I
wondering
how,
like
I
move
forward,
basically
like
who
do
I
need
to
reach
out
to.
C
I
think
we've
got
good
notes
there
and
then
I
think
it's
pretty
much
just
the
folks
that
are
already
on
that
discussion
thread
and
and
we
need
to
tease
out
the
there
was
some
discussion
about
like
how
to
set
this
up
for
good
extension
and
we'll
just
crisp
up
exactly
what
variant
we
want
to
roll
with.
But
I
I
suspect
we
can
do
that
offline
all
right.
Well,
I'll.
Just
continue
with
that.
Then
all
right
thanks.
A
G
G
F
Some
of
them
are
like
effectively
assigned
to
everyone
so
like
looking
over
spec
pull
request,
for
example.
Normally
we
need
like
as
many
people
as
possible
to
look
at
those
and
see
what
the
issues
are,
so
those
don't
tend
to
get
assigned
to
specific
people.
I'm
not
sure
if
there's
a
good
way
of
addressing
that,
it
might
be
that
maybe
when
we
say
that
this
needs
review,
we
take
a
poll
like
hands
up
in
the
call
and
actually
put
those
specific
people
on
as
assignees.
F
But
I
think
we
also
want
people
who
aren't
here
at
the
cool
to
do
these
reviews
as
well.
So
I'm
I'm
worried
that
I
don't.
I
don't
want
it
to
be
like
exclusionary
from
that
regard,
so
I
think
it's
acceptable
to
have
them
without
without
people
assigned,
but
I
do
think
that
they
probably
shouldn't
be
around
for
too
long.
C
C
Some
of
these
are
also
tactical,
and
we
can
probably
assign
to
brian.
F
Cool,
I
also
closed
one
of
the
other
projects
after
I
stopped
sharing
because
it
turns
out
we'd
finished
that
one
as
well
so
we're
down
to
one
fewer
project
as
well,
which
I
think,
how
do
you
feel
about
the
the
project
system
for
managing
these?
I
felt,
like
it
kind
of
groups
them
together
by
age
quite
nicely.
F
G
It's
a
it's
a
project
setting
in
github
that
you
can
set
the
project
to
track
track
completion
status,
I'm
just
like
I'm
surprised
they
didn't
default
to
all
the
same
thing
if
nobody's
setting
that
on
purpose.
C
It
is
nice
to
have
them
kind
of
grouped
like
that
and
see
see
progress
because
sometimes
it
takes
a
while
for
the
actions
that
pop
up
in
a
meeting
to
reasonably
be
completed.
They're
like
long
review
cycles
or
follow-ups
on
rfcs
and
it's
nice
to
be
able
to
track
how
far
of
the
how
many
of
those
have
actually
made
it
through
and
how
much
is
left.
F
Yeah,
well,
it's
good
to
know
that
our
oldest
task
at
the
moment
is
from
the
may
working
group,
which
you
know
it's
only
what
seven
months
ago,
so
not
too
bad.
C
C
F
I
agree,
I
think,
if
we,
if
there's
no
response
by
next
working
group,
we
should
close
it
in
the
next
working
group.
C
All
right
well
with
that
I'll
call
the
meeting
to
a
close
thanks
everybody
for
sticking
through
all
the
meetings
this
year,
we've
made
a
ton
of
progress,
despite
the
world
being
on
fire
around
us.
So
I'll
see
you
all
in
the
next
working
group
of
of
next.