►
From YouTube: GraphQL Working Group (Primary) - 2023-08-03
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/
A
B
B
I,
just
a
few
minutes
ago,
added
myself
to
the
agenda
via
PR.
So
if
somebody
who
can
accept
that
PR
who
wants
to
merge
that
in
that
would
be
great,
it's
already.
B
B
A
C
Okay,
welcome
everyone
that
we
were
expecting
another
couple
of
people,
but
it
looks
like
they
are
either
running
late
or
maybe
they
won't
make
it.
So,
let's
get
started
by
joining
this
meeting,
we've
all
agreed
to
the
specification
membership
agreement,
the
participation
guidelines,
the
contribution
code
and
the
code
of
conduct
links
to
all
of
these
can
be
found
in
the
agenda.
If
you
need
a
refresher
first
of
all,
I'd
like
us
to
go
around
and
introduce
ourselves
we'll
do
it
in
the
order
that
is
in
the
agenda.
C
However,
I'll
start
as
I'll
Host.
This
meeting
until
Lee
turns
up
hello.
Everyone,
I'm
Benji,
Alex,.
E
Hi
everyone
I'm
Cohen
I'm,
an
Apollo
I
work
on
the
Apollo
iOS
framework,
yeah
I'm,
also
here
to
chat
about
CCN.
G
Hello:
everyone,
my
name,
is
Martin
I'm
working
with
bonoire,
actually
on
Apollo
kotlin
I
I
did
a
very
last
minute.
I
came
to
the
agenda
about
sdl
and
how
to
write
schema
in
sdl
form.
So
if
we
have
time
I'm
happy
to
talk
about
it
and
in
all
cases,
I'm
also
super
curious
to
hear
about
CCN,
so
I'm
happy
to
be
here.
C
Yes,
thank
you.
Everyone
have
a
few
slight
audio
issues
here
which
have
now
been
resolved.
Okay,
so,
first
of
all,
if
anyone
can
help
with
the
notes,
that
would
be
excellent.
It's
the
same
note
stock
as
we
have
been
using
for
the
last
few
meetings,
so
please
go
ahead
and
contribute
there
I've
added
a
title
to
the
top
of
the
file,
so
you
can
carry
on
from
there.
C
C
C
H
I
just
wanted
to
say
that
we're
going
to
resume
the
incremental
delivery
working
group
meetings
on
Monday
they've
been
paused
for
a
while,
but
starting
up
again
next
week.
Fantastic.
Thank
you.
C
Rob,
okay,
so
we'll
move
on
to
reviewing
the
meetings
it
looks
like
no
one
was
at
the
secondary
Asia
Pacific
meeting,
because
Lee
is
the
only
person
on
the
agenda,
so
I
guess
we
can
skip
straight
over
that
and
the
same
appears
to
be
true
for
the
EU
meeting.
Again,
no
one
is
in
that
agenda
file
so
well.
That
was
easy.
C
Let's
have
a
look
at
the
action
items
then
there's
a
couple
that
are
up
ready
for
review,
so
I'm
going
to
open
the
first
one
of
those
which
is
issue
number
one.
Three
three
five
clarify
the
selection
set
in
the
example
is
a
selection
set
and
not
a
document.
C
Okay,
so
this
is
an
issue
that
was
raised
in
a
meeting
end
of
last
year
and
no
one
seems
to
have
progressed
it
for
a
while.
There
was
a
pull
request
from
Roman,
but
it
didn't
gain
consensus,
so
I
think
the
proposal
is
or
my
proposal
is
either
we
close
it
and
the
issue
or
we
look
for
another
Champion
or
us
Roman
to
pick
it
up
again.
Does
anyone
have
any
opinions
on
this
or.
J
C
But
if
no
one
has
any
opinions
on
this
for
now,
I
guess
I'll
leave
this
one
open
and
we
can
discuss
it
again
at
a
future
meeting.
C
The
next
action
item
is
hey
everyone.
Can
you
review
all
of
your
old
action
items
because
we'll
be
garbage
collecting
them
and
that
was
assigned
to
everyone
and
that
was
assigned
in
March?
So
hey
do
that
we
will
close
them,
so
I
guess
by
the
by
the
September
meeting.
If
nothing's
been
done
on
these
these,
we
will
go
ahead
and
close
those
does
anyone
have
any
other
action
items
that
they
feel
that
they've
completed
or
made
progress
on
that
they
want
to
share.
E
E
Ccn
proposal
has
gone
Domino
for
a
little
while
it's
been
stalled
and
we're
looking
to
pick
that
up
again
and
hope
you
proceeded
through
the
stages
of
the
spec,
so
everyone
knows
that
that
is
that
this
meeting
was
largely
there
at
the
last
one
I
think
it's
just
Rob
and
Ivan
that
may
be
new
to
this
information,
but
for
the
purposes
of
one
everyone
watching.
This
recording
decision
has
been
stolen,
largely
around
two
pieces
of
discussion,
one
being
error
handling
and
the
other
being
null
propagation.
E
So
the
decision
that
was
taken
at
the
last
working
group
meeting
was
to
scale
back
the
CCN
proposal
to
really
just
the
absolute
Basics,
which
at
the
moment,
is
the
bang
operator
and
try
Advance
it
that
way,
get
it
into
libraries,
get
it
into
production
somewhere
or
into
test
apps
and
gather
feedback.
That
way,
as
we
need
more
complexity
and
we're
looking
to
solve
these
things
that
come
up
in
production,
we
can
then
layer
on
this
stuff
as
it's
needed
if
they're
not
needed.
That's
great.
E
Now,
as
I
said
earlier,
like
the
discussions
around
the
things
that
we're
stalling
it,
there
are
other
proposals.
I
think
one
of
them
is
fragment
isolation,
if
I'm
not
mistaken,
that
is
useful
in
handling
null
propagation
I
think
there
is
other
things
to
do
with
error
handling
if
those
Advanced
separately
and
they
get
put
into
the
spec.
If
CCN
advances
and
gets
put
into
the
spec,
it
will
simply
come
along
with
the
ride
to
whatever
those
changes
are
with
those.
E
So
I
really
wanted
to
bring
this
here
to
update
you
on
CCN
is
alive
again
what
we've
decided
to
do
with
the
proposal
and
then
gather
any
feedback
on
what
people
think
about
stripping
it
back
to
really
just
the
beginnings
and
going
from
there.
B
Thanks
for
that
update
Calvin,
it
seemed
like
in
the
meeting
we
had
a
lot
of
discussion
around.
You
know
the
two
significant
open
issues
and
and,
like
Calvin
said
it
kind
of
came
to
a
realization
that
a
lot
of
this
stuff
is
not
directly
tied
to
CCN
and
perhaps
can
be
addressed
in
other
proposals
in
the
future.
B
I
think
that
it
was
proposed
that
we
we
move
back
to
just
using
the
bang
operator
and
not
including
the
question
mark
operator,
I'm,
not
sure
if
there's
a
better
technical
term
for
that
other
than
question
mark
operator
currently,
but
I
felt
like
that.
Wasn't
we
didn't
have
a
full,
consistent
consensus
on
that
part.
I
think
that
what
we
definitely
had
a
lot
of
agreement
on
was
saying
that
we
need
to
scale
back
all
of
the
behaviors
around
error,
propagation
and
error
handling
and
and
bubbling
and
catching
of
Errors.
B
I
I
wasn't
clear
if
we
felt
strongly
that
the
question
mark
operator
should
or
shouldn't
be
included,
it
felt
like
the
two
options
were
either
not
include
the
question
mark
operator
in
this
initial
RFC
and
then
move
forward
with
that,
maybe
as
a
secondary
later
on
or
include
the
question
mark
operator,
but
only
use
it
for
just
changing
the
null
ability
annotation
of
the
field
rather
than
as
a
catching
operator
and
I.
Think
that
was
the
the
one
part
of
it
that
we
didn't
really
come
to
consensus
on.
E
Yeah,
so
right
now
this
the
RFC
itself
has
been
stripped
back
to
just
the
bang.
The
spec
will
follow.
But
if
you
look
at
the
I
share,
concerns
around
the
question
mark
and
I
think
it
is
useful
if
you
go
back
to
Lee's
original
point
of
raising
it,
which
is
to
be
the
counterpart
to
bang
right
to
change
the
null
ability
of
non-nullability
of
something
into
being
nullable
for
the
client
I,
think
that
has
value
and
the
two
can
go
together.
E
So,
yes,
it's
eliminating
the
use
of
a
question
mark
as
a
null
boundary
from
the
RFC.
B
Right
but
eliminating
the
question
mark
as
a
error,
boundary
is
different
from
eliminating
the
question
mark
completely
right
and
it
sounds
like
the
RSC
is
now
being
stripped
to
remove
the
question
mark
completely
and
personally.
My
concern
is
that
that
makes
the
bang
operator,
in
many
cases,
almost
unusable.
E
Currently,
it's
just
back
to
the
bank
I
wanted
to
hear
Lee's
opinion
because
he
was
the
one
that
originally
raised.
The
question
mark
as
being
the
counterpark
to
bang
I
think
it
is
useful
just
as
a
notability
modifier,
not
as
like
a
nullability
boundary.
Sorry
null
propagation
boundary
in
the
response.
E
G
I,
like
the
question
mark
because
it
gives
the
client
and
it
moves
error
handling
out
of
the
schema
like
there's
a
world
where,
instead
of
defaulting
to
null
everywhere
in
the
schema,
it's
easier
for
backend
developers
to
use
non-level
fields
and
then
clients
can
opt
in
or
only
if
they
want
to.
So
that's
something
that
gets
me
pretty
excited,
but
as
long
as
we
can
add
it
after
the
fact
and
I'm
good
I
think
the
question
here
is:
what
is
the
primary
role
like?
G
Maybe
do
we
want
something
to
experiment
with
or
do
we
want
something?
I
mean
it's
it's
a
usual
chicken
issue.
G
If
we
just
want
something
to
experiment
with,
maybe
we
can
start
with
exclamation
mark
and
we
don't
need
the
full
consensus.
Excuse
excuse,
if
I,
if
it's
I'm
new
to
this,
so
I
I'm,
not
sure
and
100
sure
about
the
process
there,
but
I
guess
the
question
behind
this
is:
what
does
it
take
to
get
this
into
graphql,
GS
and
and
start
iterating
with
with
this
here.
B
Yeah
thanks
Montana,
oh
go
ahead,
come
no
go
ahead.
I
was
just
gonna
say
that
it
seems
like
we're
past
the
phase
of
like
needing
something
to
experiment
with,
like
we
have
gotten
some
pretty
good.
You
know
implementation
of
a
lot
of
this
stuff
already
in
an
experimental
Branch
and
we've
played
with
it
it's
a
lot
of
talking
through
the
expected
behaviors
of
specific
edge
cases.
B
So
the
big
question
is
around
the
question
mark
operator
being
used
strictly
to
just
change
the
null
ability
of
a
field
and
handling
error
propagation,
as
if
you
have
an
error,
it
just
propagates
up
to
the
next
null
field,
whether
that
is
a
natural
email
field
or
a
field
that
has
become
null
with
the
question
mark
operator
or
if
we
want
the
question
mark
operator
to
be
used
as
a
catch
for
that
specific
error,
so
that
when
you
use
a
bang,
you
need
to
use
a
question
mark
to
indicate
where
you
want
that
error
to
propagate
to
those
are
kind
of
the
two
options
here
and
the
the
fact
that
we
haven't
come
to
a
determination
on
that
is,
what's
LED
people
to
say
like?
B
Maybe
we
just
keep
the
bang
operator
alone
right
now,
and
we
don't
do
the
ex
the
question
mark
until
later,
when
we
can
get
consensus
on
it.
The
other
side
of
that,
which
is
certainly
what
I
fall
on
and
I,
and
we
talked
about
a
lot
at
the
meeting-
was
that
we
could
use
the
question
mark
as
that
simple
nullability
version,
and
if
we
wanted
to
add
some
sort
of
catching
behavior
that
that
would
be
something
we
can.
B
We
can
then
do
in
another
Proposal
with
some
sort
of
at
catch
directive
or
some
other
way
of
handling
that
in
the
future,
I
I
I'm
kind
of
unclear
on
what
the
next
steps
here
for
us
to
actually
move
forward
are
on
anything,
though.
I
One
problem
is
that
we
previously
discussed
use
cases
and,
for
example,
they
said
like
zero,
just
trip
bank
and
question
marks
and
send
like
a
query
to
server
and
the
same
same
will
happen
for
a
lot
of
white
proxies.
I
I
I
You
can
always
get
result
of
question
of
query
without
the
bank
and
change
it
to
be
too
much
like
a
query
with
a
bank.
Opposite
is
not
true
about
question
mark.
So
if
you
get
result
of
execution
with
question
mark
stripped
and
try
to
make
it
to
change
it,
it's
not
possible
to
change
it
too
much
acquire
with
the
question
mark.
So
let's
create
a
problem
for
proxies
proxies
or
like
like,
for
example,
whatever
it's
not
only
proxies.
I
I
Yeah
I
say
like
we
will
immediately
will
have
this
problem.
Like
I
expected,
we.
F
I
Experimental
feature
like
some
schema
composition
or
bike.
J
E
Yeah,
the
the
proxy
considerations
are
interesting
and
those
hadn't
come
up
before
the
relay
arguments
correct.
They
say
they
couldn't
use
it
without
other
proposals
like
fragment
isolation,
and
that
was
at
the
last
sub-working
group
meeting
in
his
opinion
was
fragment.
Proposals
could
help
them.
It
could
make
it
possible
that
they
would
be
able
to
implement
CCN,
but
without
that,
no
it's
not
possible
for
them
to
adopt
it.
E
I
have
to
question
whether
that
stops
the
proposal.
Advancing
though
I
don't
know.
If
we
need
consensus
around
every
single
client
to
be
able
to
move
something
forward.
C
Just
just
to
expand
on
those
two
things,
I
believe
the
discussion
with
relay
was
specifically
about
the
the
bang
being
removed
I'm,
not
sure
that
they
needed
to
remove
the
question
mark.
C
E
C
It
so
my
understanding
is
that,
because
of
the
the
excuse
me
because
of
the
fragment
boundaries,
they
would
need
to
strip
the
bangs,
because
otherwise
errors
thrown
there
would
pass
through
fragment
boundaries.
So
with
the
current
proposal,
assuming
that
we
don't
get
fragment
isolation,
which
is
obviously
a
separate
proposal,
then
they
would
need
to
strip
the
banks,
but
my
thinking
is
they
would
not
need
to
strip
the
question
marks.
They
can
send
them
straight
through
to
the
server
so
yeah.
This
is
an
interesting
discussion.
C
B
A
I
Syntax
he
aware
that,
like
box
strings,
for
example,
you
can
use
an
inquiries,
but
yeah
I,
don't
think,
can
you
buy
like
I
think
it
would
be.
The
first
big,
like
addition
to
query
syntax
with
the
subscription
but
for
subscription,
is
easy.
If
you
skip
my
appointment
subscription
root,
it's
been
like
you
can
use
subscription.
You
can
write
subscription
query
other
than
that,
like
syntax
was
mostly
the
same
as
release
time
so
like
for
everybody
for
directives.
B
Has
there
ever
been
a
situation
in
the
past,
in
which
this
has
been
a
problem
where
something
has
been
added
to
the
graphql
specification?
That
would
make
previous
servers
that
were
using
an
older
version
of
the
specification
not
be
able
to
parse
a
valid
query.
How
has
this
been
handled
before,
or
has
it
never
come
up
before.
C
C
Yeah,
absolutely
so
that
there
have
been
things
like
that,
where
the
query
isn't
valid,
but
there's
ways
of
detecting
what
that
is
and
I.
Think
that
the
for
other
things,
for
example,
like
imagine
that
we
didn't
have
include
and
Skip,
then
you
would
be
able
to
tell
that
they're
supported,
because
the
schema
explicitly
States
them,
because
the
directives
are
present.
C
B
Okay,
this
is
something
that
we
need
to
add
to
the
RFC,
then
right.
That
needs
to
happen.
So
that's
a
great
call
out,
Ivan
I
think
we
can
definitely
add
this
to
the
CCN
intro
RFC,
but
that's
a
whole
nother
question.
We
have
to
figure
out
an
answer
to
now.
I
I
Think
for
stuff
like
that,
it
should
be
actually
like
I.
Remember
one
thing
that
the
e08
book
strings
box
string
wasn't
like
with
three
quotation:
strings:
nobody
use
them,
but
technically
you
can
write
them
and
a
server
wouldn't
recognize
them.
Yeah
I
agree.
It's
like
it's
top
level
thing.
It
should
be
like
separate
I
shouldn't
be
booked
but
like
if
we
ever
release
it
or
make
my
PR
or
something
it
should
be
like
noted
to
people
that
use
them
upgrade,
say:
Gateway,
wait
or
proxy
or
anything.
E
G
Yeah
I
wanted
to
go
back
to
Ivan
objection
about
proxies
and
the
question
mark.
Basically,
if
I
understood
correctly,
what
you
said
was
if
any
of
the
downstream
servers
did
not
recognize
the
question
mark,
we
need
to
strip
them,
but
if
we
strip
them
then
the
downstream
servers
cannot
nullify
this
field
and
then
it
bubbles
up,
and
then
we
lose
some
data
yeah,
but
is
that?
G
Is
there
a
world
where
the
downstream
servers
schemas
do
not
match
one
one
with
the
proxy
one
like
you
could
have
a
given
schema
with
everything
knowledgeable
in
your
sub
graph
or
or
your
Downstream
servers,
and
because
there
is
stitching
there
are
directives
there
like
at
some
point.
We
need
to
to
assemble
everything
so.
I
A
I
The
introspection
is
to
a
catch
case,
but
even
if
you
forget
about
introspection,
people
have
an
example
of
oh
something
they
will
Stitch
with
the
red
proxied
or
something,
and
now
you
come
to
them
and
say
like
please
make
everything
newable
and
it's
not
only
on
this
side.
It's
like
they
need
to
go
through
code
base
through,
like
all
the
resolvers
typing,
call
like
how,
however,
they
generate
with
like
sub
graph,
think
and
change
it
I.
Don't
think
it's
feasible
like
why?
Why
I
ask
about
feature
detection
is
solution.
D
E
B
It's
you
know
there,
there's
the
what
Benji
put
here
this
little
code,
snippet,
there's
the
possibility
of
doing
something
with
an
individual
feature
flag
for
it,
but
I
also
feel
kind
of
concerned
about
having
additional
feature
Flags
just
continuing
to
be
added.
And
then
you
end
up
with
a
situation
where
you
have
features
that
dependent
on
other
features
that
work
together,
and
you
have
this
issue
of
like
having
to
continuously
check
for
each
thing.
B
And
if
you
have
things
like,
you
know,
routers
or
proxy
servers
of
any
sort
that
have
support
for
things
that
individual
subgraphs
don't
have
support.
For.
How
do
you
handle
all
those
things?
It
becomes
a
lot
more
complicated
and
I
wonder
if
it
is
better
to
version
the
scheme,
the
the
graphql
specification
I
mean
we
already
have
you
know
the
version
by
a
date
and
have
servers
indicate,
maybe
even
in
the
schema,
what
version
of
the
specification
they
support.
B
So
that
way,
if
we
add
CCN
in
you,
know
the
October
2023
version
of
the
spec,
any
server
that
conforms
to
this
2023
version
of
the
spec
has
CCN,
and
we
know
that
going
forward
in
the
next.
You
know
2024
February
version
or
whatever
that
CCN
is
still
always
going
to
be
there.
You
can't
have
a
situation
in
which
another
new
feature
was
added
to
a
server,
but
an
old
feature
was
never
supported,
yet
it
becomes
additive
and
incremental.
That
way
would
does
that
make
sense.
C
B
A
A
C
A
it
means
that
we
can't
experiment
with
features,
because
no
one
can
support
it
until
there
is
a
cut
version
of
the
spec
right
B.
It
stops
the
the
parallel
iteration
that
we
do
in
the
spec,
where
we're
working
on
CCN
and
we're
working
on
one
of
and
we're
working
on
this,
which
are
better
represented
with
features
but,
most
importantly
and
I,
think
this
is
the
really
the
more
important
Point.
C
It
means
that
we
can't
introduce
like
May
features,
or
at
least
we
don't
support.
May
your
schema
May
support
subscription
to
your
schema
May
support,
non-uh
client-controlled
null
ability.
If
we
have
feature
Flags,
your
schema
can
say:
yeah
I,
support,
client
control,
nullability,
but
I
don't
support
subscriptions
or
you
know
some
other
thing
so
I
think
it's
better.
Overall.
That
said,
I
think
we
should
be
very
careful
with
it
like.
C
There
is
no
need,
for
example,
to
indicate
through
the
feature
flags
that
one
of
us
supported,
because
there
would
be
the
one-off
directive
that
already
says
that,
and
that
will
be
the
case
for
many
different
things.
So
it's
only
in
the
case
where
it's,
maybe
a
syntactical
change,
or
something
like
that.
C
L
Yeah,
there's
there's
also
other
things
like
we.
We
did
a
lot
in
in
that
area,
no
like
the
last
couple
of
months,
and
there
is
like
we
do
in
our
multi-faced
introspection
to
see
really
what
features
the
server
has.
L
We
checked
for
single
features,
and
there
are
also
graphql
servers,
for
instance,
that
don't
allow
aliases
that's
why
it's
not
anymore
of
two-phase
introspection
that
we
do,
but
we
have
to
probe
for
certain
things
so
and
I
also
100
agree
with
like
it's
also
the
way
we
work
on
our
server.
It's
not
that
we
go
and
Implement
version
X
of
this
thing.
We
take
one
feature
we
implement
it
and
then
the
graphql
server
implements
that
feature
so
I
think
a
spec
version
is
too
big
of
I.
Think
to
problem.
A
E
Those
are
those
are
great
proposals,
so
they
just
take
this
back
to
CCN.
The
goal
is
to
get
this
to
the
next
stage
in
the
RFC.
It's
currently
at
stage
one
proposal
to
get
to
stage
two:
we
need
to
have
what
we
consider
a
fully
formed
solution
and
consensus
around
that
solution.
So
that's
the
main
Drive
of
stripping
this
back
to
the
basics,
so
that
we
can
form
consensus
with
this
very
narrow
scope
of
exactly
what
it
is
meant
to
do.
E
We
have
implementations
in
graphql
or
JS,
both
in
V16,
although
I
think
it
may
be
an
old
version
of
e16,
and
it's
now
in
the
newest,
v17
Alpha
I
believe
Alex.
Is
that
right?
Did
you
and
young
do
the
work?
For
that?
Sorry,
repeat,
the
question
is
the
CCN
changes
for
graphql.js.
Does
that
in
the
latest
main
take
against
17
the
latest
Alpha.
D
No,
those
are
I,
have
a
bunch
of
draft
PRS
up
for.
Are
you
talking
about
the
strip
back
version
or
the
the
yes?
The
stripped
back
version?
Yeah
I
have
a
bunch
of
draft
PR's
up
for
validation,
execution
and
Lexington
parsing.
E
Okay,
so
we're
working
to
get
that
into
the
latest
version
of
grad
cure
Js.
It
is
currently
in
Apollo
iOS,
but
not
on
that
latest
version.
So
there'll
be
some
work
to
do
against
there
and
I'm
not
sure
what
else
has
implemented
it.
But
those
two
should
allow
someone
to
have
it
working
for
them
in
an
app.
D
Yeah
for
the
original
version
that
included
the
question
mark
Lexington
Parson
is
merged.
D
I'll
I'll
link
the
PRS
I'm
talking
about
in
the
chat.
If
you
give
me
a
second.
B
I,
don't
wanna
extend
this
conversation
too
far.
I,
don't
think
we
should
be
making
decisions
on
or
diving
deep
into
this
feature
flag
stuff
today,
but
I
do
think.
We
need
to
be
clear
that
it
seems
to
me,
like
CCN,
is
directly
blocked
by
this,
and
this
is
a
Brand
New
Concept.
We
didn't
even
identify
until
today.
Right
do
we
need
to
like,
should
we
start
a
new
RFC
on
some
sort
of
way
to
handle
indicating
server
capabilities
and
feature
Flags
immediately.
D
Is
is
CCN
blocked
on
this,
for
all
clients
or
just
Advanced
clients
like
Apollo
and
relay
like?
Could
dumb
clients
use
it
I.
B
C
Hello,
they
can
use
it,
but
there
would
need
to
be
some
shared
knowledge
so
effectively.
Your
server
people
need
to
tell
your
client
people
that
they
are
or
are
not
allowed
to,
use
it,
and
normally
it's
the
schema's
responsibility
to
say
here
are
the
things
that
I
support,
so
a
client,
a
user
who,
in
their
you
know,
vs
code
or
whatever
they
write
a
bang
into
their
query
because
they
know
they're
allowed
to
do
that
in
general.
Can
now
write
a
query.
C
Maybe
it
can
be
code
generated
as
well
by
something
like
graphql
code
generator
without
that
actually
being
valid
against
the
SK
the
server,
because
the
sdl
has
no
representation
of
whether
or
not
the
server
actually
supports
that
syntax.
So
I
think
it
is
a
major
blocking
point
and
I
would
not
want
to
see
this
merged
into
the
spec
without
some
indication,
in
both
the
sdl
and
in
introspection
that
this
new
syntax
was
supported.
C
B
It
I
don't
know
if
we
need
to
get
deep
into
deciding
what
the
right,
syntax
and
right
way
to
handle.
This
is
in
this
meeting.
I
think
that
what
we
do
need
to
put
in
the
agenda,
the
notes
and
and
really
highlight
here-
is
that
CCN
we
can
figure
out
both
the
error,
handling
and
the
null
propagation
or,
if
we're
going
to
just
strip
it
back
to
only
the
bang.
B
We
can
figure
out
all
of
that
stuff,
but
this
proposal
is
not
going
to
move
forward
until
we
have
made
a
decision
on
this
language
features
or
feature
Flags
whatever
we
want
to
end
up
calling
it
is
Benji.
Does
that
seem
like
something
that
should
be
its
own
individual
RFC,
or
do
you
think
we
can
do
some
sort
of
handling
of
that
just
in
the
CCN
proposal?
To
me
this
seems
like
something
that's
way
too
far-reaching
to
be
tacked
on
to
the
CCN
proposal.
C
Yeah
I
I
hear
what
you're
saying
I
personally
think
that
it
would
be
bundled
in
with
this,
because
this
is
the
only
thing
that
needs
it
right
now,
but
we
would
have
to
put
our
you
know,
future
hats
on
and
think
about
what
other
things
might
need
this
in
future
and
design
it
in
that
way,
but
yeah
I
think
it
would
we
have
no.
C
There
would
be
no
value
emerging
that
other
RFC
on
its
own,
because
the
only
indication
it
would
have
is
that
CCN
is
supported,
like
that's
the
literally
the
only
feature
depending
on
what
the
solution
is.
If
it's
like
a
long
list
of
feature
strings,
then
maybe
it
does
have
value
now,
but
assuming
that
it
only
indicates
that
CCN
is
supported,
it
has
to
go
with
CCN
I.
Think
for
now.
C
C
D
I
wanna
I
wanna
push
back
on
the
idea
that
this
is
necessary
for
CCN
to
pass
I.
Think
the
group
we
have
gathered
here
is
represents
some
pretty
Advanced
clients
that
have
to
support
an
extremely
wide
range
of
use.
Cases
I'm
currently
just
a
developer
at
work,
and
if
I
need
a
new
thing
in
graphql,
then
I
talk
to
the
guy
next
to
me
and
he
does
it
and
then
I
implement
it
on.
D
You
know
my
client,
it's
it's
not
that
complicated
and
if,
if
we
we
started
supporting
CCN,
he
would
say:
hey
we're
supporting
CCN
today
and
then
I
would
go
and
use
it
in
the
client.
D
I
I
think
we're
returning
to
the
issue
that
we
had
prior
to
stripping
back
the
RFC,
which
is
that
we're
we're
trying
to
support
all
of
the
clients
and
all
of
the
servers
and
blocking
CCN
on
the
support
of
all
the
clients
and
servers
and
CCN
would
be
supported
by
a
smaller
portion
of
the
clients
and
servers
at
up
front.
But
then
later
that
you
know
the
the
the
the
pie
would
expand
with
these
additional
features.
I
A
I
Like
it's
a
fact,
Bank,
as
budget
said,
if
you
use
Bank
in
inquiry,
and
everything
is
good
until
you
have
a
runtime
matter,
but
it's
not
issue
an
approxy
proxy
like
proxies
is
at
least
like
in
experimental
stage,
can
just
strip
it.
And
it's
not.
It's
not
a
big
issue
so
like
for
proxy
to
support
like
Bank
you
stripped
independently.
If
client
supports
bank
or
not
supports
you
just
like
strip
it,
and
in
that
way
you
don't
need
to
do
feature
problem.
I
If
you
want
to
optimize
and
you
okay
with
future
problems
that
culture
code
using
quite
what
type
of
stuff
you
you
you
can
do
that
so
bank
is
not,
is
not
an
issue
for
proxies.
It's
it's
an
issue
like
with
developer
experiences,
but
but
it's
not
infrastructural
issue
but
question
mark
is
so
I
would
say
like.
I
B
Yeah
Alex
I
hear
what
you're
saying
and
I
mean
it
sounds
like
a
couple
of
people
are
agreeing
with
this
not
said
it
also
may
just
be
fine
if
the
server
doesn't
support
it.
If
the
client
fails,
it
just
does
which
isn't
too
terrible,
but
I
do
think.
There
is
something
to
be
said
about
this
being
the
first
time
that
new
syntax
is
being
added
in
a
way
that
thus,
you
cannot
understand
from
the
schema
if
it
is
supported
or
not,
and
whether
or
not
individual
clients
can
work
with
individual
servers
at
your
company.
B
The
the
graphql
specification
is
a
document
that
indicates
what
graphql
is
and
how
graphql
works
and
having
something
in
the
graphql
specification.
That
says
this
is
valid
legal
syntax
and
having
servers
that
purportedly
support
the
graphql
specification,
not
having
those
things
in
them
and
there's
no
way
to
indicate
that
is
I,
think
a
violation
of
the
specification
in
general
and
I
think
is
against
the
in
the
goals
of
creating
a
unified
specification
for
a
networking
protocol.
B
I
I
feel
pretty
strongly
that
we
have
to
be
able
to
indicate
that
I
know
we're
using
the
same
specs.
So
I
know
that
if
I
make
a
request
that
works
like
this
any
speed,
any
server
that
purports
to
in
use.
That
specification
can
accept
that
as
a
valid
request
and
if
it
can't
for
some
reason,
there
has
to
be
some
way
for
me
to
know
that
outside
of
like
two
developers
talking
to
each
other
at
the
same
company.
E
Okay,
maybe
15
minutes
was
a
bit
ambitious
for
this
discussion.
E
I
feel
like
we
have
enough
Direction
and
feedback
to
take
back
to
the
sub-working
group.
Is
there
anything
that
anybody
else
wants
to
raise
other
than
what
we
spoke
about
so
far
in
regards
to
CCN.
C
I
just
wanted
to
mention
that
I'm
not
sure
if
this
has
already
been
mentioned
in
the
chat.
In
fact,
I
think
it
has
to
as
a
scan
is
another
feature
that
would
require
this
would
be
fragment
arguments
because
that's
another
syntax
change
that
could
be
validated,
so
those
two
rfcs
both
would
need.
I.
Think
this
indication
and
I
think
that
how
we've
expressed
it
as
syntax
features,
rather
than
just
general
features,
is
probably
the
right
way
of
of
modeling.
This
and
I
don't
anticipate
that
we
would
have
altogether
too
many
of
them.
C
K
I
think
it
has
been,
but
that
proposal
hasn't
gotten
far
enough
where
it's
been
a
major
deal.
My
my
attitude
has
also
been
just
like.
If
a
server
doesn't
support
it,
then
the
server
will
fail
and
that's
kind
of
like
we
might
want
a
I,
do
think
that
there's
probably
some
value
in
a
server
being
able
to
basically
give
you
its
version
and
like
and
or
just
like
a
bunch
of
directives
that,
if
they're
defined
on
that
server,
it
means
that
it
supports
these
things.
K
That
all
seems
totally
reasonable
to
me,
but
also
like
it
just
doesn't
seem
horrible
to
allow
requests
to
fail
when
the
server
doesn't
understand
a
syntax.
That
we've
said
now
it's
in
the
spec
so.
I
I
If
you
wrote
something
you
have
like
immediate
feedback,
you
see
if
it's
valid
or
not
in
JavaScript
or
like
everything
languages
without
types
you
run,
and
you
see
and
if
you
forget
to
click
like
this
particular
button
in
UI
or
if
you
forget
to
open
this
particular
tab,
you
would
no
it's
like
yeah.
You
need
to
do
like
testing,
but
stuff
happens
so
I'm
like
I,
think
it's
like
shift
and
I'm,
not
an
not
in
good
direction,
but
yeah.
It's
not
the
I,
it's
developer
experience
I
would
say
it's.
K
A
I
D
I
C
So
I
personally
think
this
is
quite
important
and
also
it
ties
quite
nicely
into
I
think
what
Martin
will
be
talking
about.
C
Having
seen
Martin's
issue
raised
the
other
day
and
discussed
it
a
little
bit
on
Discord
talking
about
how
you
can
detect
what
features
the
schema
has
and
other
such
things
so
I
think
for
now.
Let's
switch
over
to
Martin's
agenda
item
and
maybe
come
back
to
this
other
discussion.
If
we
have
time
at
the
end,
perfect.
G
Transition,
thank
you.
Thank
you
very
much
Benji
and
also
thank
you
for
inviting
me
to
this
Mega
meeting.
It's
called
I'm
so
far,
so
let
me
do
a
quick
intro
of
what
I'm
working
on
so
I
saved
it
already
I'm
working
on
Apollo
kotlin,
which
is
a
client
basically
for
Android,
like
95
of
users,
are
on
Android,
but
people
can
use
it.
G
Kotlin
is
used
and
it
works
like
Apollo
iOS
and
like
graphql
content,
by
doing
a
code
generation.
So
the
user
drops
queries
like
this
is
a
somewhat
large
query
drop
the
schema
in
the
code
base
and
then
we
generate
stuff
like
this
well
yeah
I,
don't
want
to
go
too
much
in
the
detail.
It's
all
generally
the
code.
G
A
G
That's
good
so
here
there
is
like
a
red
on
the
lines
like
developers.
Do
not
like
this,
and
it
says
include
directive,
try
to
redefine
existing
directly.
That's
because
the
graphql
plugin
in
IntelliJ
here.
A
G
That
sdl
is
going
to
come
without
the
built
in
the
directive
and
it's
the
same
for
well
for
all
the
introspection
types
like
if
I
go
here,
the
same
thing
you
you
got
the
idea
we
apologetically.
We
need
to
know
the
version
of
introspection,
that's
not
supported
by
the
server
exactly
the
discussion
we
had
before.
But
on
the
other
hand,
some
tooling
does
not
want
them
and
actually
for
very
good
reasons,
because
if
you
go
to
the
spec.
A
J
G
G
Then
we
have
the
same
for
directives
here,
but
we
don't
have
anything
for
introspection
types,
which
is
my
points.
So
it's
a
tiny
baby
steps
into
making
these
features
available
to
to
lose
to
Tools
in
general,
like
if
we
add
this
to
the
spec
at
least
it
will
be
explicit
and
tools
like
the
graphql
IntelliJ
plugin
can.
G
So
that's
a
proposal.
I
can
put
the
link
in
the
in
the
chat
here,
and
this
is
all
I
have.
F
G
K
K
That
also
would
allow
you
to
have
a
graphql
server
that,
for
instance,
doesn't
support
floats
it's
like
none
of
the
types
I
have
I
have
no
representation
for
floats,
none
of
the
fields
I
give
you
will
have
floats,
none
of
my
input,
objects
have
floats
or
whatever
we
call
them
double
long
or
yeah.
I
think
we
call
them
floats,
but
yeah,
basically
like
it.
It
allows
you
to
have
a
strip
down
sdl
and
also
four
features,
as
Martin
is
pointing
out
four
features
that
are
like.
K
Oh
we've
added
the
directive,
like
the
specified
by
directive,
like
maybe
that
isn't
actually
supported
by
your
server.
You
don't
want
to
deal
with
supporting
that,
so
you
just
omit
it.
C
C
It
won't
be
in
the
STL
anyway,
so
we
don't
actually
need
to
indicate
that
there
is
no
floats,
but
for
your
second
point
with
the
specified
directive,
it
would
actually
help
to
indicate
whether
you
support
the
specified
directive
specified
by
versus
whether
you
already
had
a
specified
directive
that
you'd
defined
yourself
and
if
the
way
to
tell
that
is
to
see
whether
one
of
the
built-in
scalars
is
present,
because
those
have
to
be
you
know,
supported
or
whatever
then
I
mean
at
least
one
of
them's
got
to
be
thoroughs.
C
Yeah
string
has
to
be
there
because
otherwise
the
introspection
schema
doesn't
work
right.
So,
if
string
is
present,
then
you've
opted
into
telling
me
everything
about
your
schema.
Otherwise,
you've
opted
into
brevity,
in
which
case
we
keep
the
rules
that
we
have
and
I
wanted
to
expand
on
that
a
little
bit
more
as
well,
because
I
was
talking
to
Martin
about
this
over
Discord
and
effectively.
The
point
is
the
same
as
what
I
just
described
with
Matt,
with
the
float.
C
The
reason
that
the
introspection
types
in
the
schema
currently
is
because
there's
no
entry
point
to
them.
That
is
visible
in
the
schema,
because
the
entry
points
to
them
are
the
meta
fields
and
they
are
implicit
fields
which
means
explicitly
that
they
do
not
come
through
introspection,
so
type
name
type
and
schema
double
under
all
of
those
do
not
appear
in
the
fields
list
and
because
they
don't
appear
in
the
fields
list.
The
types
that
they
use
are
not
referenced
anywhere
in
the
schema.
C
So
there's
no
point
to
Output
them
with
the
sdl
so
effectively.
I
think
what
we'd
be
saying
here
is.
If
we
were
to
opt
into
the
more
verbose
form,
then
we
would
also
be
exposing
those
entry
points
and
I
think
that
that
would
also
have
value
because
it
allows
for
us
to
add
additional
meta
fields
that
don't
currently
exist.
So
I
think
there
is
a
lot
of
value
in
this
proposal.
If
we
push
it
in
the
right
directions.
I
just
wanted
to
surface
some
of
that.
C
I
I,
don't
think
so,
and
I
think
we
could
probably
fuzz
that
one
away,
specifically
specifically
an
exclusion
for
that
one.
K
There
might
also
be,
we
could
potentially
add
to
the
schema
object
so
like
the
schema
object
could
include
a
type
in
it.
That
is
like
meta
field
or
just
we
have
a
meta,
Fields
type.
I
It's
new
entity:
it's
like
a
camera
razor
we've
introduce
new
entities,
I
I,
actually
like
the
more
thinking
I'm
like
easier
for
underscore
everything
with
understanding,
because
otherwise
we
create
like
three
groups
right
now.
We
have
two
groups,
we
have
explicit
fields
and
we
have
implicit
fields
and
now
we
would
have
like
three
groups,
explicit
Fields,
implicit
printable
fields
and
implicit
non-printable
fields
which
is
like
also
but
for
cameras.
Instead
of
like
two
weeks,
our
three
types
I'm,
like
maybe
others,
can't
stop
type
name.
I
We
don't
add
like
description
and
it's
just
like
a
single
wine
on
every
object,
type
and
maybe
we'll
add,
like
I,
think
might
you
wanted
to
add
some
some
field
for
field
yeah.
K
J
K
Which
normally
just
aliases
to
ID
like
the
normal,
not
underscore
underscore
ID,
but
we
we
have
a
problem
where
we
have
types
that
have
an
ID
that
does
not
uniquely
represent
that
type
or
that
object.
So
we
have
to
actually
like
do
weirdly
different
things.
I
K
No,
it's
all
implicit.
It's.
K
We
we
actually
have
a
few
yeah.
We've
got
like
three
or
four
meta
fields
that
are
not
part
of
the
open
source
spec
that
are
hidden
because
we
have
an
ID
field.
We
have
like
a
a
key,
a
like
cache,
key
type
field
and
then
a
fetch
key
field,
because
those
might
not
be
the
same.
The
fetch
field
might
require,
like
hundreds
of
bytes
but
yeah.
I
Can
be
much
of
this
is
because,
like
we
basically
turned
in
every
conversation
about,
like
even
small
features
into
like
snowballing
like
it
starts
with
a
small
change,
and
it's
not
going
to
be
commodity
multi-year
proposal,
you
know,
like
I,
think
it's
incremental
stuff.
It's
not
changing
status
quo.
If
it's
set
for
directives
like
we
can
say
it
for
for
introspection
types.
K
Change
happened
relatively
recently.
I
think
we
used
to
allow
the
introspection
types
or
we
used
to
allow
not
not
underscoring
score
type
name,
but
like
the
scalar
and
oh
scalar,
string
and
whatnot
I
believe
it
was
a
relatively
recent
like
within
the
past
few
years,
change
that
we
said
it
must
no.
I
But
yeah
I
remember
it's
experimental
project
I!
Actually
I
did
like
printed
respection
schema,
plus
print
schema,
I
think
and
try
to
get
like
a
full
schema.
Yeah
I
needed
it
for
for
to
understand
what
what
is
supposed
supporting
in
his
server,
because
I
work
with
inter
expression,
queries
in
particular
I
need
to
know
like
types
for
them.
So.
L
But
I
think
what
Matt
proposed
is
a
good
way
out
of
the
problem
here.
Right,
I
think
the
the
underscore
underscore
type
name
for
me
would
be
also
the
thing
that
we
could
ignore
or
exclude
of
that,
and
then
we
have
like
at
the
every
other
field
could
be
in
the
in
the
spec.
Then
in
the
schema.
K
L
J
C
C
So
having
that
field
be
in
multiple
locations,
could
in
a
potential
hypothetical
future,
make
sense,
I,
yeah
I.
Think
that's
a
good
idea,
but
I
want
to
I
want
to
say
that
this
I
think
is
actually
two
separate
rfcs.
There
is
an
RFC
which
says
what
should
the
concise
sdlb,
which
is
effectively
what
Martin
is
doing
in
our
pr4
at
the
moment
and
then
there's
the
other
one,
which
is
what
does
the
full
sdo
look
like,
and
we
don't
currently
have
that
and
that's
going
to
be
a
much
bigger
change.
C
I
think-
and
my
argument
at
the
moment
is
that
in
Martin's
current
proposal,
I
would
say
that
the
concise
form
of
the
schema
should
not
include
the
introspection
types
so
because
I
think
that
is
I
mean
that's.
What
graphql.js
does
currently
I
think
that's
what
most
things
do.
I,
don't
tend
to
see
introspection
types
in
schema
files
unless
it's
been
specifically
engineered
in
a
custom
way
to
produce
that,
maybe,
for
you
know,
special
powerful,
tooling,
so
I
think
it's
I
feel
like
it's
a
must
to
not
have
it
yeah.
L
Because
then,
then
it
makes
sense
with
the
second
proposal
here
to
have
this
like
it's
either
there
or
it's
not
there,
because
then
it
must
makes
much
more
sense,
but
if
we
don't
go
for
must
it
should
be
a
should,
should
not
be
there.
G
Most
is
is
making
my
problem
worse,
my
immediate
problem
worth
because
I
can't
go
to
the
graphql
interviewee
plug-in
people
and
tells
them
to
expect
sometimes.
L
Yeah,
but
so
you
can,
because,
like
we
do
two
PRS
and
I
mean
you
can
already.
We
cannot
already
make
the
second
PR
Ok.
A
J
C
I
think
it's
big
in
terms
of
you
have
to
write
a
lot
of
words
to
explain
exactly
what
the
rules
are.
I,
don't
think
it's
big
in
terms
of
actually
changing.
Algorithms,
like
the
algorithms
are
all
basically
there,
so
it
is
very
much
just
it's
prose.
We
need
a
lot
of
Pros
there
to
explain
exactly
what's
going
on
and
why.
I
I
I
One
function
is
for
writing
servers
and
when
you
pass
sdl
with
introspection
types,
it
should
fail
and
second
function
is
like
build
Quant
HDL,
which
should
create
schema,
but
not
executable
schema,
but
with
really
resolve
the
fields
that
exist
in
sdl
and
nothing
more.
So
if
your
permutation,
for
example,
supports
like
one
of.
I
I
L
Graphic
interests,
but
but
this
depends
on
which
approach
you
like?
Are
you
doing?
Annotation
based,
makes
no
sense,
like
your
server
will
not
be
changed
at
all,
because
you're
not
even
using
a
schema
file.
A
L
Yes,
my
point:
is
you
don't
have
an
input
as
a
schema
like
like
what
you
pointed
out
is
okay,
when
you,
when
you
define
such
a
schema
and
load
it
into
your
graphql
server,
but
like
depending
on
what
approach
you
do
in
building
your
schema,
you
never
write
schema
file.
L
L
So
at
the
moment
like
introspection
is
the
one
thing:
if
you
try
to
to
modify
it
like
we're
allowed
to
modify
it,
but
then
you
have
to
be
explicit
about
that,
but.
A
L
I
Yes
same
same
with
graphqs,
and
it's
not
if,
if
I
dump
sdl
from
a
year
ago,
with
introspection
types
and
try
to
put
it
in
latest
version
of
hot
chocolate,
it
it
will,
is
a
favor
excitedly
ignored
by
those
types.
F
I
A
L
So
this
is
for
the
introspection
for
things
like
scalars
or
directives.
We
would
basically
say:
okay,
this.
You
are
trying
to
do
a
to
Define
here,
the
built
in
the
building
type,
for
instance,
string
you're,
defining
here
a
string,
scalar,
okay,
we
don't
allow
you
to
replace
it
here.
Is
our
string
Scala.
L
We
do
that
in
in
the
way
that
that
you
don't
introduce
things
that
are
defined
by
the
spec
and
introduce
non-spec
behavior
for
the
core
types.
Yes,.
F
I
Short
answer
for
you:
Martin,
even
if
we
change
his
back
and
even
if
people
change
validation,
I
expect
like
implementation
as
a
wipers
that
power
in
this
particular
plugin.
They
probably
need
to
do
a
code
changes,
Beyond,
relaxing
validation
rules.
They
need
to
do
separate.
Concepts.
I
I
L
L
I
G
L
L
G
I
guess
I
guess
my
question
now
is:
do
do
we
want
to
make
the
daily
step
and
and
see
later
for
the
rest,
or
do
we
want
to
do
everything
all
at
once
and
and.
L
K
I
guess
one
question
for
my
team
is:
what
would
be
what
prevents
Apollo
from
not
spitting
out
the
scalar,
int
or
scalar
string
or
the.
G
K
Yeah,
so
so
we
need
to
solve
this
in
one
of
a
few
like
there's
possible
paths
to
solve
this.
One
of
it,
like
one
of
the
possible
paths,
is
that
we
allow
full.
We
allow
full
description
of
the
full
schema
that
you
actually
support
and,
if
you're,
for
instance,
missing
one
of
in
it
or
you're
missing
at
at
specified
by
then
we
know.
K
Okay,
you
don't
support
that
we
can
validate
when
we
see
it
not
to
allow
you
to
do
that
and
then
the
other
one
is
like
for
every
new
feature
that
we
add,
we
add
some
flag
on
the
schema,
some
direct,
something
that
tells
us
hey.
This
is
actually
either.
This
is
the
version
of
graphql
that
is
supported
here
and
our
validation
knows
what
features
are
supporting,
which
version-
or
these
are
the
set
of
features
that
you've
opted
into,
and
we
can
actually
say.
Oh,
you
didn't
opt
into
the
at
specified
by
feature.
So
it's.
I
I
So
now
we
in
situation
where
there
is
like
chain
of
feature
clocks,
so
I,
like
current
approach
when
you
look
at
differ
and
see
like
if
it's
available
or
not-
and
there
is
no
like
separate
we're
not
at
like
separate
facts-
we're
not
describe,
or
in
Humes
or
strings
into
spec
and
saying
like
there
is
like
support
for
the
third
facts,
with
visible
without
variable
I'm
I'm,
like
future
I'm
strongly
for
future.
Only
for
language
features.
L
But
I
have
everyone
more
like.
Is
it
even
the
right
approach
to
do
that
with
the
schema
and
the
client
yeah
like?
Is
it
isn't
that
already
solvable?
Your
problem?
Was
the
standard
introspection
like
to
figure
things
out
and
then
create
a
config
file
that
just
has
all
the
features
aggregated
in
there
like?
This
is
what
we
detected
in
you.
G
But
that
config
files
that
you
are
mentioning
it's
basically
the
schema,
it's
graphical
language
and.
L
Yeah
I
think
could
could
be,
but
it
could
like
it's
a
for
instance.
What
we
do
in
in
distributed,
graphql
setups
is,
we
use
a
heavily
annotated
schema,
so
we
inspect
subgraphs
and
then
we
heavily
annotate
these
things
in
our
graphql
document
so
features
would
be
annotated.
For
instance,
we
use
this
schema
definition,
and
then
we
have
a
specific
directives
on
there
that
tell
us
what
the
subgraph
points
and
supports
and
I
mean
it
could
be
also
soft
in
that
way
and
to
have
it
much
quicker,
but.
L
G
L
L
A
G
A
F
G
G
I
mean
it's
new
directives
like
a
directive
that
would
be
specific
to
a
chocolate.
For
example,
that
says
one-off
is
reported
like
this,
and
maybe
RP
Al
Java
is
going
to
use
another
directive
that
is
specific
to
graphql
Java
and
every
Library
out
there
uses
their
own,
which
works.
It's
just
that
for
someone
that
is
reading
the
schema,
it's
weird
because
they
have
to
relearn
every
time
how
to
read
the
include
directly
formula
or
something
nice.
L
Now
the
include
directive
I
mean
is
these:
are
these
are
standard
things
but
like,
for
instance,
I?
Don't
know
there
are
a
couple
of
of
capabilities
that
you
could
annotate
like
I'm,
just
saying
that
there
are
multiple
ways
to
approach
this
problem
like
you,
don't
have
to
wait
for
a
spec
proposal
to
add,
maybe
also
a
lot
of
complexity
to
it.
It's
maybe
not
even
needed.
J
L
I
Have
a
jealous
first
class
citizen:
we
need
to
start
specifying
everything.
C
C
Should
be
able
to
tell
if
you've
got
a
graphql
operation,
a
graphql
document
and
you've
got
an
STL
file
that
defines
a
schema.
You
should
be
able
to
tell
whether
that
operation
is
valid
against
that
schema
and
for
non-introspection
things.
That
is
true,
excluding
what
we've
discussed
today
with
the
bang
and
with
the
fragment
arguments.
But
the
moment
that
is
true
until
you
put
introspection
Fields
into
your
query
into
your
document.
C
Once
those
introspection
fields
are
in
your
document,
you
no
longer
know
whether
they're,
supported
or
Not
by
that
schema,
because
there's
no
indication
of
what
that
is.
If
we
indicate
that,
whether
it
be
by
including
the
introspection,
types
and
Fields
into
the
scheme
into
the
SEO
or
whether
it
be
by
adding
schema
directives
like
Michael's
suggests,
which
is
also
a
perfectly
valid
way
of
doing
it.
C
It
doesn't
really
matter
so
long,
as
whatever
approach
is
standardized
and
I.
Think
I
agree
with
Martin
in
this
case
that
it's
much
easier
to
standardize
the
sdl
as
just
using
printing
the
introspection
schema,
because
we
already
have
rules
for
that,
whereas
if
we
were
to
standardize
it
by
introducing
the
schema
directives,
we
would
need
to
have
ones
that
indicate
every
single.
You
know
potential
field
that
we
might
add
at
any
point
in
the
introspection,
schema
and
I
think
that
that
could
become
more
cumbersome.
L
I'm,
just
I'm
just
thinking
about
it.
This
way
that
it
could
be
very
difficult
because
when
you
have
no
schema
like
I,
think
also
from
a
server
side
now-
and
that's
just
because
I've
been
talked
about
that
when
you
start
putting
introspection
types
in
there
like,
we
would
fail
and
like
what
does
it
mean
if
you
put
introspection
type
suddenly
into
the
the
schema
and
feed
that
into
a
schema
first
graphql
Server
doesn't
mean
that
I
want
the
introspection
system,
maybe
to
drop
fields
that
that
are
there
by
spec.
A
L
Yeah
I'm
just
I'm
just
I'm,
just
saying:
suddenly
we
have
to
also
deal
with
these
effects
because
you're
putting
that
you're
allowing
to
put
that
system
in
there.
So
we
also
have
to
deal
with
what
is,
if
a
graphical
server
loads
it
in
do
we
ignore.
It
could
also
be
like
we
specify
all
the
cases
around
that
like
ignore,
ignore
that
if
it's
red
and
it
can
only
be
for
client-side,
schemas
or
whatever
I'm,
just
saying,
there's
a
lot
of
complex
there's.
L
While
it
doesn't
have
like
a
lot
of
complication
to
me
in
the
first
place
like
there
could
be
an
impact
to
The
Wider
ecosystem
that
we
have.
C
Yeah
very
good
points.
This
has
been
an
excellent
discussion
and
I
think
it
has
blown
up
a
lot
more
than
Martin
was
expecting.
Nonetheless,
we
are
now.
C
K
Thank
you.
Everyone
welcome
one
very
quick
thing.
We
don't
have
a
meeting
scheduled
for
or
it's
not
on
the
agendas
list
for
next
month.
We
should
action
item
somebody.