►
From YouTube: GraphQL Working Group - 2022-08-04
Description
GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools. Get Started Here: https://graphql.org/
B
C
D
C
C
Yeah
and
lots
of
people
attending
and
then
see
ya.
C
A
A
Almost
at
the
weekend
is
everybody
been
getting
some
time
off
over
the
summer
I'm
off
next
week.
Oh.
A
Nice
yeah
wow
was
it,
was
it
super
busy
or
was
it
not
too
bad.
E
Not
too
bad
they've
been,
you
have
to
get
a
reservation
to
drive
into
the
Park
yeah,
which
is
nice,
so
they're
they're,
actually
very
little
traffic.
Oh
that's.
E
It
was
going
to
be
a
bit
of
a
game
time
call
I
had
my
my
eye
on
the
purple
air
app.
That
shows
you
all
the
like
air
quality
index
across
the
map,
and
it
was
actually
not
that
bad.
It
was
like
just
Smoky
enough
that
you
got
kind
of
the
crazy
sunset
colors,
but
like
oh
wow
enough,
that
it
was
bothersome,
yeah,
wow.
F
F
D
A
C
G
D
C
Yeah
there
were
a
lot
of
pull
requests
with
failed,
so.
D
A
E
E
E
All
right,
I
just
merged
some
pull
requests
and
updated
our
attendee
list.
So
if
you
wouldn't
mind
doing
a
quick
reload
of
the
agenda
file,
if
you
got
it
open
and
then
we'll
get
things
rolling.
E
Awesome
all
right:
everybody
welcome
to
the
August
2022
edition
of
the
graphical
working
group
meeting,
of
course,
as
we
all
join.
That
means
that
we
are
in
agreement
with
the
spec
membership
agreement,
participation,
guidelines,
contribution
guide
and
code
of
conduct.
E
E
Okay,
as
we
like
to
do,
let's
start
off
with
a
quick
round
of
intros,
just
a
quick
name
to
face.
We
will
go
in
the
order
that
it
appears
in
the
agenda
file,
which
is
exactly
first
name,
Alpha
sort
this
time
it's
with
the
exception
of
me,
because
I'm,
the
one
who
talks
first
and
it
makes
it
easier
for
me
to
intro
first
so,
hello,
everyone,
my
name
is
Lee
the
here
representing
the
graphical
Foundation.
A
Hasn't
joined
yet
doesn't
look
like
it.
Perhaps
a.
E
I
A
Hi
all
Hugh
from
Apollo.
E
B
You
missed
me
because
I
failed
to
add
myself
on
time
to
the
invite
I'll
do
that
soon.
I'm
Gabriel,
McAdams
I'm,
currently
a
workday
but
not
representing
them,
representing
myself
and
I,
am
working
on
the
graphql
over
HTTP
spec.
E
Awesome
and
I
see
as
per
usual
Benji,
busily
filling
in
our
nymphs,
but
I
know
that
Benji
also
has
some
items
up
for
discussion.
So
could
anyone
be
willing
to
volunteer
to
help
take
notes?
E
Let's
take
a
quick
look
over
our
agenda,
as
is
becoming
typical.
We
have
a
packed
agenda
which
is
awesome,
I'll.
Do
a
quick
read
through
of
our
action
items
from
past
meetings,
although
I
don't
know
that
we
have
too
much
action
since
the
last
one.
After
the
last
meeting,
we
had
a
quick
discussion
about
overflow
or
changing
to
Cadence
I
opened
a
discussion
about
that
I'd
like
to
talk
about
a
proposal.
I.
Have
there
a
update
about
graphql
over
http,
a
parsing
stress
test
project
sounds
exciting.
E
E
Finally,
a
discussion
on
chapter
ordering
in
the
spec
I
suspect
that
we
might
not
get
through
all
of
this,
but
we
will
do
our
best
to
stay
on
time
and
try
to
get
through
all
of
it.
Anything
else
that
we
would
like
to
discuss.
That's
not
on
this
list,
or
does
anyone
want
to
propose
any
reordering.
H
E
H
E
We
have
a
okay,
I,
don't
know,
I,
don't
know
if
we've
ever
formalized
this,
but
we
ought
to
part
of
the
idea
with
mentioning
the
requested
time.
Slot
was
that
we
would
time
sort
the
agenda
so
that
shorter
topics
get
discussed
sooner
and
the
later
topics
fall
to
the
end
of
the
meeting
I'm
not
going
to
reorder
the
one
we
have
now,
but
we
might
wanna
do
better
at
being.
E
Yeah,
hopefully
it
makes
it
a
little
bit
more
fair
as
to
the
order
they
show
up,
but
we
might
be
able
to
get
to
everything
today,
let's
see
how
far
we
get
through
this
I'll
always
say,
comment.
F
One
of
the
other
things
is:
if
you
have
a
conflict,
for
example,
two
people
raise
items
at
the
at
the
same
time
or
similar
times
before
they
get
merged,
whichever
one
gets
merged.
First
ends
up
at
the
bottom.
Bizarrely,
when
you
click
the
resolve
wall
by
just
accepting
both
changes
and
I
tend
to
just
do
that
stuff
quickly,
just
click!
The
button
click
merge,
so
apologies.
If
that
does
change
the
order
of
things.
It's
just
faster.
E
Good
call
Roman,
yes,
we
will
do
a
break
yeah.
Let's
do
it
like
five
minutes
before
the
hour.
That
way,
we
can
have
a
well-known
time
to
get
started
again.
Thank
you
for
the
reminder.
Thank
you.
E
Okay,
let's
see
if
we
have
any
resolved
action
items
and
we
do
and
they're
both
opening
discussion
threads
Benji.
Anything
to
note
about
these
two
that
we've
got
marked
as
resolved
open
discussionings
for
strucks
in
the
discretion
thread
for
chapter
reordering.
E
Cool,
thank
you
for
keeping
an
eye
on
those
I'll
close
both
of
these
issues.
E
Apologies
I've
not
been
Super
Active
on
the
discussion
threads
over
the
last
month,
I
like
going
on
in
my
world,
so
I've
been
a
little
slow
but
much
appreciated
to
raise
those
so
there's
active
discussion,
okay
and
then
name
of
time.
I
won't
dig
through
the
other
two
links
right
now,
but
I
may
go,
take
a
look
at
them
later:
okay,
first
agenda
item,
and
ideally
there,
because
it
should
be
complete.
E
A
brief
discussion
is
meeting
times
in
Cadence,
so
I
know
in
over
the
last
couple
of
meetings,
we've
had
some
soft
discussion
about
wanting
to
consider
changing
the
meeting
times
for
some
a
retelling
of
the
history
of
this
meeting.
This
meeting
started
as
a
three
hour
long
meeting,
which
was
a
bit
grueling.
We
didn't
always
use
the
full
three
hours,
but
that
was
kind
of
the
thought
is
that
we
didn't
want
to
run
out
of
time.
E
So
it's
better
to
be
to
have
the
time
and
not
use
it
than
you
know
not
have
the
time
and
need
it,
but
as
Cadence
kicked
up,
we
actually
had
a
few
of
them.
That
did
go
long
and
in
particular
this
made
it
challenging
for
folks
who,
where
the
third
hour
was
really
late
into
the
night,
and
then
also
we
wanted
to
have
a
time
that
was
more
convenient
for
asia-pacific
time
zones
and
that
shifted
it
from
I.
E
Think
this
meeting
used
to
start
at
nine
if
I
remember
correctly
anyway,
we
shifted
it
to
11,
hoping
that
that
would
both
kind
of
make
it
not
too
terrible
for
the
end
of
the
night
for
folks
in
Europe,
but
also
early
enough
that
we
could
catch
some
of
the
Asia
Pacific
time
zone.
E
Now
that
we've
been
doing
this
for
it's
not
quite
a
full
year,
since
we
made
that
change
I.
My
sense
is
that
we've
kind
of
failed
on
both
marks,
although
I
don't
know,
are
European
attendees
are
still
here.
Thank
you,
but
I
know
it's
relatively
late.
In
the
evening
we
certainly
have
not
had
any
attendance
from
Asia
Pacific
I.
Think
part
of
the
diagnosis
there
was
we
made
this
change
in
the
middle
of
I,
can't
remember
where
you
call
it
in
daylight.
E
Savings
time
or
outside
of
daylight,
saying
sign
either
way,
whatever
the
time
zones
are
in
the
winter
and
because
of
how
northern
and
southern
hemisphere
shifts
work
like
the
the
combined
shift
is
like
two
hour
swing,
so
it
used
to
be
a
not
necessarily
convenient
but
doable
like
five
or
six
a.m.
Start
time
for
Asia
all
of
a
sudden
shifted
to
three
or
four
a.m
for
Asia
in
the
summer,
which
put
it
right
back
into
the
sort
of
non-viable
slide.
E
So
that
bit
of
context
of
what
led
to
the
last
change,
followed
by
a
recent
discussion
about
a
our
meetings,
have
been
going
way
too
long
and
we've
overflowed
and
lost
agenda
items
and
also
a
desire
to
kind
of
speed
up
the
Cadence
a
bit
like
we
actually
have
healthily
updates
faster
than
month
by
month,
which
is
great
to
see.
E
I
opened
discussion
shortly
after
that
last
or
last
meeting
last
month's
meeting,
with
a
couple
of
ideas
just
asking
for
everyone
to
kind
of
toss
in
their
mood
and
thank
you
to
Alex,
who
suggested
that
you
know.
Maybe
the
right
way
to
think
about
this
is
actually
increase
Cadence,
rather
than
just
changing
time
or
increase
or
adding
an
overflow
day,
and
that's
actually
where
the
majority
of
folks
preferred
so
I
want
to
kind
of
run
with
that
and
I
actually
have
a
proposal
here.
E
So
I
I,
just
added
this
at
the
beginning,
or
just
like
right
before
the
meeting
started
so
I'll
just
read
through
it
briefly.
But
the
idea
is
to
a
shift.
This
to
Wednesdays
I
saw
a
couple
of
comments,
I'm
curious
to
hear
from
folks
if
this
is
a
good
thing
or
a
bad
thing,
but
a
couple
of
comments
suggesting
that
if
we
had
had
an
overflow
time
that
we
would
want
to
ship
to
a
Wednesday
Thursday
rather
than
a
Thursday
Friday,
because
Friday
would
be
really
hard
for
folks
so
shifting
to
a
Wednesday.
E
Hopefully,
that
makes
timing
better
for
folks
and
doing
weekly
meetings,
but
alternating
between
what
would
be
West
Coast
U.S
mornings,
and
that
would
be
there
for
a
little
bit
earlier
for
East,
Coast,
U.S
and
then
also
earlier
for
Europe
and
then
in
the
alternate
weeks
to
do
evening.
E
West
Coast
U.S,
which
would
be
hopefully
still
late-ish
but
doable
for
East
Coast,
probably
not
very
doable
for
Europe.
Although
bless
anyone
who
decides
to
show
up
for
that,
but
it
would
be
much
more
viable
for
Asia
Pacific.
It
would
be
in
the
sort
of
like
early
morning
for
Sydney
and
and
Japan
that
ends
up
being
also
tightening
them.
So
if
we're
going
to
do
them
more
frequently
than
we
can
afford
to
shorten
the
meeting
a
little
bit
to
one
and
a
half
hours,
I
think
was
a
suggestion.
E
So
my
suggestion,
my
pitch
here
is
9
30
a.m,
to
11
Pacific
time
which
maps
to
noon;
30,
New,
York,
Time,
5,
30
p.m,
London
time,
6,
30,
PM,
Zurich
time
and
on
the
opposite
ones:
3
30
to
5
West,
Coast
Pacific,
which
is
hopefully
not
too
late
of
6
30
p.m,
New
York
time
and
that
maps
to
8
30
Sydney
time
and
then,
with
the
time
zone
shifts
it
actually
makes
the
time
better
for
Sydney
in
the
winter
rather
than
so.
Anyway.
That's
a
proposal
I'm
curious.
E
If
anyone
has
thoughts,
comments,
suggestions
for
making
this
better,
if
you
haven't.
B
E
Threatening
to
one
and
a
half
hours
instead
of
two
hours,
and
my
my
hope
is
that
if
we
are
increasing
the
frequency
that
we
would
typically
End
early,
but
we
will
see
it
could
be
that
we
just
fill
the
time
each
time.
E
But
one
going
one
and
a
half
hours
means
ending
at
11,
A.M
Pacific,
which
would
end
at
2
p.m:
New,
York
time,
7,
P.M,
London
time,
8
pm,
zark
time
for
that
European
friendly
times
and
would
end
at
5
pm,
Pacific
time,
8,
P.M,
New,
York
time
and
then
10
a.m.
Sydney
time
for
the
Asia
Pacific
friendly
time,
foreign.
C
No
I
think
it's
good
for
the
graphical
Java
guys
because
they
are
kind
of
excluded
until
now,
and
this
reinvites
them.
C
They
are
kind
of
the
graphical
Java
guys
are
not
in
Sydney
in
Gold.
Coast
is
I
want
to
meet
him
this
year
because
I'm
on
a
conference,
Town
Sydney
and
we
will
meet
up
there,
but
they
are
located.
I.
Think
it's
Gold
Coast.
He
told
me
in
Australia.
A
A
A
H
Is
it
possible
to
figure
out
these
three
spots
so
that
none
of
them
falls
into
the
night
for
anybody
like
10
pm?
Next
spot
is
6
pm
at
6
a.m,
and
the
next
spot
is
2
p.m.
Right
and
somehow
so
looks
like
comfortable
whenever
you
more
or
less
comfortable
for
now,
yeah
6
a.m
a
bit
early,
no,
but
and
then
a
sign
a
sign.
You
know,
or
maybe
rotating
something
like
this
in
one
of
the
spots.
So
everybody
has
some
inconvenience
once
a
month.
C
A
Think
we
need
to
be
sensitive
to
the
chairs
time
here,
because
if
we
have
three
time
slots,
I
don't
think
Lee
would
be
able
to
attend
all
three
of
those.
E
Yeah
selfishly
I'm
planning
this
so
that
I
can
attend
as
many
of
them
as
possible,
but
I
think
it's
not
unreasonable
for
me
to
delegate
a
co-chair.
That's
not
something
we've
had
to
do,
but
if
we
needed
to
do
that
to
make
more
times
work
I'd
be
I'd,
be
happy
to
discuss
that
too.
E
I
think
the
one
thing
the
flag,
maybe
is
that
the
day
change
I
know
that,
since
this
has
historically
been
on
Thursdays
people
have
carved
that
time
out
for
a
long
time.
So
the
shift
to
Wednesdays,
if
that
makes
things
net
easier,
and
that
harder
is
like
also
a
reasonable
thing
to
talk
about.
Benji
I
saw
your
flag
about
Wednesday
evenings
being
a
potential
problem.
E
Cool
that
one
was
a
bit
of
a
left
field
curve
ball,
so
I'm
totally
happy
to
stick
with
the
Thursday
plan,
although
the
one
thing
that
might
make
that
tricky
is
that
there's
also
the
graphql
board
meeting,
which
happens
on
Thursday
mornings,
which
right
now,
we've
got
set
up
to
be
alternating
weeks.
So
if
I
can
figure
out
how
to
do
that
so
that
it
slots
in
the
week
that
doesn't
have
the
morning
meeting,
then
I
think
will
be
good,
but
we.
K
Can
also
do
those
asynchronously,
probably
but
the
TSC,
what
it
means
for
what
counts
as
a
TSC
Quorum,
so
that
we
can
actually
like
approve
changes
to
the
spec
and
or
like
things
that
need
TSC
vote
that
need
Quorum
this
interacts,
and
so
we
have
to
decide
like
right
now.
We
only
expect
it.
K
It
require
a
TSC
member
to
show
up
once
every
three
months
and
now
they'll
either
need
to
show
up
once
every
three
weeks
or
we
need
to
establish
like
one
of
the
monthly
meetings
to
be
the
official
TSC
meeting
either
of
those
are
fine,
I'd
be
happy
with
the
once
every
three
weeks,
but
whatever
it's.
E
Like
yeah
I
forgot
that
those
interacted,
but
thank
you
for
reminding
me
about
that
I'll,
take
a
look
and
make
sure
it
doesn't
end
up
being
a
unnecessary
burden.
E
Okay,
so
my
sense
is
that
we
will
probably
stick
to
Thursday,
since
people
already
have
that
carved,
but
the
time
shifts
hopefully
make
things
better
for
everyone.
I'll
do
a
little
bit
of
calendaring
to
make
sure
that
they
don't
go
colliding
with
the
the
board
meeting
and
get
us
something
to
to
codify.
But
it
sounds
like
everyone,
no
one
I'm,
not
hearing
any
scary,
vetoes
or
anyone
saying
that
seems
like
a
bad
idea.
So
all
right,
this.
F
Is
effectively
taking
us
from
what
two
hours
a
month
to
up
to
six
hours
a
month,
so
I
think
it
should
be
good
for
a
while.
Hopefully,
if
we
keep
the
meetings
to
around
an
hour
in
general
and
have
that
extra
half
hour,
if
we
need
it,
I
think
that
should
work
quite
nicely.
E
It's
quite
sense
also
knowing
that
these
are
flipped
on
the
time
zones.
I
I
have
a
feeling
that
the
Asia
ones
are
going
to
be
a
little
quiet
for
a
while
and
that's
okay,
but
I'd
rather
have
them
and
have
them
be
quiet
as
like
room
for
people
to
start
showing
up
where
they
historically
haven't
been
able
to,
but
yeah
full
speed.
More.
C
How
do
we
manage
the
agenda
at
the
moment?
We
just
merged
everything
in.
Do
we
have
them
like
a
stop?
Gap,
okay,
and
this
is
one
and
a
half
hour,
and
you
have
to
go
to
the
next
meeting
with
that
item.
Something.
E
H
E
Yeah
I
think
it.
It
may
make
sense
to
have
a
rough
rule
of
thumb
that
if
your
agenda
item
gets
bumped
from
one
meeting
per
time,
that
you're
prioritized
for
the
following,
meaning
that
you
can
attend.
Yeah
I
think
that's
just
like
a
easily
stated
rule
that
we
can
abide
by
which
we'll
keep
it
easy
to
merge
agenda
and
also
easy
to
flag
the
things
you
need
to
rise
to
the
top.
E
F
Oh
I'll
try
and
keep
this
super
quick
because
I
know
Ivan
wants
to
say
something
we
have
as
promised.
Last
month
we
have
made
the
edits
to
the
graphql
over
HTTP
draft
specification.
We've
also
agreed
as
a
subcommittee
to
raise
it
to
our
stage
one.
F
F
So
there
is
the
graphql
over
HTTP
repository
under
the
graphql
foundation
that
you
can
have
a
look
at.
We
do
also
have
the
spec
MD
set
up,
so
it
now
compiles
and
has
a
hosted
website.
Much
like
the
graphql
spec
itself.
There
are
some
styling
issues
which
I'm
discussing
with
Lee,
so
don't
worry
too
much
about
those
but
other
than
that.
It's
basically
in
place.
F
Dennis
has
prepared
us
a
full
reference
implementation
that
he's
written
from
scratch.
So
that
is
available
for
you
to
have
a
look
at
that's
available.
It's
linked
in
the
agenda.
Also.
We
aren't
expecting
this
to
break
any.
F
We're
not
expecting
this
to
break
the
majority
of
existing
graphql
servers,
so
Express
graphql
should
already
be
compatible,
at
least
with
the
musts,
maybe
not
with
the
shirts,
but
at
least
with
the
musks
and
I
think.
The
same
is
true
of
Apollo
server
I
believe
they
already
comply
with
all
of
the
musts.
F
There
are
some
shoulds
that
they
they
do
not
plan
to
support,
but
that's
okay,
there's
decisions
they've
made
around
that
which
I
think
are
fine,
so
yeah,
please
go
have
give
it
a
read
and
give
us
your
feedback
Yvette.
D
J
It
can
be
handled
actually
I,
just
like
initially
I
propose
a
application.
Graphql
is
a
mime
type,
and
now
it's
used
only
for
response,
and
that's
why
confusion?
We
have
application
graphql,
yes,
graphical
language,
but
application
graphqls
response,
but
it's
like
technical
thing,
so
I
will
just
spend
like
half
a
day
today,
walking
through
my
rfcs,
so
I'm
like
now
I'm
summarizing
it
I
think
it
can
be
discussed.
Asynchronously
just
to
know.
C
And,
what's
reason
for
that,
even
in
the
beginning
like
if
we
cannot
just
introduce
a
mime
type,
that
has
to
be.
J
Database
and
what
people
actually
using,
for
example,
Protocols,
are
actually
using
and
it's
official
mind
types.
It's
like
application,
graphql
Dash
response,
it's
in
my
database
and
it's
make
more
sense
because
it's
it's
a
representation
of
response
not
through
the
presentation
of
required
or
HDL
file.
So
the
it's
like
technical
thing,
I,
actually
figure
out
how
to
apply
to
mime
type,
so
I'm
feeling
an
issue
to
to
apply,
but
we
can
actually
officially
registrate
it
yeah.
No,
not
a
big
deal
for
spec.
J
Just
like
a
note
that
and
I
will
try
to
submit
as
fast
as
possible
to
to
not
have
like
breaking
changes
along
the
lines
or
like
a
better
chance
to
prove
it.
Yeah.
E
Thank
you
for
this
update.
My
sense
is
that,
because
this
is
a
companion
spec,
that
it
doesn't
necessarily
make
sense
to
have
it
go
through
the
stages
because
we're
not
adding
it
to
to
the
main
spec
proper,
but
there
is
sort
of
a
discoverability
problem
that
we
ought
to
solve.
Of
this
is
we've
had
a
discussion
of
having
many
companion
specs,
this
one
being
the
most
important,
and
we
ought
to
have
a
place.
E
It
just
lists
out
all
of
the
specs,
including
the
401
and
I,
think
that's
just
kind
of
an
open
question
that
we
we
need
to
figure
out,
but
it'd
be
great
to
get
this
hosted
under
spec.graphql.org.
F
Okay,
crazy-
that
was
one
of
our
questions
really
was.
Should
we
have
the
main
working
group
actually
Advance
it
through
the
stages
or
because
I
think
we'll
still
stage
the
changes,
but
is
it
just
entirely
managed
by
the
subcommittee
or
does
it
need
to
escalate
up?
Obviously
we'll
try
and
keep
everyone
in
the
loop.
E
I,
like
a
model
where
a
subcommittee
gets
to
own
this,
because
it
allows
you
to
move
faster,
should
we
get
into
a
mode
where
it.
This
is
also
like
on
the
early
phase,
where
nothing
abides
the
spec
yet.
E
E
That
a
decision
is
the
right.
One
then
like
giving
this
larger
group
updates,
rather
than
asking
for
decisions
to
be
made,
is
probably
the
right
model.
C
One
other
question
on
this
is
like
okay.
If
the
subcommittee
owns
that
when
we
subcommittee
thinks
so,
we
want
to
release
that
as
as
this
is
done,
should
the
TSC
vote
on
that
or.
E
Yeah,
that
is
a
great
question.
I
will
double
check
how
our
sort
of
legal
guidelines
work
around
that,
but
I'm
pretty
sure
the
right
way
to
model
that
is
everyone.
Who's
contributed
to
that.
Spec
needs
to
have
gone
through
the
CLA
IM,
and
then,
when
we
actually
do
a
cut,
then
we'll
have
to
do
a
TSU
vote
to
ratify
it
and
that
those
two
things
basically
say
like
hey
everyone.
E
Who's
contributed,
has
contributed
under
the
same
guidelines,
so
it
can
be
free
to
use
and
that
the
TSC
has
approved
the
final
edited
dock,
but
it's
cool
for
it
to
kind
of
live
in
draft
mode
as
long
as
you
need
it
to
in
order
to
get
it
to
that
point,
but
I
think
so.
A
One
other
quick
question
here:
does
this
mean
that
well
graphql.js
is
the
reference
implementation
of
the
graphql
spec?
Does
this
mean
Express
graphql
will
become
the
reference
implementation
for
this
spec,
or
is
that
not
determined.
C
Actually
yeah,
it
kind
of
there
is
ensol
who
also
specified
the
graphical
W
as
protocol,
who
writes
now
an
implementation
from
scratch
that
just
implements
the
graphical
over
HTTP
spec.
If
Express
graphical
or
this
new
from
scratch
thing
becomes
a
reference.
Implementation
is
not
yet
defined,
but
there
should
be
something
that
we
can
point
people
to
got.
F
F
Is
going
to
be
a
reference
implementation,
it
will
be
Express
graphql
at
the
moment,
though,
no
one
has
updated
it
and
Dennis
has
done
the
work
to
right,
give
a
new
implementation
of
it
yeah,
but
this
is
going
to
get
more
interesting
when
we
start
expanding
the
graphql
over
HTTP
to
cover
service
and
events
and
web
sockets,
which
obviously
Express
graphql
does
not
support.
Currently
so
yeah
there's
definitely
some
decisions
to
be
made
as
time
progresses,
but
we
don't
need
to
worry
about
those
right
now.
F
I
think
we're
good
to
move
on.
The
next
agenda
item
managed
to
slip
in
there
with
our
attribution
I'm,
not
sure
how,
but
Solomon
has
actually
reached
out
to
me
and
said
he
has.
He
can't
make
it
tonight,
so
this
one
will
have
to
be
skipped.
Okay,.
E
Thank
you
for
letting
me
know
yeah.
So
just
close
the
book
on
the
HTTP
spec
update
that
last
bit
of
reference
implementation
I
am
happy
to
follow.
Whatever
recommendation
you
all
want
to
have,
though
I
think
it
probably
is
the
right
thing
to
have
the
reference
implementation
managed
under
the
foundation.
E
So
if
we
need
to
do
any
like
repo
move,
Shenanigans
we'll
make
that
happen,
but
I
like
the
idea
of
having
sort
of
like
a
core
that
is
not
beholden
to
express
or
KOA
or
any
one
of
the
sort
of
framework
level
pieces
as
being
the
representation
seems
like
a
nice
property
to
have,
but
nice
work
on
this
so
far,
everyone.
This
is
really
kind
of
Stellar
progress
over
there.
A
very
short
amount
of
time,
props.
B
One
quick
question:
Lee.
You
said
it's
probably
a
good
thing
for
the
reference
implementation
to
be
managed
or
owned
by
the
the
working
group
here.
But
would
we
say
and
I'm
thinking
of
all
subspecs?
Would
it
be
correct
to
say
that
it's
a
requirement
that
the
reference
implementation
be
owned
by
this
group.
E
I
think
that's
probably
a
safe
thing
to
require
I,
think
the
problem
or
the
the
failure
mode
that
I
would
like
to
avoid
is
one
where
we
Mark
a
particular
repo
as
the
sort
of
blessed
reference
implementation
that
we
guide
people
to
to
understand
the
reference
between
code
and
spec
and
then
for
whatever
reason
that
person
goes
Rogue
or
we
lose
access
to
it
or
something,
and
then
all
of
a
sudden.
We
end
up
in
a
broken
State,
and
so
we
don't
want
to
end
up
in
that
position.
E
It
also
makes
it
easier
from
a
legal
point
of
view
to
like
guide
contribution
and
Licensing
and,
and
that
sort
of
thing
I
would
say,
like
those
aren't
neces,
they
don't
have
to
be
strict
requirements,
but
would
certainly
make
it
far
less
possible
for
us
to
end
up
in
that
failure
mode.
If
we
make
sure
that
those
the
reference
implementation
projects
are
hosted
by
us.
E
Usually
the
trade-off
for
that
is
the
folks.
Who've
contributed
the
line
share
of
work
to
it
want
to
retain
maintainer
access
and
we've
got
playbooks
for
that.
So
hopefully
we
can
keep
that
going.
E
Okay,
so
we're
skipping
over
the
parsing
stress
testing.
Hopefully
we
can
talk
about
that
again,
At,
a
next
meeting,
which
means
Benji.
You
get
a
chance
to
talk
about
your
struct
type.
F
Oh
yes,
okay,
the
struct
type,
so
at
the
graphql
conference
a
little
while
ago,
I
guess
that
was
about
six
weeks
ago
or
so
I
did
a
talk
on
metadata.
I've
been
thinking
about
metadata
for
a
few
years
now,
there's
that
issue
thread
number
300,
which
is
particularly
long
and
I,
did
a
lot
of
research
into
it.
I
looked
into
all
the
different
solutions
that
people
were
doing,
I
thought
about
what
all
the
different
problems
were
and
I
was
starting
to
think
about
what
a
solution
might
look
like.
F
One
of
the
problems
that
I
kept
coming
back
to,
especially
when
we
talk
about
metadata
in
the
form
of
directives
is
the
issue
of
directives.
Take
inputs.
Introspection
gives
outputs.
How
do
we
mesh
these
together
and
it's
a
bit
of
a
problem?
So
I
was
chatting
with
Ivan
about
this.
After
the
the
meeting
we
had
a
very
productive
conversation
came
up
with
a
bunch
of
different
ideas
like
complete,
spitballing,
loads
and
loads
of
stuff
and
I.
Think
it
was
Ivan
originally
suggested.
F
Something
like
this
and
I
expanded
it
on
what
what
I'd
been
doing
with
the
with
the
one-off
and
also
with
a
few
things
that
you've
said
in
the
past
Lee
and
I
thought.
Maybe
this
is
something
and,
as
I
started
to
think
more
about
it.
I
realized
that
actually,
if
we
had
a
type
with
these
properties
properties
being
similar
to
that
of
an
input
object,
so
an
input
object
has
Fields.
Those
fields
have
types.
F
The
fields
don't
accept
arguments,
of
course,
because
they're
input
they
can
also
like
reference
in
a
chain,
but
the
the
loot
has
to
be
broken
at
some
point.
So
we
have
requirements
on
them
for
objects,
so
there
is
no
infinite
chain,
and
so
on
what
happens?
If
we
were
to
take
a
type
like
that
and
Export
it,
and
it
turns
out,
it
solves
a
whole
bunch
of
issues.
F
So
anyone
who's
familiar
with
the
graphql
introspection
query,
at
least
the
one
that
graphical
produces,
will
have
seen
the
off
type
of
type
of
type
of
type
of
type
of
type
fragment,
which
goes
I,
think
eight
layers
deep
from
memory,
and
it's
basically
the
same
thing
over
and
over
again
eight
layers
deep
and
what
it
means
is,
though
graphql
doesn't
actually
strictly
limit
you
to
having
a
an
X,
dimensional
array.
F
If
you
go
past
a
certain
number
of
Dimensions
and
non-nulls,
then
you
can't
introspect
it
with
graphical
anymore
and
there's
things
like
that,
but
also
it's
just
unpleasant
to
write
like
we
don't
want
to
be
writing
that,
in
my
opinion,
there's
various
other
things
where
this
kind
of
thing
actually
happens
for
people's
own
schemas.
F
So
I
had
a
situation
with
a
table
of
contents,
for
example
where
actually
you
want
like
a
deeply
tested
tree
structure
that
you
know
will
finish
but
will
represent
everything
in
a
particular
document,
I
think
of
a
you
know,
H1
headings,
all
the
way
down
to
maybe
age,
six
or
even
further.
You
want
all
of
that
stuff
to
come
through
and
if
someone
adds
another
level,
you
don't
want
your
application
to
break,
because
it's
not
requesting
that
extra
level.
F
People
have
solved
this
by
using
things
like
a
Json
scalar
or
things
like
that
to
to
grab
an
object
like
that.
But
then,
of
course
you
lose
typing.
F
There
are,
of
course,
also
ways
where
you
turn
a
tree
into
a
list,
pull
it
down
as
a
list
and
then
turn
it
back
into
a
tree
on
the
client.
But
one
of
the
main
things
about
graphql
is
giving
data
to
the
client
in
the
shape
that
is
useful
to
the
client
so
having
the
client
have
to
transform
again
afterwards
is
not
really
aligned
with
graphql's
goals.
I
would
say.
F
Another
thing
that
is
commonly
requested
is
the
wildcard
selection
on
graphql.
Now,
there's
many
many
good
reasons
that
we
don't
have
this
in
graphql,
the
main
one
of
which
being
that
it
would
break
or
one
of
the
main
ones.
F
It
means
that
we
can't
safely
add
Fields,
because
it's
now
going
to
effectively
affect
all
previous
clients,
and
that
makes
sense
for
most
things,
especially
when
we've
got
arguments
when
we're
returning
deep
nested
object,
trees
that
may
ultimately
be
recursive
when
we've
got
things
that
might
be
deprecated
and
so
on
and
so
forth.
But
if
you
think
about
something
that
has
structure,
and
yet
you
want
to
treat
it
as
a
scalar,
that
is
really
the
core
of
this
idea.
So
one
example
of
this
would
be
a
GIS
data.
F
So
if
you've
ever
used
geojson
for
representing
things
on
a
map,
a
geojacent
tends
to
it
has
a
bunch
of
different
shapes,
polygons
and
so
on,
and
it
has
the
coordinates
and
it
can
also
have
additional
properties,
and
you
may
want
to
strongly
type
these
and
when
you
pull
down
a
geojson
node,
you
want
the
entire
geojson
node,
but
you
also
want
to
know
that
it
has
a
description
and
what
those
properties
are
going
to
be
in
a
typesafe
way.
F
So
there's
a
whole
absolute
whole
host
of
issues
that
this
solves
I
have
written
up
an
RFC.
So
you
can
read
through
this
in
more
detail
and
maybe
slower
in
the
struct
markdown
file
in
the
rfcs
folder
in
the
graphql
working
group.
F
One
of
the
other
things
that
it
potentially
solves
is
polymorphism
and
it
actually
Harkens
back
to
one
of
the
other
solutions
that
we
originally
rooted
for
input
unions,
which
was
effectively
adding
type
name
to
two
input
objects,
and
we
decided
in
the
end
that
that
wasn't
the
route
we
wanted
to
go.
But
if
we
were
to
add
these
structs
to
Output
as
well
as
having
them
on
input,
then
actually
that
symmetry
there
may
make
that
solution
more
desirable.
F
So
I
experimented
with
this
as
potentially
replacing
scalar,
replacing
an
input,
object
or
being
a
new
type
called
struct,
and
in
the
end
and
I've
explained
this
in
the
document.
The
best
route
does
seem
to
be
to
basically
have
it
be
the
input
objects
become
struck
and
get
this
ability
to
come
through
output
as
well,
so
we'll
have
to
get
over
the
fact
that
it's
called
input
and
just
roll
with
it.
F
One
other
really
interesting
thing
that
we
could
do
with
this,
and
this
is
kind
of
optional,
but
also
desired.
If
you
think
of
a
scalar
at
the
moment,
like
a
Json
scaler,
you
request
it
and
that's
it
in
graphql.
You
request
the
one
thing
you
don't
give
it
a
selection
set
and
we
just
pull
it
down
for
you.
The
entire
thing
now,
sometimes,
with
these
kind
of
atomic
pieces
of
data
like
a
geojson
node,
for
example,
that's
what
you
want!
You
want
to
pull
down
the
whole
thing.
F
F
Now
these
selection
sets
would
be
a
little
bit
different
from
our
normal
selection
sets,
in
that
they
will
not
obviously
have
arguments,
because
these
fields
don't
support
arguments,
and
thus
they
will
not
need
aliases
and
they
should
not
have
aliases
and,
as
such,
the
merging
of
the
selection
sets
for
them
should
be
really
really
easy.
If
something
requests
field,
a
something
request,
field,
B
and
something
requests
the
whole
object.
We
just
get
the
whole
object,
because
that
satisfies
all
three
of
those
different
selection
sets.
F
So
that
is
particularly
interesting
when
it
comes
to
metadata.
It's
also
interesting
for
things
like
the
geojson,
because
you
could
say
I
just
want
the
coordinates
and
I
don't
care
about
the
attributes,
there's
a
whole
bunch
of
things
that
that's
useful
for
so
here's.
My
interesting
idea,
which
does
put
a
few
things
on
its
head
I,
wanted
to
collect
anyone's
thoughts.
Hopefully
people
may
have
had
a
look
at
it
since
I
raised
it
at
the
last
or
intended
to
raise
it
at
the
last
working
group,
but
it
was
punted
so
yeah.
E
I
remember:
we
talked
about
something
similar
when
we
were
because
we
had
this
sort
of
branched
path
when
we
were
talking
about
input,
unions
of
doing
essentially
a
struct
type
or
the
one
of
and
for
due
diligence,
and
also
because
it
was
interesting.
We
were
following
this
struct
type
that
could
be
used
in
input
output
forms
and
eventually
decided
that
it
had
too
many
like
it.
It
broke
both
forward
and
backwards
compatibility
if
I
remember
correctly,
like
there
was
there's
a
bunch
of
cases
where
you
could
paint
yourself
into
a
corner.
E
F
I,
don't
remember
those
specific
concerns.
I
have
thought
about
it,
a
fair
amount
and
I
think
we
can
avoid
most
of
them.
One
of
the
things
is
whether
the
like
thunder
type
name
field
is
required
or
not.
F
For
example,
if
we,
if
we
replace
input
with
this
struct
type,
then
obviously
it
needs
to
be
backwards.
Compatible,
so
done
to
type
name,
wouldn't
be
required
unless
you
were
using
it
as
part
of
an
input
Union,
but
in
that
case,
of
course,
you're
using
it
as
part
of
an
input
Union.
So
therefore
it
would
be
supported.
F
That
does
mean
that
you
wouldn't
be
able
to
upgrade
and
input
object
in
your
schema
to
suddenly
be
a
union
of
invert
objects,
but
that
I,
don't
think,
is
a
is
a
major
concern
and
I
I,
honestly
I
think
most
of
the
other
things
probably
are
fine,
but
I
have
to
refresh
myself
on
what
those
problems
were.
Yeah.
J
I
can
put
away
some
context,
sorry
Roman,
because
it's
connected
so
to
finish
like
like
a
change.
Basically,
it's
not
about
the
way
the
types
of
action.
It's
it's
about.
This
type,
it
became
a
frozen
type.
Basically,
if
we
add
any
non-nowable
field,
it
means
it's
required
to
provide
it.
J
So
imagine
you
have
jio
coordinates
and
you
recently
don't
ask
why
but
I
look
into
coordinates
and
I
figure
out
actually
like
Ukraine
have
its
own
local
coordinate
systems
so,
and
it's
very
makes
sense
to
provide
a
unified,
GPS,
coordinates
and
like
Ukrainian
local
coordinates.
If
it's
like
work,
always
business
and
Ukrainian
local
coordinates.
It's
not
knowable,
because
you
can
always
convert,
but
you
cannot
add
them.
J
So
if
you,
basically,
if
you
you
can
do
in
unions
of
stuff
but
yeah,
basically
like
even
without,
for
example,
of
coordinates
you
you
cannot
add
no,
no,
both
stuff
anymore
duplicate
is
weird
you.
You
cannot.
If
you
deprecate
it,
it's
mean,
like
you
deprecated,
and
put
an
output
at
the
same
time,
but
usually
in
the
system.
You
want
to
deprecate
output
and
only
after
people
stop
using
it.
You
duplicate
input
yeah
and
it's
it's
not
possible
here.
J
K
We
could
enable
migration,
if
you,
if
we
kept
input,
struct
and
output
struct
as
two
different
things
and
when
you're
in
because
structs
are
structural,
presumably
I
can
pass
any
struct.
That
is
a
superset
of
the
input
struct
in
and
I
can
provide
any
struct.
That
is
a
subset
with
all
the
required
fields
of
an
output
struct
to
the
like
resolver
on
the
server
you.
J
Yeah,
what
comment
if
we
have
two
different
types,
it's
basically
defeat
purpose
of
of
guitar.
Again,
yes,
fig!
You
cannot
wait,
you
cannot
wait
or
split
it.
If
you
create
one
type,
you
cannot
split
it,
but
if
you
create
two
separate
types
like
we
can
solve
the
same
problem
as
a
way
around.
We
can
introduce,
for
example,
right,
asterisks
or
some
form
of
recursive
fragments
to
the
same
solution.
So
main
proposal,
in
my
view,
is
like:
can
we
do
it
both
input
and
output?
At
the
same
time,
very
important
switch
to
Roman.
H
So
guys
I
I,
want
to
make
a
quick
comment
about
that.
Alias
is,
are
not
needed.
If
you
don't
have
arguments
actually
Alias
still
would
be
very
helpful.
If
you
want
to
return
it.
I
would
change
names
to
easily
serialize
into
some
object.
Redefined
object
on
the
client
side.
You
know.
Sometimes
it's
useful,
the
serialized,
the
keys
in
the
in
Json
sometimes
differ.
They
don't
conform
certain
language.
H
You
know
standards
of
the
property
names,
so
it's
normal
to
have
I,
know
some
attribute
or
something
to
change
automatically
the
keys
versus
the
property
names,
and
so
to
make
it
easy.
You
can
provide
aliases
for
some
fields
in
this
return
g-strom
so
that
they
can
easily
fit
into
the
the
serialized
object
right.
So
this
was
some
quick
comment
regarding
aliases.
They
still
might
might
be
allowed.
H
They
still
might
be
useful,
so
in
general,
I
would
say
that
I'm
all
for
it
I
think
this
thing
finally
might
solve
so
many
problems
that
actually
are
in
in
practice
out
there.
So
and
even
if
we
had
some
unresolved
issues,
you
know
with
these
kind
of
things
in
the
past
so
screw
it.
We
have
to
solve
these
issues
and
we
actually
have
no
choice.
H
Yeah
that
that's
that's
kind
of
my
opinion.
I
have
a
question.
So
basically
is.
It
is
probably
it's
a
chance
to
also
think
about
map
and
untyped
object
types
colors
or
something
like
this,
because
this
is
also
kind
of
a
close
seems
like
the
same
theme
and
again
in
practice.
It
is
very,
it
would
be
very
beneficial
because
the
entire
world
is
not
strongly
typed.
Sometimes
you
have
mixed
types
somewhere.
H
So,
although
I'm
all
for
strong
types,
but
the
reality
is
sometimes
somewhere,
you
need
it
so
map
and
untyped
object,
any
let's
say
map
and
any
would
it
be
appropriate
to
bring
this
into
the
context
and
final
question
since
looks
about
input
objects.
It
looks
like
the
scope.
The
time
scope
of
this
feature
is
Way
Beyond
October,
but
maybe
we
can
do
one
small
thing.
Long
asked
to
allow
return,
input
objects.
H
It
looks
like
it
will
be
as
part
of
this
particular
effort,
bigger
effort.
It
will
be.
We
will
allow
it
so
maybe
separately
in
October
release.
We
will
just
allow
it
and
treat
input
objects
as
kind
of
subtypes
or
restricted
types
of
object,
types
because
I
think
technically,
nothing
prevents
us
simply
to
return
in
input
objects,
and
it
is
often
the
situation
when
you
have
some
simple
object:
just
bunch
of
properties.
H
You
know
simple
strings,
integers
and
so
on,
and
you
want
to
send
it
to
the
server
or
receive
it
to
the
server
and
you,
but
you
have
to
duplicate
them,
one
type
of
type
and
another
type
as
input
type.
So,
basically,
maybe
we
can
just
allow
it
a
final
in
Industries
as
a
separate
change.
F
F
So
what
I've
written
down
a
list
of
a
few
of
them,
and
let
me
address
them
one
by
one,
so
first
was
Ivan
raising
the
the
non-null
issue,
so
another
use
case
for
this
geojson's
one
another
one
is
things
like
prose,
mirror
documents
and
things
like
that
where
you're
editing
nodes
in
those
cases
there's
a
generally
things
that
you
want
to
pull
down
from
the
graphql
schema,
you
want
to
modify
them
somehow,
and
then
you
want
to
send
them
back
to
the
graphql
schema.
F
So
one
of
the
things
that
you
can
think
of
with
the
struct
in
particular
by
marking,
think
of
it
as
like
input,
blah
abstract.
For
now,
it's
a
specially
tagged
input
type
that
you've
said
I
want
it
to
be
used
in
this
particular
way,
and
the
particular
way
is
this:
you
always
pull
it
down
from
graphql.
You
can
do
something
to
it
and
then
you
send
it
back.
F
So,
in
the
case
of
creation,
where
you,
where
the
non-nullability
would
cause
problems,
you
may
well
do
the
creation,
with
some
other
API
that
allows
you
to
add
more
fields
that
are
non-nullable
later,
the
the
server
will
backfill,
but
for
the
for
the
main
operation,
pull
it
down,
do
something
with
it.
Send
it
back.
The
addition
of
non-nullable
fields
isn't
a
concern,
because
you
pull
down
the
whole
object.
It's
got
those
fields,
even
if
you
don't
understand
them,
when
you
send
it
back
to
the
server,
it
still
has
them.
F
F
As
for
aliases,
which
Roman
raised,
if
we
allow
aliases,
it
basically
breaks
that
ability
that
I
just
described
the
ability
to
pull
things
down,
do
stuff
with
them
and
send
them
back
if
you've
got
different
selection.
Sets
that
add
aliases
now
you
potentially
overwrite
other
fields
or
you
cause
other
problems.
F
So
basically,
it's
just
not
compatible
with
what
the
desire
of
the
spec
is.
So,
yes,
it
would
be
convenient
in
certain
circumstances,
but
actually
it
undermines
a
very
significant
amount
of
the
feature
of
the
spec,
so
I
don't
think
we
can
allow
them
and
you'll
just
have
to
rename
those
fields
on
the
client,
side,
map
and
untyped
I
think
those
are
separate.
F
We
may
be
able
to
add
them
afterwards.
At
the
moment,
struct
can
have
any
scalar
other
struct
or
list
thereof
included
in
it.
So
if
we
also
allow
things
like
map
and
any
in
general,
then
those
hopefully
would
be
able
to
be
made
in
a
compatible
way.
As
well
said.
F
Maybe
this
is
putting
the
rest
back
into
graphql
nice.
Ask
them
that
actually
one
of
the
motivating
things
not
one
that
I'm
dealing
with
myself,
but
one
that
I
have
seen
in
the
issues
is
people
dealing
with
put
requests
in
HTTP
as
opposed
to
patch
requests
and
in
those
cases
you
do
pull
something
down.
You
don't
know
what
it
is.
You
know
you
know
what
bits
of
it
are
you
fiddle
with
those
and
you
send
it
back
so
yeah.
F
This
can
actually
deal
with
the
put
problem
of
HTTP
while
still
doing
it
in
a
graphql
way.
F
I
think
one
of
the
biggest
issues
honestly
that
this
introduces
is
that
it
makes
it
uncertain,
potentially,
when
you
should
use
an
object,
type
versus
when
you
should
use
a
struct
I,
think
that
is
honestly
the
biggest
problem,
and
the
answer
is,
if
you
don't
know
which
one
you
should
be
using,
you
should
be
using
an
object
type.
The
struct
has
a
very
specific
use
case
and
we're
going
to
have
to
be
careful
to
guide
people
towards
it.
F
So
I
am
very
aware
of
that
as
one
of
the
major
major
problems
with
it,
but
I
still
think
that
the
benefits
outweigh
that
cost.
Was
there
any
other
questions
that
I
didn't
address.
C
H
H
F
Someone
would
need
to
raise
a
separate
RFC
for
that
and
I
I
think
it's
unlikely
that
it
will
get
merged
in
time
for
the
October
spec.
But
we
could
try.
H
H
L
So
there's
there's
a
lot
to
like
about
this
proposal.
Yeah
there's
it
it
dresses.
Like
certain.
You
know,
complaints
we
often
hear
about
like
oh
yeah,
white
inputs
and
outputs
have
to
be
separate
and
all
that,
but
I
do
want
to
provide
a
glimpse
into
the
future
of
when
this
is
adapted.
L
So
at
Netflix
we've
used
for
long
time,
a
very
similar
protocol
called
Falcor
and
it
has
a
type
called
an
atom
which
is
basically
a
struct,
and
one
thing
that
we
have
observed
is
that
sometimes
things
end
up
all
getting
piled
into
into
that
to
the
UI
teams,
call
them
summary
atoms
and,
and
then
you
do
end
up
with
you
know
like
parts
of
the
graph
that
are
like.
Basically,
this
rest
blob
that
just
kind
of
grows
and
so
addressing
early.
L
The
the
ambiguity
of
when
do
you
use
use
this
I
think
would
be
a
pretty
key
for
you
know
healthy
graphs
in
the
ecosystem.
E
I'm
gonna
wrap
this
one
up,
so
we
can
have
a
break
time
shift
by
10
minutes.
My
advice
to
move
this
forward
is
to
back
up
from
the
proposal
to
redefine
the
problem.
I
know
like
this
ended
up
being
extremely
clarifying
when
we
talked
about
input
unions,
because
we
were
in
the
Weeds
on
the
details
of
a
particular
approach
and
backing
up
and
defining
the
problem
really
helped
us
map
out
the
space.
E
I
agree.
There's
a
lot
to
like
about
this.
E
E
Cool
thank
you
Benji
for
leading
that
super
interesting.
Let's
take
a
quick
break
and
come
back
at
12,
past
I
think
it's
a
roughly
five
minute
break
foreign.
E
E
D
E
Next,
up
on
our
agenda
is
graphql
definition
and
the
role
of
sdl
Roman.
This
is
yours.
Take
it
away.
Thank
you.
A
H
Okay,
so
let
me
start
this
is
essentially
this
is
a
short
presentation.
I'm
I
will
try
to
bring
back
the
attention
to
the
old
discussion,
already
old
and
quite
important
problem.
So
again,
we
have
essentially
two
definitions
in
this
spec.
What
is
graphql
and
both
I
think
and
setting
Factory
quite
unsatisfactory,
clear
and
unclear,
and
during
the
discussion
of
the
suggestion
that
there
was
even
opinion
that
it's
it's
so
like
an
empty
talk,
it
doesn't
matter,
you
know,
graphql
is
something
it's
different
for
everybody.
H
Well,
I
think
it
is
the
opposite.
If
we
Define
something,
if
we
build
something,
we
must
clearly
Define
what
exactly
we
build
and
again,
the
core
of
my
suggestion
is:
graphql
is
a
client
server
communication
protocol
and
now
let's
go
next.
This
actually
is
important
for
us
as
well
for
it's
important
for
potential
readers
and
for
for
us
as
well
to
help
us
focus
and
to
understand
what
is
our
Target
domain?
H
What
we,
what
things
we
want
to
specify
so
basically,
I
think
our
own
expertise
and
experience
influence,
what
we
put
into
the
spec
and
sometimes
not
in
the
right
way.
So
here
is
a
very
simple
diagram,
so
our
own
expertise
is
client,
Communication,
channel,
HTTP
and
server,
and
we
also
many
of
us
are
very
familiar
with
internals
of
some
graphql
implementations,
servers
and
clients
and
it
kind
of
shows
up
and
influences
what
we
put
into
the
spec.
My
so
and
the
question
is
what
what
what
should
be
like
I
mean.
H
Let's
explicitly
ask
this
watch,
what
should
be
the
concern
of
the
spec
and
I
think
it
is
communication
Channel,
basically,
what's
on
the
wire
or
what's
in
the
communication,
what
goes
between
a
client
and
server
and
again
client
and
Sarah
understood
in
general
way
it
can
be
sometimes
colliding
server,
running
the
same
domain
and
running
the
same
server
process,
and
it's
just
direct
call,
but
the
in
my
definition.
H
The
target
should
be
only
communication
definitions,
so
what's
on
The
Wire,
and
we
should
not
presume
that
our
readers
have
the
same
any
knowledge
outside
of
this.
Of
course,
they
would
know
something
about
programming
and
apis
and
so
on.
Some
of
them
would
be
with
no
just
client
side,
a
client
programs,
some
of
them
server-side,
and
definitely
we
should
not
presume
that
they
know
some
implementations
of
graphql.
H
Why
is
that
important?
I
would
like
to
give
you
some
example.
There's
a
late,
quite
heated
discussion
there
actually
around
my
PR
and
look
at
this
fragment
of
the
spec.
There
are
two
paragraphs
there,
two
sentences
and
for
me
it
looks
like
the
second
one.
Likewise
and
so
on.
It
is.
It
says
the
same
thing.
H
From
the
point
of
view,
oh,
it
says
you
can
omit
the
schema,
the
second
one,
the
only
difference,
I
see
it
should
be
emitted,
okay
and
that's
it
so
after
the
discussion.
What
here
is
what
I
was,
for
example,
the
explanation
that
I'm
getting
when
graphql
schema
is
represented
with
sdl,
and
now
you
see
when
you
do
print
schema
in
graphql,
Gs
or
equivalent.
H
It
means
that
this
is
about
certain
implementations,
the
server
side,
implementations
that
can
generate
schemas,
and
so
essentially,
this
second
sentence
says
that
the
a
server-side
software
should
generate
schema
in
this
way,
unlike
in
general,
like
if
you
write
a
schema
manually
and
design
it,
and
then
my
question
is
why
it
says
about
server-side.
Why
would
be
schema
even
mentions
the
server
side?
Implementation?
H
Second,
why
it
tells
us
how
to
do
things?
If
my,
for
example,
I
have
a
server
implementation
and
I
do
generate
the
schema
on
demand
and
I.
Consider
it
valid
in
the
terms
of
the
first
sentence,
why
this
spec
certainly
says
that
if
you
do
automatically
generate
it,
then
you
should
you
should
do
it
this
way,
you
should
admit.
Well,
you
could
I
mean
this
is
one
thing.
The
second
thing,
which
is
more
disturbing,
is
that
to
understand
the
second
statement.
H
You
actually
have
to
kind
of
have
some
knowledge
about
something
on
the
server
side
and
how
things
work
inside
the
server,
which
I
think
is
a
completely
wrong
assumptions
that
the
the
user,
the
reader,
would
know
something
about.
It.
H
That's
essentially
my
concern
with
this
and
it
illustration
of
how
it
happened
that
we
actually
lose
focus
of
what
should
be
in
the
spec
and
what
concepts,
what
things
we
can
use
there
or
which
background
references.
H
One
thing
we
get
in
line
with
other
similar
Tech,
essentially
that,
like
grpc
three
hour
and
so
on,
they
Define
communication,
not
the
implementation,
not
the
options
for
schema
generating
for
for
automatically
generating
clients
or
servers.
H
So
basically,
this
clear
definition
will
actually
guide
us
and
restrict
us
to
what
we
actually
talk
about
in
respect
and
important
thing.
We
really
have
a
lot
of
things
to
kind
of
discuss.
There
are
a
lot
of
requests
free.
We
have
enough
work
to
do
already
and
that
will
actually
clearly
cut
the
work
and
Define
what
we
should
do
again.
We
will
presume
readers
have
no
knowledge
on
clients
or
server
side
and
graphql
Frameworks
as
well
and
regarding
sdl
again
in
line
with
its
definitions
in
interface
definition
language.
H
If
we
declare
it
in
the
spec,
then
we
will
make
it
in
the
face
definition:
language.
It
defines
the
communication
protocol.
Essentially,
all
you
need
to
know
to
communicate
successfully
with
other
parties
and
that's
it
it's
not
about
generating
automatically
generating
client
code
of
server
code.
If
you
have
this
generated
good
for
you,
but
it's
not
the
concern
of
the
spec.
H
Thank
you
and
I
would
like
to
invite
back
to
this
discussion.
You
know
and
go
along
kind
of
the
line
that
I
suggest
that
the
definition
is
important.
H
E
I
see
a
bunch
of
comments
in
the
chat,
but
maybe
people
want
to
raise
their
hand
and
zoom
that
way
we
can
go
through
folks,
one
at
a
time.
E
I
think
Tim
won
the
hand
Race
So
to
go
for
it.
Just.
G
H
The
one
of
the
things
strange
things
we
have,
we
have
two
definitions
of
what
is
graphql
and
both
are
unsatisfactory.
Both
don't
make
sense.
The
first
definition
is
graphql
is
a
language
for
creating
client
applications
which
is
really
strange.
What
is
it
like
react
or
something?
H
You
know
there
is
a
client
application
without
a
server,
and
second
is
something
like
this:
it's
the
language
and
execution
engine,
although
we
don't
ship
any
engines,
so
basically
I
the
initial
motivation,
let's
clear
it
up
and
second,
let's
specify,
then
it
automatically
gives
us
the
focus
or
the
certain
defines
the
domain
that
what
is
the
concern
of
the
entire
spec?
D
M
Sure
I
think
there's
a
lot
to
be
said.
Generally
speaking
for
refining
the
I
guess,
the
definition
of
graphql
I'm
not
showing
me
as
it's
used
in
the
spec
document,
I
guess
we
should
a
be
consistent
and
B,
there's
always
room
for
improvement
when
describing
anything.
But
you
know
it's
tough,
you
know
maybe
we'll
never
hit
the
exact
perfect,
so
I
I,
you
know
I
would
generally
agree
with
that.
M
But
I
think
it's
a
it's
true
that
the
specification
doesn't
specifically
ship
an
engine
but
an
execution
engine,
but
it
certainly
ships
a
specification
of
execution,
that's
implemented
by
certain
engines,
so
I'm
not
sure
what
the
better
English
language
equivalent
would
be,
and
the
last
the
last
thing
I
would
say
is
that
and
I
guess
it's
a
more
narrow
discussion,
but
the
exact
relationship
between
or
different
slightly
different
angle
of
what
Rome
was
saying
and
important
is
I.
M
Do
think
it's
important
to
define
the
role
of
of
sdl
and
the
schema
my
sense
of
it
certainly
not
being
anywhere
near
things
when
they
were
created
or
added
to
the
spec.
Is
that
you
know
right
now.
We
have
introspection
a
document,
that's
right
that
basically
there
is
a
one-to-one
correspondence
between
introspection
and
and
and
the
and
the
schema
itself
and
and
everything
it
can
be
represented
in
sdl,
except
sort
of
the
function.
The
you
know
the
that
execution
stuff
and
it
might
be
worth
you
know
the
resolvers.
M
You
know
it
might
be
worth
explaining
that,
but
saying
that
the
two
are
identical
sort
of
ties,
our
hands.
You
know
if
we
find
something
that
something
further,
some
other
category
that
can't
be
represented
in
text
and
maybe
that's
the
hesitation
of
saying
the
two
are
identical.
Factually
speaking,
they're
not
identical,
we
may
want
them
to
be
identical,
but
it's
certainly,
and
maybe
we
want
to
suspect.
M
Maybe
there
could
be
like
some
language,
but
that
particular
example,
I
think
you
know
in
terms
of
converting
between
one
direction
to
another
I
think
is
fairly
straightforward.
You
know
there's
an
entity
that
you
know
that
that
we're
specifying
and
then
there's
the
textual
representation
of
that
entity
and
you
you
do
need
to
convert
back
and
forth
and
there's
different
differences
in
normative
approach
to
that
when
converting
back
and
forth
in
terms
of
standardization,
so
I
think
that
part
makes
sense.
But
in
general
you
know,
I
support
clarify.
M
You
know
continual
continuous
Improvement,
but
I'm
not
sure
what
the
language
in
particular
that
I
would
agree
with.
E
E
Into
the
background
of
why
things
are
the
way
they
are
now,
which
is
introspection,
was
the
original
way
and
still
the
preferred
way
to
fetch
the
schema
from
us.
If
you
are
a
user
of
a
service,
that
is
the
way
in
which
you
get
the
schema
from
that
service,
and
then
the
STL
actually
historically
was
a
way
to
talk
about
it
like
it
was
a
tool
that
people
used,
and
there
was
a
lot
of
demand
for
sort
of
codifying
how
to
do
that.
E
And
then
there
was
a
bunch
of
tooling
that
wanted
to
rely
on
it,
and
so
it
was
sort
of
added
in
a
way
that
was
like
not
really
about
this
communication
layer
at
all.
So
the
the
discussion
between
a
user
of
a
service
and
a
service
doesn't
actually
use
the
sdl,
which
is
part
of
the
reason
why
it's
a
little
bit
kind
of
floating
in
the
spec,
rather
than
being
grounded
in
that
that
core
reason
or
that
core
original
purpose.
E
But
it
still
has
proven
to
be
fairly
valuable
to
be
there
nonetheless,
but
I
agree
that
it
could
be
helpful
to
articulate
that
there
are.
There
are
a
couple
goals
to
that:
spec
that,
rather
than
a
single
goal,
I
think
the
the
first
and
foremost
goal
is
I.
Don't
know
that
I
would
frame
it
exactly
the
way
you
have
Roman
I
think
it's
not
necessarily
about
the
communication.
E
I
think
that
is
more
in
the
space
of
the
sort
of
grapple
over
HTTP
spec
is
more
about
that
communication
bridge
and
how
they,
how
that
works
on
a
fundamental
level
and
more
about
as
a
abstract
user
of
a
service.
What
what
is
your
perception
of
that
service?
What
properties
must
it
abide
by
and
then
the
secondary
one
is,
then?
How
do
you
talk
about
these
schemas
and
model
them
and
iterate
on
them,
which
is
where
the
sdl
IDL
spaces
ended
up
being
quite
useful.
H
Let
me
kind
of
respond
to
this
again.
I
understand
there
are
historical
accidents
and
the
things
were
added
and
created
in
organic
way,
and
it
evolved
into
something
really
violable
I
want
to
bring
up
again
the
perspective
of
the
newcomer
as
I
was
three
years
ago,
and
what
people
start
to
associate
like
directives,
they
Patron
annotations,
sdo.
H
We
as
an
ideal
and
people
may
know
some
other
examples
of
this,
and
this
they
start
because
there
is
a
direct
Association
of
things.
For
example,
oh
is
the
other,
it
is
actually
the
definition
of
the
bro
and
but
suddenly
they
are
met
with
the
surprises.
You
know
no,
it's
like
this
understand.
This
is
a
historical
explanation,
but
there
are
reasons
I
to
bring
it
with
the
expectations
and
not
only
expectations.
H
The
way,
usually,
they
work
in
other
Frameworks,
for
example,
the
ideal
is
the
definition
and
sdo
sdo
and
intersection
should
be
equivalent
expectation
is
it's
the
same,
only
sdo
for
humans
to
read
it
and
introspection
for
tools,
and
this
is
great.
It
works
and
all
this
contradiction
that
by
the
informational
content
is
not
the
same.
H
This
is
very
surprising
and
again
you
have
to
bring
up
the
historical
reasons
for
this
involving
I
think,
there's
a
good
reason
to
bring
it
up
in
currently,
and
this
kind
of
mostly
disregard
the
historical
reasons
why
it
appeared.
E
For
sure,
I
can
totally
agree
with
that.
Hopefully,
the
history
is
helpful
for
this
group
in
particular
to
help
us
guide
decisions
but
I'm
with
you
as
a
new
reader
of
the
spec.
You
should
be
able
to
make
your
way
through
it
and
understand
its
purpose.
That
seems
like
a
very
viable
goal.
Thank
you.
H
E
So
I
know
we're
coming
up
on
the
20-minute
Mark
for
this
agenda
item.
I
want
to
make
sure
that
we
end
with
something
actionable,
I.
Think
the
broad
stroke
of
what
you're
suggesting
here
Roman
is
on
point,
which
is
there
is
confusion,
as
you
read
through
that
confusion
is
in
roughly
two
buckets
one
bucket
being
sort
of
in
the
in
the
tactics
and
the
details.
There's
places
where
we
phrase
things
in
ways
that
is
could
be
clear
and
we
should
be
cataloging,
those
and
and
fixing
them.
E
So
you
had
a
screenshot
of
one
that
looks
right
for
an
improvement
where,
where
we
sort
of
repeat
ourselves,
with
lack
of
clarity
around
what
the
actual
expectation
is,
we
should
fix
that
I
I
love
that
I
think
that's
been.
Actually
the
Lion's
Share
of
the
changes
that
have
made
it
into
the
spec
in
the
last
couple
of
years
have
been
things
that
make
the
spec
easier
to
read
and
make
it
less
ambiguous
more
clear.
So
that's
one
category.
E
The
second
category
is
sort
of
this
overall
understandability
like
what
is
the
purpose
of
it.
What
is
what
is
its
domain?
I
think,
as
is
in
the
the
chat
and
I
broadly
agree
with
the
rough
course
of
the
chat
that
I,
don't
necessarily
agree
with
the
pitch
that
you've
given
us
as
to
what
the
the
primary
purpose
of
the
domain
of
the
spec
should
be
I
think
the
diminion
of
the
spec
should
be
as
an
observer
of
a
service.
E
What
you
should,
what
should
you
be
able
to
see
that
service
doing,
and
how
should
you
interact
with
it,
which
includes
communication
because
broader
than
that,
but
I
think
it's
the
the
main
point
there
that
we,
a
new
reader
of
the
spec,
will
find
themselves
confused
because
we
don't
make
it
very
clear
what
that
domain
is
is
a
problem
that
we
ought
to
solve
so
I,
don't
know
if
that's
enough
to
hopefully
get
us
to
something
actionable,
hopefully
that
first
category
of
things
is
actionable.
E
As
we
see
these
at
a
minimum,
we
should
be
flagging
them
as
issues
so
that
we
can
turn
through
them
and
fix
them
with
editorial.
If
there's
improvements
to
be
made,
then
pull
requests
are
even
better.
Let's
keep
churning
on
those,
because
the
more
of
those
we
can
fix
the
easier
it
is
will
be
to
read
the
second
one
feels
like
it
needs
something
closer
to
what
will
get
group
consensus.
H
C
It
is
not
like
a
good
term
that
that
Lee
used
in
the
user
group
recently
is
graphql
is
a
coordination
layer,
and
that
actually
is
what
the
main
graphql
engine
is
right.
It's
it's
not
about
communication.
That
is
what
the
graphical
https
pieceback
is
trying
to
solve,
describing
the
communication
between
clients
and
servers
over
http.
H
It's
transport
there
is
transport
and
there
is
communication
protocol
on
top
of
the
transport
right
right
and
Community
communication
protocol
is
that
the
request
text
show
should
be
like
this.
Then
the
response
in
Json
this
is
called
protocol.
What
is
it's
not
simply
language?
It's
just
the
language
yeah
right.
H
And
that's
my
big
question:
why?
Because
I,
why
you
didn't.
H
E
A
particular
request,
two
Services,
which
provide
the
same
schema
and
abide
by
the
same
graphql
defined
Behavior,
should
give
you
the
same
result,
given
the
same
request.
E
Then
it
becomes
really
difficult
to
build
tools
and
to
build
client,
libraries
and
all
the
rest.
So
you
need
a
definition
of
execution
that
is
detailed
enough,
so
that
clients
know
what
to
expect
and
servers
know
how
to
produce
those
expected
results
that
that's
the
main
purpose
of
the
execution
section
I
think
would
be
we'd
be
in
trouble.
If
we
didn't
have
that
we
would,
we
would
introduce
a
lot
of
ambiguity,
even
if,
like
I
there's,
there's
also
there's
a
lot
of
room
for
us
in
Spec
land
right
like
we
can.
E
E
To
this
point,
we
have
not
had
that
principle.
We've
actually
had
sort
of
the
flip
side
where
we
try
as
much
as
possible
to
contextualize
Norm
normative
statements,
there's
a
lot
of
non-normative
stuff
in
the
spec.
It
makes
it
longer,
but
the
goal
of
that
is
to
make
it
easier
to
read
for
two
general
audiences,
a
consumer,
a
user
of
graphql,
so
whether
that's
someone
like
someone
who's
building
the
Apollo
client
or
someone
who's
using
a
client-side
tool
and
then
there's
certain
parts
of
the
spec
that
feel
sort
of
egregious.
E
But
that's
for
the
second
audience,
which
is
someone
who
is
implementing
a
service.
If
you're
building
a
graphql
service,
then
you
want
to
be
able
to
look
for
the
spec
and
say
hey
if
I'm
building
out
this
particular
piece
of
the
introspection
engine
or
the
execution
engine
or
the
validation
engine.
What
is
the
appropriate
behavior
and
the
spec
very
intentionally
goes
beyond
the
normative
there
to
provide
the
algorithms
and
provide
context
around
how
they
should
work
and
why
they
don't
necessarily
have
to
do
that.
E
You
could
just
only
look
at
the
reference
implementation
to
get
a
sense
of
that,
but
so
far
that's
been
quite
helpful,
but
I
think
so
this
the
sense
of
where
is
it
that
we
should
State
the
domain
which
I
think
like
Michael
Roman.
You
guys
are
both
saying
things
that
are
accurate
here,
which
is
like
hey.
We
should
be
crisp
about
what
what
the
purpose
of
the
normative
statements
and
the
spec
are
and
there's
both
a
spec
spec
reader.
You
know
spec
for
the
spec
people
sort
of
take
on
that
which
is
like.
E
Is
it
or
is
it
not
inclusive
of
the
transport,
and
is
it
fair
to
call
it
a
client
server
or
is
it
bigger
or
broader
than
that?
It's
like
yes,
but
also
a
casual
reader
and
a
first-time
reader
is
going
to
come
to
this
with
the
language
of
I.
Have
an
IOS,
app
and
I
hit
a
server,
that's
built
in
Python
like
how
am
I
supposed
to
move
from
the
practicalities
of
that
world
into
the
abstractions
of
the
spec,
and,
ideally,
that
is
where
the
overview
section
helps
ground
things,
and
that's
why
it
starts.
E
With
the
statement
of
you
know,
it
is
designed
to
be
a
query
language
for
client
applications.
It
doesn't
have
to
exclusively
be
that,
but
that
is
its
original
purpose.
E
The
overview
is
a
place
where
we
should
be
setting
the
stage.
We
should
help
people
go
from
the
more
common
uses
of
graphql
in
terms
of
tactically
how
it
gets
used,
which
is
I,
think
we
even
mentioned
Json
a
couple
times
in
that
overview.
So
then,
like
tease
it
out
to
the
spec
domain,
I
think
broadly
what
we
have
written
there
probably
hasn't
changed.
Since
we
originally
wrote
the
very
first
draft
of
the
spec,
it
probably
could
be
improved.
E
H
First
of
all,
I,
like
your
term
observable
what
I'm
actually
trying
to
argue
here
is
whatever
observable
outside
the
server
should
be
specified.
Whatever
is
the
details?
How
I
reach
the
proper
response-
and
you
say
there
are
two
implementations
and
they
with
the
same
query,
they
should
return
the
same
result.
I
absolutely
agree
this.
It's
just
the
observable
part
is
our
concern.
H
Second,
in
general,
guys,
if
you
think
that
this
my
definition
is
not
appropriate
and
insisting,
but
I
think
then.
Secondly,
the
existing
definitions,
yeah
for
historical
reasons
they
came
up
to
be
are
not
satisfactory.
Then,
let's
suggest
other
better
fins.
Maybe
it's
client's
server,
communication
and
implementation
execution
with
our
protocol,
but
I
think
this
is
urgent
enough
problem
to
make
it
better.
E
E
What
is
observable
by
a
graphql
service
that
that
is
the
primary
domain
of
what
is
normative
within
spec,
because
the
the
spec
defines
how
a
user
of
a
service
perceives
that
service
behaving
and
in
many
cases
it's
hard
to
actually
tease
out
exactly
how
to
do
that,
and
the
gray
area
of
the
spec
is
one
where
we
go
a
little
bit
above
and
beyond
purely
the.
What
is
observable,
where
we
write
in
how
to
produce
that
observed,
result
as
well
and
I
think
I
think
probably
not
a
problem
that
we
do,
that.
E
It
doesn't
mean
that
we
actually
go
to
some
length
to
D
to
express
that
a
server
does
not
need
to
line
for
line
re-implement,
the
algorithms
that
we
propose.
But
those
illustrate
what
is
an
observed
behavior
and
it's
sometimes
difficult
to
draw
a
cut
line
through
that
and
and
only
express
the
pieces
that
are
observable
and
not
the
pieces
that
are
not
because
sometimes
it's
a
little
bit
difficult
to
do
that
cutline,
but
certainly
if
we
can
reduce
non-normative
pieces
in
a
way
that
improves
Clarity.
E
That
would
be
a
win
because
the
purpose
of
having
the
non-normative
pieces
there,
including
the
non-normative
parts
of
the
or
the
not
less
observable
or
non-observable
parts
of
the
algorithm,
those
are
there
for
clarifying
purpose.
So
if
they
reduce
Clarity,
then
we
should
improve
that
I.
Think
that's
a
reasonable
goal.
E
E
I
do
think
it
is
useful
to
have
sort
of
a
set
of
principles
as
spec
writers
here
in
this
audience,
that
we
have
a
shared
goal.
I'm
happy
that
you're
pursuing
this
Roman
I
think
you
can
read
from
the
chat
that
your
the
current
framing
of
that
is
not
quite
right.
You're
getting
a
lot
of
pushback
in
the
chat,
but
I
think
the
the
purpose
here
is
is
right
to
make
sure
that
we
understand
the
domain
and
that
there
is
a
lack
of
clarity.
E
Actions
so,
within
those
two
buckets
I
framed
earlier
in
the
tactics,
let's
continue
to
flag
those
as
issues
if
it's
not
clear
how
they
should
be
rewarded
like
there
is
a
point
of
something
that
is
lacking
Clarity
and
we
don't
know
how
to
fix.
It
therefore
issue
there's
a
point
of
something
that's
lacking
Clarity
and
we
have
a
good
idea
of
how
to
fix
it,
pull
requests
for
an
editorial
change
and
then
the
second
category
of
things
which
is
defining
the
domain.
E
It
seems
like
that
just
needs
a
better
case
at
iteration.
My
sense
is
that
you've
been
mostly
go
doing
an
inwards
out
mode
to
this,
like
you've
had
your
own
personal
perspective
on
what
would
be
improved,
you're.
Getting
pushed
back
on
that.
My
sense
is.
That
means
that
you
need
an
outside
in
process
where
you
can
pull
from
folks
what
they
think
the
domain
is
and
try
to
get
something
that
is
closer
to
the
agreed
upon
consensus.
E
It
seems
like
the
working
group
has
sort
of
a
rough
agreed
upon
sense,
but
we
just
haven't:
read
it
down
anywhere
and
like
arriving
at
something
that
we've
written
down
that
Maps
reasonably
close
to
what
we've
been
considering
the
domain
that
we're
defining
is
the
right
place
to
start,
and
then
we
can
start
to
define
the
problems
within
that
rather
than
trying
to
go
only
to
the
idealized
end
state,
which
I
think
is
always
going
to
suffer
from
this
case
of
being
any
one.
H
H
Let's,
let's
think,
let's
think
about
this
in
general,
you
know
forget
about
our
own
context,
forget
about
historical.
You
know
how
it
to
think
about
as
the
existing
thing
a
new
reader.
E
That
I
strongly
agree
with
one
of
our
principles
should
definitely
be
a
new
reader
of
the
graphql.
Spec
should
be
able
to
make
its
way
through
top
to
bottom,
without
getting
lost
or
needing
to
go,
find
a
secondary
dock
or
go
dig
into
history.
That
seems
like
a
very
crisp.
Hopefully,
everyone
agree
principle
that
we
should
all
have
in
mind
I
like
that.
A
lot.
M
Okay,
I'm
gonna
try
to
keep
it
pretty
brief.
This
is
sort
of
an
update
on
on
what
we
were
talking
about
a
few
working
groups
ago,
I
think,
and
that
was
the
ability
to
specify
that
more
types
that
actually
you
know,
satisfy
an
interface.
The
graphql
is
aware
of
it,
so
I'm
going
to
try
to
figure
out
where
I
can
share
my
screen
or
maybe
I'll
just
some
reason:
I'm
not
able
to
okay.
M
So
for
some
reason,
I'm
sorry
about
that,
like
I,
can't
seem
to
share
my
screen,
but
you
have
in
the
the
agenda
the
the
the
issue,
the
issue
linked
and
the
motivating
use
case.
So,
if
you
follow
that
link,
it
would
be
the
spec
pull
request,
950
that
has
in
there
and
I'll
just
paste
that
into
the
chat
and
sorry
about
that.
M
But
basically
we're
trying
to
or
the
the
goal
would
be
to
basically
say
that
that
if
you
have
a
type
that
implements
a
certain
interface,
it
would
be
okay
if
one
of
the
fields
of
that
type
like
implementing
an
interface,
let's
say
an
object,
type
implementing
an
interface.
It
would
be
okay
to
say
that
a
if
that
feels
typed
is
is
a
union
that,
where
all
the
subtypes,
all
the
members
of
that
Union
are
within
a
parent
Union,
it
would
graphql
would
currently
recognize
this.
M
So
right
now
the
only
types
that
can
fulfill
a
union
that
are
considered
valid
implementations
are
object
types,
but
in
some
cases
we
have
unions
that
for
sure
Implement
a
union
because
they're
a
sub-union.
So
let's
give
a
particular
example:
let's
say
you
have
a
union
of
animal
types
that
includes
cows,
wolves,
all
sorts
of
different
animals,
and
then
you
have
another
Union
of
animal
types
that
are
just
I,
don't
know
domesticated
animals,
but
they're
also
dutifully
listed
out
by
that
parent
Union.
M
There's
no
way
for
graphql
to
know
that
an
object
type
with
a
field
of
that
smaller
Union
implements
the
the
parent
Union
and
so
in
order
to
delineate
in
the
union
type.
M
We
have
a
couple
of
certainly
many
different
syntax
options,
but
basically
the
the
idea
would
be
to
Simply
allow
putting
a
union
inside
one
of
the
member
types
of
of
a
union
when
it's
first
specified
again
I'm
sorry
that
I
can't
share
my
screen
for
some
reason
this
time,
but
I
hope
that
I
hope
that
certification
is
basically
straightforward.
M
The
the
goal.
The
goal
would
be
to
basically
allow
the
graphql
type
system
to
be
more
robust
and
to
allow
type
relationships
to
be
better
delineated
by
the
existing
types
and
to
allow
graphql
to
better
enforce
you
know,
type
safety
or
I
should
say
you
know
the
type
membership,
and
we
spoke
about
this
last
time
and
we
spoke
about
or
a
couple
times
ago.
M
We
said
that
one
of
the
one
of
the
downsides
to
this
would
be
that
you,
if
a
union
is
allowed
to
specify
a
union
or
an
interface,
would
be
that
a
schema
reader
or
and
even
the
execution
engine
would
have
to
scour
the
schema
and
make
sure
that
you
know
sort
of
you
know
potentially
leading
to
recursive
problems,
and
so
in
this
implementation.
M
M
Now
the
union
is
a
member,
the
the
parent
Union
must
specify
all
of
the
child
member
texts,
and
so
actually
the
only
thing
that
has
changed
is
that
there's
no
automatic
I
mean
we
talked
about
this
in
a
further
work
group
to
go
with
the
intersection
types
that
you
know.
We
can
run
into
problems
with
when
things
happen
automatically.
M
That
can't
happen
because
everything
all
the
member
types
of
the
Union
are
still
specified
manually.
The
only
thing
that's
added
is
that
the
union
or
interface
that
we're
trying
to
say
is
a
member.
Will
that
will
later
be
trying
to
say,
as
a
member
of
that
Union
is
also
added
in
the
graphql.str
also
requires
a
a
change
in
introspection
to
be
able
to
build
the
schema
from
the
introspection.
M
We
have
to
not
only
say
what
are
the
possible
types
which
refers
to
object
types
currently
and
which
pretty
much
shouldn't
be
a
breaking
change
right,
so
the
graphql.js
possible
types
will
sorry.
The
introspection,
value
of
possible
types
will
stay
the
same
and
only
include
object
types
but
there'll
be
another
value
called
member
types
and
that
member
types
can
possibly
include
object.
M
Sorry,
interfaces
and
unions,
as
well
as
all
the
other
members
and
so
you'll,
be
able
to
build
the
schema
from
the
introspection
in
the
same
exact
way
and
I
think
that's
a
pretty
much
solves
all
the
recursion,
because
no
additional
recursion
has
to
happen
except
a
level
of
validation.
We
just
have
to
make
sure
that
that's
true
that,
but
that's
a
similar
sort
of
level
of
type
checking
that
we
currently
do
for
interfaces
that
Implement
interface.
M
M
There's
a
use
case
here,
but
it
does
involve
additional
complexity
and
so
I'm
not
saying
that
I
necessarily
think
that
it's
worth
it
I
mean
that's
for
the
you
know
the
working
group
to
as
I
said
before
you
know,
sort
of
for
the
working
group
to
decide
whether
additional
complexity
is
is
worth
it
and
it
doesn't
solve
everything
you
know
it
doesn't
solve
expressing,
for
example,
that
a
union
satisfies
an
interface.
It
solves
that
an
interface
satisfies
a
union,
and
so
it
doesn't
solve
everything.
M
So
that's
with
two
caveats,
but
it
actually
you
know,
but
it
was
a
little
bit
more
complicated
to
solve
that
direction.
I
think
this
is
much
more
straightforward
and
maybe
we'll
open
a
window
toward
solving
that
one
later,
and
you
know
and
and
if
this
maybe
advances
to
a
next
stage,
but
it's
felt
like
not
really
ready
to
be
released
until
that
problem
is
solved,
that
sort
of
approach,
meaning
the
parallel
problem,
is
solved.
M
F
I,
like
this
solution,
a
lot
better
than
the
last
one
that
you
propose
jack
off,
so
good
job,
that's
I,
think
including
the
object
types
does
solve
that
occursion
issue.
Well,.
M
Yeah
in
the
linked
example,
there
is
an
example
with
an
interface
of
boning
info
and
I,
don't
list
out
in
that
example,
just
because
it
was
the
original
iteration
every
object
that
implements
cloning
info.
But
later
in
the
comment
down,
I
mentioned
that
I
changed
the
proposal.
I
think
it's!
You
know
you
should
for
strictness,
and
so
just
that's
confusing
anybody
or
unions
I
do
list
out
them
out,
but
I
think
you
should.
We
should
list
them
out
for
both.
G
One
question
here:
so
the
seems
like
the
end
goal
that
you
would
have
in
mind
is
the
syntax
that
you
described
in
the
pr950,
where
you
can
provide
the
implements
syntax
on
a
union
level.
Do
we
even
need
to
implement
unions
of
interfaces
before
that
or
just
thinking
there
might
be
a
you?
Could
Define
it
in
different
ways?
Here
no
I
could
Define
the
implements
on
the
interface
level,
but
also
on
the
union
map.
M
Yeah
I'm
sorry,
the
within
pr950,
on
the
graphql
set
in
that
example.
There
there's
a
line
that
says
Allowed
by
939
and
that's
the
one
where
a
union
implements
an
interface.
So
that's
a
proposal
that
put
that
has
turned
out
to
be
a
little
bit
more
complex
and
so
that
hasn't
advanced.
Yet
you
know
this.
M
This
proposal
is
probably
I,
see
for
power
cooking
info
to
say
that
that
cloning
info
interface
would
fulfill
a
union
and
again
I
apologize,
I
I,
don't
have
all
the
types
they
would
have
to
be
explicitly
listed
for
cloning
info
in
there,
and
then
you
would
be
able
to
later
say
that
all
these
unions
cower
cloning
info
in
that
wolf
type
implements
animal.
M
But
again
you
would
have
to
list
out
explicitly
all
the
types
of
cloning
info
for
the
union
so
that
separate
PR
that
language
of
implements
sorry,
the
939
it
hit
a
problem
with
regards
actually
to
introspection
and
the
fields
of
such
a
union
type,
maybe
not
insurmountable,
but
actually
I
thought
to
tackle
it
first
and
they
sort
of
are
reverses
of
each
other.
So
we
might
eventually
that's
what
I
was
saying
before
we
might
want
to.
M
You
know,
even
if,
if
this
PR
is
found
reasonable,
but
it's
thought
maybe
listen.
If
we're
going
to
do
this,
we
want
to
make
sure
it's
compatible
with
the
reverse
one
of
a
of
a
union
implementing
an
interface
rather
than
an
interface
being
rightly
considered
a
member
of
a
union.
We
might
want
to
release
those
in
some
spec
version,
like
the
cut
version,
meaning
the
final
stage,
I
guess
together
this
one
seemed
a
little
bit
more
straightforward,
not
necessarily
more
important,
not
sure
how
important
either
of
these.
M
So
again,
it's
it's
to
be
determined
whether
the
additional
complexity
is
worth
it.
I
I
think
that
it
is,
but
you
know,
obviously
a
caution
is
a
is
a
good
idea.
I
think
that
it
is
just
because
I
think
that
the
if
the
type
system
can
be
made
more
robust,
we
should
try
to
do
that
because
it
it
unlocks.
M
You
know
just
more
power
in
the
system,
but
I,
don't
know
that
it's
you
know
certainly
not
necessary.
It
hasn't
been
until
this
point.
I
would
mention
that
the
original
issue
was
posted
by
others,
not
by
myself
and
I
picked
it
up
just
to
find
there's
something
interesting
to
work
on.
So
I
can't
say
that
on
a
day-to-day
basis,
my
life
will
be
changed
much.
E
We
did
in
the
long
long
ago
and
part
of
the
the
decision
that
ended
up
having
unions.
They
must
Express
the
list
of
objects
rather
than
going
through
an
intermediate
like
there's
a
reason
why
member
types
was
admitted,
I
think
we
are
considering
it
before.
E
My
major
concern
is:
is
going
back
to
that
original
one,
that
there
will
be
confusion
between
whether
to
use
member
types
or
possible
types
and
how
to
interpret
the
differences
between
the
two
and
I
I'm.
Still
a
bit
worried
about
that
and
I'll
disagree
with
Benji
I
I
liked
your
previous
suggestion,
better
I
liked
that
it
was
explicit
rather
than
implicit,
that,
if
a
rather
than
saying
that
there's
some
parent
Union,
that
is
a
superset
which
is
I,
think
what
this
allows
you
to
do.
E
The
really.
What
you
wanted
to
be
able
to
say
is
this
particular
Union
is
a
subset
of
that
unit
or
or
every
member
of
this
Union
implements
the
interface.
You
know
applying
sort
of
type
set
theory
that
this
is
always.
This
follows
a
constraint
that
exists
elsewhere
and
I
liked
the
explicitness
of
that
tonight.
C
M
Yeah
yeah
again,
there's
two
I
mean
there's
two
different
goals
for
for
robustness:
I'm,
not
sure
what
some
people
say
like
this
better
than
previously
I'm,
not
sure
which
iteration
I
mean.
There's
been
a
few
again
to
this
non-urgent
problem.
So
but
you
know
there's
there
there,
but
I
do
think.
I
I
definitely
see
Lee's
Point,
meaning
where,
where
do
we
specify
this?
M
That
a
child
Union
is
a
member?
You
know
all
the
types
of
a
child,
Union
or
or
all
the
implementations
of
an
interface
are
members
of
a
union.
Where
do
we
specify
that
I
think
we
certainly
you
know
we
could
specify
the
parent
Union
or
the
child
I
think
it
makes.
You
know
I'm,
not
sure
you
know
and
I'm
like
not
I'm,
not
sure
I
understand
the
advantages
or
disadvantages
of
both
I
mean.
Maybe
that's
something
to
catalog.
C
What
I
liked
was
the
previous
proposal,
where
a
union
implements
an
interface,
so
you're,
essentially
saying
that
this
Union
is
guaranteed
to
have
these
fears
that
actually
starts
real
problems
that
you
have
on
the
client
side.
With
this,
it's
it
kind
of
sounds
like
okay.
You
can
do
that,
but
what's
the
use
case
for
that,
oh.
M
Yeah,
no,
that's
true,
that's
true,
I'm,
not
sure
I
mean
I
have
the
use
case
set
over
here.
You
know
set
out
in
an
example
that
that
says
you
know
now.
Graphql
will
give
you
a
validation
error.
If
ever
you
have
a
change,
and
so
this
is
a
you
know
complex
you.
M
Basically,
the
use
case
would
be
a
complex
type
system
when
you
want
to
make
sure
that
you
have
a
guarantee
such
that,
if
you
make
any
further
changes,
you
know
all
you
know
that
you
know
that
relationship
still
holds
so
the
it
adds
robustness
overall
rather
than
then
I.
Think
because
you
could
always
say
that
it's
not
you
know,
you
I
think
you
could
leave
it
out,
but
it
adds
that
level
of
robustness.
E
That
robustness
is
also
valuable,
though
right
like
as
soon
as
you
introduce
that
robustness
constraint,
then
you
can
rely
on
it
elsewhere.
So,
if
you
know,
I
think
the
original
motivation
for
interfaces
implementing
interfaces
was
this
sort
of
actually
like
fulfilling
an
interface
problem
right.
You
say,
like
this
interface
describes
something
in
a
broad
way.
E
I
wanted
to
find
something
in
a
more
specific
way,
but
rather
than
doing
that,
only
via
a
single,
concrete
type
I
actually
want
to
again
use
an
interface
and
up
until
that
particular
proposal,
it
wasn't
possible
to
do
that.
Interfaces.
Implementing
interfaces
is
actually
more
about
applying
a
constraint
that
says
interface
B
definitely
is
implements
interface
a
so.
If
something
says
it
needs
an
a
you
can
use
a
b
you'll
be
good
and
I
I.
E
Remember
that
being
the
original
thrust
of
the
last
time
you
you
brought
a
variant
of
this
through
and
that's
why
I'm
saying
I
liked
the
previous
one
better
was
saying
that
okay,
again
I,
don't
want
to
supply
a
specific,
concrete
object
type,
but
in
this
case
I
want
to
supply
a
couple
defined
by
a
union
and
I
want
to
be
able
to
tell
you
that
this
Union
is
definitely
going
to
be
implementing
that
interface,
because
I've
specified
that
it
must
the
other's
constraint.
E
So
that
says,
like
also
in
in
you
know,
one
part,
the
robustness
part.
The
schema
validation
can
now
make
sure
that
you,
you
know.
You
stated
that
thing
that
that
thing
is
true
and
it
can
fail
to
you
know
we
can
make
sure
that
there's
a
rule
that
says
that
the
schema
must
abide
by
that,
but
also
now
it
unlocks
the
ability
to
do
that
that
subtyping
so
I'm
curious.
E
If
there's
I
like
that,
because
I
think
the
flip
side
sort
of
where
you've
gone
with
this
to
have
both
member
types
and
parent
types
is
less
about
supplying.
That
constraint.
On
the
subtype
and
more
about
saying,
like
Okay,
you'd,
have
to
go
back
to
this
parent
type
and
keep
adding
like
every
time
you
had
a
subtype
you'd
have
to
go
back
to
this
parent
and
add
it
to
that
list
and
I
was
concerned
about
the
scalability
of
that.
L
M
I
guess
I
see,
I
mean
the
reason
the
the
scalability
problem
is.
You
know
it's
attention,
I
guess
with
the
explicitness
meaning
in
the
other.
In
the
other
version
you
would
say
I
guess
I
I
mean
again.
I
was
thinking
also
as
a
potential
other
approach.
Let's
say
if
we
return
to
the
line,
I
finally
figured
out
how
to
scare
share
my
screen
for
some
reason
it
escaped
me
if
we
have
this
line
over
here,
unlocked
by
939,
where
we
said
Union
cower,
wolf
implements
animal.
M
We
could
form
that
more
generally
and
I
think
I
think
this
is
what
you're
saying
that
I
at
least
any
sort
of
Union
has
to
you
know,
put
let's
put
aside
the
word
implements,
but
has
to
satisfy
certain
constraints.
So
it
could.
We
could
say
over
here
that
one
of
the
constraints
is
that
it
implements
animal
and
we
could
have
some
language
over
here.
Some
nice
short,
wonderful
language
that
says
that
it
has
to.
M
It,
has
to
also
satisfy
the
union
and
therefore
we'd
be
specifying
that
on
the
child's
on
the
child
level.
So
that
was
another
first.
Is
that
basically,
what
you're
saying.
E
Yeah
that
that's
what
I'm
saying
that
implements
peace
is
nice,
because
it's
local
to
the
subtype
that
you
care
about
describing
the
constraint
on,
and
that
is
where
you've
describe
the
constraint.
As.
E
C
M
So
I
mean
basically
I'll.
Take
you
know
what
I'll
do
is
actually
other
people
have
their
hands
raised,
I'll,
take
more
feedback,
I,
guess
and
but
I
can
work
on
that
as
like
an
alternative,
no
rush
with
it
yeah
and
then
I
I
think
I
even
had
their
hands
I.
E
J
Yeah,
like
short
thing,
basically
like
your
previous
proposal
on
939,
provide
some
benefit
to
the
client
I
thought
about
what
what
this
criteria
benefits
to
a
client
and
like
I
call
it
directive
test.
Can
we
Implement
with
features
a
directive
server
specific
directive,
so
you
can
think
wait.
J
You
can
create
empty
union
now
and
you
can
create
like
new
directive
code
like
Implement
interface,
and
it
will
be
implementation
detail
of
a
server
so
what
we
and
it
provide
like
type
guarantees
and
validation.
You
can
implement
it
that
way.
But
the
question
here
is
quite
losing
anything
or
not
like
in
case
of
939
coin,
to
Vision
stuff
client,
who
is
an
ability
to
to
acquire
a
few
directly
type.
J
J
Is
not
an
issue
so
like
I,
don't
see
by
different
and
provide
a
bit
of
trivia
about
interface
implementation,
other
interfaces
not
just
for
exchange.
It
was
about
because,
like
you,
can
change
output
type
in
if
interface,
Implement,
another
interface
and
have
a
field
returning
another
interface
chain.
You
can
update
it,
so
example
was
pretty
complex,
but
it
basically
I
want
to
express
something:
new
new
contract
between
content,
server
and
939
review
with
directive
test.
But
this
one
is
not.
M
Yeah
I
mean
that's
great
feedback,
I
mean,
and
specifically
since
we're
talking
about,
maybe
changing
it
to
beware
the
child,
Union
or
the
you
know
what
would
would
be
specified.
Maybe
a
directive
over
there
would
be
a
better
way
to
express
it.
Yeah
thanks.
E
One
last
thought
on
this
before
we
wrap
is
I.
Remember
looking
at
your
pull
requests
before
about
this
and
being
worried
about
infinite
recursion,
recursion
Loops,
which,
up
until
this
point
you
had
safely
avoided
by
limiting
this
to
only
be
interfaces.
But
if
it
is
unions,
be
aware
that
that
might
be
something
you
have
to
account
for,
but
I
think
I
still
think
this
is
interesting
like
we
marked
it
as
RFC,
one
for
for
a
reason,
I
think
like
the
being
able
to
appropriately
Define
these
subtypes.
It
still
seems
quite
useful.
E
Okay,
folks
I
know
we
are
a
bit
over
time
and
sorry
Benji
to
bump
your
last
one
I
know:
we've
also
lost
a
handful
of
attendees
since
we're
running
a
little
bit
over
so
feel
free
to
async
that
or
bring
it
to
the
next
group
meeting,
and
thank
you
all
for
joining
healthy
discussion.
All
around
have
a
good
rest
of
your
day.
See
you
in
the
next
one
bye.
Everyone
thank.