►
From YouTube: Metadata Working Group - 2022-07-28
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
D
B
E
C
B
Well,
I
was
on
a
call
so
yeah
anthony's
in
vegas.
I
was
on
a
call
with
somebody
else
in
vegas
two
days
ago
and
they're
like
yeah.
A
It's
I
think,
114
degrees,
fahrenheit,
is
what
they.
F
F
C
You
know
most
houses
have
two
units
and
when
I
lived
in
seattle,
everyone
complained
like
I.
I
was
fortunate
when
I
moved
out
there
to
get
a
condo
or
apartment
that
had
centralized
cooling,
but
I
didn't
realize
that
most
people
in
seattle
did
not
have
that
most
people
just
have
heating
and
no
cooling
and
people
would
complain.
It
would
be
like
95
degrees
outside
and
was
like.
Oh
it's
so
hot.
I
can't
stand
it
and
I
would
just
laugh
at
them
like
guys.
E
G
B
All
right:
well,
I
guess
we're
going
to
talk
about
some
metadata
over
introspection,
all
right,
guys.
B
B
The
heat
all
over
the
place,
yeah
yeah
europe,
had
quite
different
parts
of
europe
had
quite
the
heat
spell
as
well.
So.
F
F
B
G
B
F
D
First,
I
didn't
specify
how
much
time,
how
much
time
this
meeting
will
take.
So
what
what's
your
time
limits
and
we'll
choose
ones
that
accommodate
everybody.
F
I
have
to
jump
off
in
an
hour,
unfortunately,
but
that's
just
me
and
I
can
catch
up.
D
I
I
would
I
would
go
with
the
input
union
approach
because
I
mean
it's
one
topic,
but
at
one
point
we
have
solved
it
like
with
the
other
sub-committees,
it's
more
like,
because
it's
ongoing
or
like
graphical
over
http.
We
are
constantly
adding
things
to
that
or
also
the
graphical
user
group
working
group.
D
Yeah,
so
I
also
feel
like
the
same.
Hopefully
it
would
be
like
short
sequence
of
of
a
calls,
and
we
come
with
solution
and
desired
outcome
is
not
separate
document
desired
outcome.
We
have
something
solution
to
a
problem
and
no
further
calls
so
yeah
and
by
the
way
we
can
start
group
at
any
point
third
issue.
H
D
Everybody
kind
of
familiar
with
input
union
work
for
how
it
was
done
with
input
right
or
maybe
like
anthony
or
euroman,
wasn't
part
of
his
working
group,
and
it
happened.
It
was
like
a
year
or
two
ago,
so
we
have
a
bunch
of
competent
solutions
for
one
time
and
we
basically
stuck
and
to
solve
this
issue
we
choose
to.
D
Instead
of
instead
of
having
like
compare
each
solution,
one
to
one,
we
agreed
to
have
one
definition:
one
problem
statement:
one
solution
criteria,
one
document
with
problem
statement,
solution
criteria
and
different
solutions.
So
each
solution
had
its
own
pr
or
issue
or
rfc
document,
but
it
was
one
common
place
for
to
solve
a
common
problem.
So
basically,
if
you
feel
like
we're
solving
the
same
issue,
we
create
document
describing
this,
and
I
discuss
different
technical
solution
to
the
same
problem
and
using
the
same
criterias
as
solution
criterias.
I
The
idea,
the
idea
is
really
good.
I
I
liked
the
way
input
union
went,
although
it's
not
solved
yet,
and
benji
comes
up
with
new
things
yeah,
but
but
in
the
end,
it's
it
got
such
a
good
big
picture
of
the
problem
like
what
what
do
we
actually
want
to
solve,
and
then
what
are
the
downsides
of
each
of
the
solutions
and
the
matrix
that
we
came
up
with
was
quite
good.
So
going
this
way,
I
would
also
support
that.
H
I
like
to
comment
so
what
the
emphasis
one
thing
that,
while
this
input
union
problem,
probably
something
I
would
say
nice
to
have
not
to
diminish
importance
anything,
but
this
problem
here
I
see
a
big
deficiency
with
kind
of
urgent
and
we
need
to
solve
it
kind
of
come
up
with
solution
and
go
because
this
is
something
that
is
a
big
surprise
for
people.
H
As
I
write
in
my
you
know,
post
on
this
subject
that
it
doesn't
work
this
way,
for
example,
that
it's
very
similar
this
facility,
or
even,
if
not
similar,
there
are
these
facilities
in
other
languages
platforms.
They
work
very
well
and
they
are
definitely
missing
in
graphql,
so
kind
of
from
the
point
of
view
of
urgent
urgency
and
need
that
kind
of
gives
me
hope
and
that
we
will
sow
it
quickly.
H
Hopefully,
as
for
different
ways,
probably,
as
I
said,
we
need
to
kind
of
explore
and
analyze
several
approaches
mainly
to
death
and
then
choose
which
one,
we
think
is
better.
H
D
My
point
core
idea
about
this
thing
is
to
have
common
problem
statement
and
command
solution
criterias
and
before
we
start
discussing
solution
like
competing
solution.
G
D
Need
to
agree
what
we're
solving
and
know
so.
This
is
like
approach
that
I
proposed
and
spent
like
first,
like
first
non-technical
agenda
items,
never.
I
I
always
I
also
wouldn't
mind
if
you
take
a
few
extra
rounds.
I
I
know
that
this
is
missing,
but
I
wouldn't
say
it's
that
urgent,
because
there
are
workarounds
for
that
and
we
did
a
couple
of
implementations
already
like
we
and
graphql
java
did
the
applied
directives
approach
and
it
has
a
couple
of
downsides
and
when
we
put
it
in
the
stack,
we
cannot
take
it
back.
So
we
shouldn't
rush
it
I
mean
that
there
are
workarounds.
D
I
It's
three
big
implementations
have
it
already,
but
I
mean
all
of
them,
have
it
as
an
opt-in,
so
I
wouldn't
say
it's
a
de
facto
standard.
H
Excuse
me,
my
code,
so
you're
already
implementing
this.
There
are,
and
you
present
it
as
work
around
when
framework
sort
of
framework
implements
that's
not
exactly
work
around
work
around
is,
if
I'm
doing.
I
That
works
no!
No,
I
I
I.
I
No,
it
doesn't
work
there.
There
are
a
couple
of
there
are
a
couple
of
so
you
can
implement
something,
but
then
you
see
the
problems.
There
is
good
advice
like.
I
If
you
look
at
language
designer
c-sharp
designers,
they
try
things
out,
and
sometimes
you
you
see
that
it's
not
good
and
you
pull
it,
and
this
is
one
thing
where
I
found
in
the
implementation
detail
with
double
serialization
and
things
like
that
that
it's
actually
not
nice
to
use
and
has
a
couple
of
problems
that
you
only
discovered
on
runtime,
where
you
could
have
a
fully
static
solution,
but
I
mean
that's:
that's
already
the
details
we
should.
We
should
go
through
and
that's
why
I,
okay.
I
I
think
we
should
iterate
over
that
correctly
with
workarounds
I
mean
the
the
workarounds
that
we
have
like.
If
you
look,
for
instance,
apollo
federation,
they
essentially
wrap
the
sdl
and
transport
it
over
the
the
service
layer.
You
can
essentially
fetch
the
sdl
over
graphql.
I
We
do
something
similar
for
for
for
schema,
stitching
and
things
like
that
relay
has
client-side
schemas,
where
they
put
that
and
put
their
things
in.
So
there
are
workarounds
different
workarounds
for
each
framework,
so
I
didn't
mean
applied
directive
as
a
workaround.
That
was
like
an
experiment
to
see
if
that
works
out.
I
Yeah,
okay,
but
it
doesn't,
I
I
think
it
doesn't,
but
I
think
we
should
discuss
that
and
that's
why
it
would
be
good
to
have
the
matrix
to
see
what
actually
is
not
good
with
this
approach
and
what
would
a
different
approach
bring
us
more
or
what
what
benefits?
Would
we
get
from
that.
H
May
I
suggest
one
more
thing
that,
for
example,
one
one
problem
I
think
we're
facing
with
any
approach,
at
least
with
the
applied
directives
and
metadates,
is
the
problem
of
returning
input,
types
and
and
type
wells
and
so
on,
and
I
think
we
we
should
when
we
talk
of
either
solution,
we
should
kind
of
establish
that
this
is
problem
for
any
solution
right
and
probably
expressed
that
that
should
be
become
an
issue
in
general.
A
separate
issue
looks
like
there
is
a
need
for
this.
I
That's
what
that
needed
that
that's
actually
I
mean
I,
I
just
read
your
comment
on
the
discussion.
That's
one
of
the
reasons
why
we
have
this.
As
so,
you
essentially
say
this
input
is
represented
as
that
output.
I
That
is
one
of
the
solution
approaches
that
is
there
for
this
there's
another
one
that
benji
is
working
on
struct,
for
instance,
that's
a
more
generalized
way
where
you
say:
okay,
we
have
object,
structures
that
exist
on
the
input
and
on
the
output
has
also
downsides
has
plus
sides.
I
mean
all
these
things
have
and
that's
why
I
think
it's
important
to
look
at
that
closely,
because
that
could
be
a
solution
also
for
other
things.
I
agree.
D
I'm
proposing,
like
criteria
that
we
judge
final
solution
so
like
in
the
first
round.
We
after
we
define
like
criteria
and
define
solutions.
We
assume.
D
You
can
add
anything
to
graphql
spec
like
extract
and-
and
we
discuss
like
because
it
creates
a
loop
basically
like,
for
example,
when,
let's
use
bunch
of
purposes,
we
discuss
it.
D
Solution
for
for
metadata
required
you,
new,
struct
and
introspection
is
one
of
the
use
case
for
forward
struct.
So,
instead
of
focusing
on
it,
let's
assume
we
can
add
anything
to
spec
and
when
we
finalize
it,
we
basically
like
see
if
this
feature
can
be
added
into
his
back
or
not.
D
D
D
D
D
Is
that
it's
like
types
of
isomorphic
types
that
work
both
as
input
output
is
a
at
s
is
a
like
some
other
solution,
so
I'm
proposed
before
we
dive
deep
into
thing.
D
I
Even
if
you
already
have
something,
why
don't
you
just
share
it
and
then
we'll
go
over
it
and
maybe
add
things
yeah?
I.
D
E
I
imagine
excuse
me,
I
imagine
that
the
discussion
will
be
get
getting
quite
interesting,
so
help
on
taking
the
notes
on
this
would
help
us
to
capture
any
changes
that
need
to
be
made.
So
please
I
have
sent
the
the
google
doc
link
into
the
chat
so
do
open
that
up
and
and
type
in.
E
I
don't
see
in
there
that
the
metadata
should
be
representable
like
nicely
in
sdl.
I
know
you've
said
it
as
part
of
introspection,
but
I
wonder
whether
that
one
was
accidentally
missed.
D
E
I
know
you
and
I
have
discussed
it
many
times,
so
it's
definitely
needed
yeah,
one
of
the
things
that
we
did
when
we
were
doing
the
input
unions
is
we.
We
came
up
with
these
criteria
and
then
we
gave
them
weightings
now.
The
weightings
are
very
controversial
because
different
people
think
that
their
their
thing
is
the
most
important
thing,
whereas
other
people
think
that
it
doesn't
matter
at
all.
E
So
we
kind
of
tried
to
do
it
based
on
a
kind
of
a
consensus,
but
I
think
it
was
the
the
champion
in
the
end,
who
decided
what
those
waitings
are.
So
I
imagine
there'll
be
some
fun
discussions,
but
what
I
will
say
is
in
the
early
stages
of
input
union.
What
we
did
is
we
just
came
up
with
all
the
criterias
that
we
thought
we
might
want.
E
We
did
not
filter
them
based
on
quality,
we
didn't
argue
about
them,
we
put
them
all
in
the
document
and
then
we
went
through
afterwards
and
said.
Actually
I
don't
think
this
is
something
we
care
about
or
this
is
you
know
this
is
a
nice
to
have,
but
whatever
or
like
yeah.
This
is
obviously
critical
like
we
cannot
have
a
solution
that
doesn't
pass
this
criteria,
so
I
suggest
that
we
do
that
same
pattern.
H
D
Yeah,
it's
not
a
location,
okay,
yeah,
and
so
I
need
to
suggest
you
all
the
same
with
benches.
So
if
you
I've.
E
Copied
these
into
the
google
doc
for
the
notes
awesome,
so
we
can
like
start,
maybe
editing
around
that
if
that
makes
sense,
yep.
D
Yeah,
so
let's
start
from
the
first
one
and
feel
free
to
stop
and
suggest
in
the
process.
So
also
node
order
is
like
random.
It's
not
list
of
priority
lists,
so
first
one
it
should
be
possible
to
substract
metabolic
values,
ideas
that
I
have
yeah.
H
And
I
I
would
probably
point
out
again
that
I'm
coming
from
my
my
big
foundational
point
is
comparing
to
net
attributes
and
similar
things,
and
there
is.
There
is
a
good
reason
for
this,
because
these
things
look
alike
and
they
are
very
successful
there
and
they
are
not
very
over
complicated
first
thing.
I
argue
that
what
we
are
adding
through
directives
directives
is
not
a
metadata,
it's
just
pieces
of
custom
data.
H
They
are
not
meta,
they
are
attached
to
metadata
elements,
but
it's
custom
data.
It
can
be
labeled,
it
can
be
any
hey
hello
from
me.
You
know
anything,
it's
not
meta
and
I'm
I'm
afraid
that
calling
the
metadata
it
skews
our
thinking
into
one
direction.
Oh,
it
should
be
just
like
underscondosco
type,
or
it
should
be
something
like
this.
No
it's
random
crap
and
it
enables
developers
in
limited
groups
like
server
clients
or
service
framework
and
implementation
to
trans,
to
create
a
custom,
mini
contracts
and
send
kind
of
information
to
each
other.
H
D
Let's,
and
can
I
suggest,
we
go
point
by
point
because
if
couple
points,
especially
if
if
they
separate
discuss
it's
hard
to
respond
so
yeah
on
the
first
point,
why
I
call
that
metadata,
so
data
is
what
is
exposed
by
server.
So
in
the
case
like
you
have
graphed
like
they
are
representing
books
book
title
book
number
after
it's
a
data,
everything
about
with
data
is
metadata,
so
by
metadata
I
mean
it's
just
like
academic
definition
of
metadata.
So
it's
data
about
data,
so
any
crowd.
You
are
any
to
a
field,
an
argument.
I
D
Okay
and
to
quantify
what
what
you
think,
what
you
say
about
yeah,
so
I
explicitly
try
not
to
mention
directive
in
solution
criterias
directly
awaiting
solutions,
because
here
we
should
not
disagree.
I
Can
I
just
interject
to
we
should
we
should
speed
that
along?
I
think
we
should
just
go
through
them
and
and
not
reject
them.
Like
benji
said,
let's
just
collect
them
and
do
a
second.
G
I
And
then,
then
we
can
discuss
why
it
shouldn't
be
a
criteria
or
why
it
should
be
a
criteria.
D
D
And
to
be
fair
and
to
not
create
pressure
or
on
the
rejecting
something,
I
will
add
the
nodes
saying
they're
not
final
and
can
be
removed.
H
D
D
D
You
cannot
include
like
current
date
is
metadata
because
proxy
of
schema
stores
or
like
documentation,
generation
stuff
like
they
need
to
be
able
to
dump
metadata
and
to
to
describe
it
in
more
like
hard
terms,
basically
requirement
here,
you
dump
metadata
and
you
can
generate
exact,
same
response
for
introspection
query
as
target
server,
because
technically
you
cannot
dump
introspection
right
now,
because
you
can,
you
can
follow
types,
you
can
create
the
cycles,
but
basically
you
can
dump
enough
information
to
generate
all
possible
responses.
E
I
think
you've
actually
got
two
topics
there,
you've
got,
it
should
be
possible
to
dump
it
all
and
also
it
should
be
static.
So
I've
added
l,
the
metadata,
must
be
static.
D
For
example,
what
would
be
example
of
being
able
to
dump
with
I
mean
okay.
E
C
E
C
D
Yeah
and
like
in
my
point
b,
I
provide
criteria
you
you
should
be
able
to
dump
stuff
in
criteria,
don't
involve
version,
so
you
done
stuff
and
you
generate
responses
if
between
dumps,
something
change,
it's
okay,
but
if
server
operates
on
the
same
thing
and
you
and
the
server
receive
the
same
introspection
where
you
should
be
able
to
generate
the
same
response.
D
D
D
Metadata
should
be
typed
and
respectable.
I
specifically
don't
say,
input
output
type.
It
should
be
typed.
G
D
F
D
D
Experience
is
like
different
directive
can
have
the
same
name
but
different
like
meaning
so
directivity
key
can
be
used
for
like
different
stuff
and
have
different
meaning
for
scours.
We
solve
it
by
using
specified
body.
D
I
E
I
added
the
type
sand.
I
was
wondering
why
why
values
specifically
or
do
we
have
an
idea?
What
values
are?
Should
we
just
remove
the
word
values.
D
No,
no,
I
idea
was
exactly
right,
like
the
values,
because,
because
roman
was
speaking
about,
map,
mass
solution
and
map
have
a
key
so
either
like
fields
or
keys
or
something
like.
If
you
have
metadata
called,
I
don't
know
like
experimental.
D
D
Yeah
and
switch
to
next
one
or
by
the
way
like
important
thing,
is
to
clarify
that
so
we're
on
the
same
point
so
yeah,
I
agree
with
better.
We
should
not
discuss
it.
Is
it
like?
Should
we
remove
it
or
change
yeah,
but
here
like,
if
you
don't
understand
what
what
I
meant
by
that,
please
feel
free
and
we
discuss
it's
like
what
we're
doing
right
now.
I
D
Is
intended
for
for
things
that
compose
schemas,
so
we
should
not.
We
should
not
expose
it
further.
It's
like
implementation
detail,
for
example,
if
we
use
like
schema's
teaching
can
use
some
some
metadata
to
define
schema
stitching
with
direc
with,
like
metadata,
should
not
expose
further.
D
So
we
need
some
mechanism,
future
mechanism
mahogany's
to
control
what
exposed
what
not
expose,
what
what
exposed
to
short-term
user,
but
not
others
users.
So
some
metadata
can
be
part
of
like
a
private
api,
some
public
ipa,
and
we
need
some
mechanisms
to
specify
that
not
in
spec
but
as
like
as
part
of
solution.
D
Yeah
and
age
this
is
specifically
added
based
on
discussion
with
roman
is
in
implementation.
Details
shouldn't
be
exposed
as
metadata.
It's
not
about
secrets
it's
about.
We
should
not
expose
all
the
crap
we
have
on
the
server.
D
So,
and
and
basically
end
of
my
list,
so
we
go
further
all
right,
I
it
should
be
representable
ssd.
We
already
discussed
it.
I
think
it's
the
most
uncontroversial
one,
so
everybody
agree.
Sdl
is
first
question
my
support.
E
If
I
can
interject
for
a
moment
since
I
added
most
of
these
yeah,
I
wanted
to
to
comment
that,
in
the
input
unions,
working
group,
part
of
this
exercise
isn't
necessarily
to
find
out
what
all
the
solutions
are,
what
all
the
goals
are,
but
also
to
find
out
what
some
of
the
non-goals
are.
E
So
some
of
these
I've
deliberately
stated
as
if
they
would
be
a
nice
to
have
when
actually,
we
probably
don't
want
them,
we
don't
care
about
them
or
we
explicitly
do
not
want
them
to
be
solved
so
they're
more.
There
is
talking
points
than
necessarily
things
that
we
should
have.
Polymorphic
data
is
one
that
should
be
discussed,
I'm
not
sure
if
there
is
a
need
for
it,
but
it
is
if
we
decide
to
not
support
polymorphic
data.
That
is
definitely
a
decision
that
we
are
taking,
so
we
should
think
about
it.
E
Multi
large
data,
like
megabytes
of
data
like
base64,
encoded
images
or
large
pros,
mirror
documents
or
whatever
they
may
or
may
not
be
suitable
to
go
into
the
schema.
Now
graphql
doesn't
actually
put
any
size
limits
on
things,
but
when
we
evaluate
things
we
should
at
least
have
in
mind
how
we
intend
it
to
be
used,
because
if
you
do
want
large
multi
megabyte
things
to
be
in
the
metadata,
then
part
a
sub-selecting
metadata
values
is
going
to
be
critical,
so
you
don't
have
to
pull
that
down
every
time.
E
I
put
in
m:
it
should
be
clear
if
changing
metadata
will
break
clients
really,
that
is,
we
need
to
figure
out
what
changing
metadata
means.
Is
it
a
breaking
change?
Can
we
change
metadata
to
anything
and
it's
not
seen
by
graphql
as
a
breaking
change,
but
if
you
have
your
own
contract,
then
that's
your
problem
to
govern,
or
is
there
a
more
spec
level
idea
of
breaking
changes
like
the
idea
of
changing
a
field
from
nullable
to
non-nullable,
or
vice
versa?
E
We
we
know
concretely
whether
that
is
breaking
or
not,
so
we
at
least
need
to
evaluate
that
and
know
what
our
stance
is.
Should
it
allow
the
any
data
type?
I
think
again,
this
is
a
broader
topic
and
if
you
need
that
you
can
just
use
something
like
a
json
scalar,
but
nonetheless
I
want
to
put
it
in
there
for
discussion
and
explicitly.
E
I
think
we
shouldn't
allow
it
so
though
I
added
it
I
put
reject
underneath
and
also
should
it
allow
for
dynamic
data
like
should
we
be
able
to
return
the
current
time
from
one
of
the
introspection
fields
should
we
have
fields
that
can
accept
arguments
in
the
introspection,
and
I
explicitly
think
the
answer
to
that
is
no,
because
it
prevents
the
static
dumping
and
the
full
dumping
of
the
metadata.
I
C
Yeah
sorry,
my
point
is
that
I
just
explicitly
saying
we
don't
want
any
introspection
fields
that
take
arguments
may
or
may
not
be
a
fair
assumption
to
make
like.
Yes,
we
do
want
to
be
static,
given
the
same
arguments,
you
always
get
the
same
values
and,
though
that,
like
that's,
derived
from
a
type
name
that
you
get
from
another
part
of
the
introspection,
but
it
does
seem
odd
to
me
to
say
no.
We
should
not
allow
any
arguments
when
we
already
have
an
introspection
field
that
does
have
them
yeah.
I
C
I
The
the
thing
how
I
understood
benji
is
that
you
don't
specify
like
dynamic
metadata,
that
expose
dynamic
arguments
that
then
produce
dynamic
values.
In
that
way,
I
and
that's
what
I
understood.
H
E
H
D
You
should
be
able
because,
like
for
example,
we
can
create
mapping
plus
one,
if
you
specify
one
you
receive
to
if
you
specify
two
years,
you're
free,
but
we
cannot
replicate
it
automatically.
So
if
you
dump
introspection
and
run
your
own
server
or
proxy,
you
cannot
replicate
that.
So,
basically,
it's
not
only
you
receive
the
same
output
for
the
same
input.
It's
also
damping
introspection
should
be
enough
to
replicate
this
result.
G
D
Because,
like
that
underscore
underscore
type
is
good
example,
introspection,
query
standard
and
the
expression
query:
don't
use
underscore
underscore
type.
It's
used
on
this
quantum
schema
and
it's
contained
in
our
data
to
to
power
that
underscore
underscore
time.
D
So,
if
we
decide,
for
example,
applied
directives
can
have
arguments
specifying
a
list
of
directives
to
return.
For
example,
we
can
implement
some
selection
that
way
it's
it's
okay
or,
for
example,
each
directive.
D
I
G
C
Are
there
any
other
criteria?
We
want
to
add
here.
H
I
Yeah
directly,
we
should
we
should
specify
them.
Then
I
mean
and
that's
have
you
read
the
document?
That's.
I
I
Have
familiarity
I.
H
D
D
Can
we
formulate
it
in
a
sense
like
readability,
so
a
person
who
starts
with
graffiti
and
she
next
year?
It
currently
is
here.
Yes,.
H
G
I
Because
there
are,
there
are
concepts
like
also
with
attributes
like,
for
instance,
you
didn't
like
the
first
first
of
the
principles
here,
roman.
I
think
that
you
should
have
sub
select
in
c
sharp.
You
don't
need
that
because
you,
you
always
have
the
object
in
memory,
but
in
graphql.
That
is
one
of
the
core
values
that
you
can
say.
C
Agrees
with
you
there
that,
like
as
much
as
possible,
we
should
reuse
the
principles
and
the
concepts
that
we
that
already
exist
in
graphql,
but
I
think
what
michael
schrein
was
trying
to
say
is,
if
we're
going
to
say,
we
want
to
follow
the
preconceived
notions
and
best
practices
and
guidelines
of
graphql.
Then
we
need
to
outline
what
those
are,
or
else
saying
that
kind
of
just
isn't
really
valuable
or
helps
anybody,
and
if
we're,
if
we,
we
can't
really
outline
what
those
are
until
we
have
proposed
a
solution.
C
So
I
think
that,
naturally,
that
conversation
is
going
to
come
up
as
we
look
at
the
proposed
solutions
and
say
this
solution
might
be
better
or
tweaked
naming
or
design
wise
to
follow
these
same
principles
or
practices
that
we've
used
about
graphql
in
the
past
to
maintain
familiarity,
but
that
adding
that,
as
an
a
blanket
statement,
is
overly
broad
without
any
specific
solution
that
we're
talking
about
like
how
we
want
to
do
that
to,
and
it
may
or
may
not
apply
to
any
specific
solution
so
making
it.
It's
not
that
no.
C
H
D
To
try
to
capture
maybe
your
intention
as
a
couple
separate
criterias,
like
one
of
the
principle
we
have
in
gracier,
is
not
surprise
person.
So
when
a
person
preaches
year,
he
can
understand
what
he's
seeing
without
treating
a
spark.
It's
a
general
idea
acquiring
look
like
response.
You
can
explain
concept
it's
easily
so
like
breathability
and
by
the
way
directive
in
in
that
sense,
like
have
a
clear
advantage
of
saying
going
you
you
can
understand
what
what
it
is
so.
C
C
Yeah
yeah,
I
think,
we're
all
in
agreement
that
we
should
try
to
follow
that
principle.
It
just
doesn't
seem
applicable
on
a
broad
sense
here.
H
But
for
a
again
again,
I
I
doubt
it
should
be
the
criteria
sub
about
sub
selection.
Again
it
it
all
depends
how
much
we
expect
and
again
writing
on
knowledge
from
20
years
of
math.
There
is
not
much
very
few
attributes
is
enough
or
whatever,
and
we
are
kind
of
assuming
there
would
be
a
lot
and
also
falling
on
vengeance.
Notion
would
be
megabytes
or
so
on.
H
I
I
I
In
the
case
of
apollo
federation,
they
have,
for
instance,
these
field
sets,
which
is
essentially
a
selection,
set
that
you
can
define
in
the
key
attributes,
and
that
is
essentially
graphical
syntax
and
that
can
add
up
like
if
you
have
a
lot
of
them
and
distribute
them.
And
I'm
just
I'm
just
outlining
here
something
and.
I
I
E
I
also
think
that
there's
a
lot
of
metadata
that
can
appear,
especially
when
multiple
schemas
are
merged.
Together,
I
mean
places
like
netflix,
have
like
hundreds
of
different
graphql
schemas
that
are
merged,
and
you
may
add
metadata
of
like
here's,
where
this
field
came
from
or
what
is
where
it's
modified.
By
and
what
information
you
need
and
keep
in
mind
that
introspection
isn't
only
used
to
represent
what
the
schema
is.
It
can
also
be
used
at
runtime
to
do
things
like
populating
drop
downs
when
you're
populating
a
drop
down.
E
I
D
I
I
also
like,
like
just
just
to
point
sorry
for
interject
just
point
to
your
company.
I
It's
also
at
microsoft.
I
talked
to
darren,
for
instance,
from
the
microsoft
graph
team
and
they're
also
stitching
at
the
moment
all
data
endpoints,
but
they
are
also
thinking
about
how
they
move
to
graphical
and
how
this
could
be
composed
there,
and
they
would
run
into
the
same
problem
statements
that
we
just
outlined.
D
D
I
build
like
this
directory
like
it's
thousands
of
open
ipad
definitions
and
people
put
a
lot
of
crap
there
like
a
lot
of
things,
quite
specific
things.
For
example,
there
is
one
vendor
called
automatic.
They
generate
sdks
code
based
on
open
api
definition
and
they
literally
put
configuration
for
every
programming
language
in
the
open.
Ipad
definition,
so
expect
same
happening
will
happen
here.
D
People
I
will
put
things
specific
for
like
craft
or
a
particular
language
in
the
schema,
and
especially
since
cogeneration
is
a
big
thing
now,
for
example,
that
thing
should
be
configurable
by
person
who
generates
code
by
client,
but
people
will
want
to
specify
code
generation
specific
thing
things
like,
as
benches
said,
to
represent
stuff
translation.
Things
like
avenger
use.
Good
example
in
our
discussion
about,
like
translated,
brings
a
description
in
different
language,
so
with
description
right
now
in
one
language,
people
will
want
to
use
metadata
for
description,
different
languages.
D
H
H
Because
let
me
tell
you,
I
I've
been
through
this,
for
example,
and
in
order
to
let's
say
you
find
a
typo
in
some
translation,
they
tell
you.
So
if,
if
you
have
it's
in
attributes
or
or
in
directives,
it
means
that
you
have
to
rebuild
and
redeploy
everything
because
of
one
single
typo,
and
there
were
cases
when
you
know
microsoft
had
to
burn
a
million
disks
from
because
of
one
typo
in
the
name
of
one
country.
D
Yeah,
but
this
implementation,
you
can
store
that
in
database.
You
can
serve
it
metadata
by
the
way
like
we
didn't
specify
that
it's
another.
G
I
The
main,
the
main
use
case-
I
I
really
see-
is
really
distributed
schemas
and
they
use
today
already
a
lot
of
metadata
that
that's
what
I
just
wanted
to
point
out,
but
we
shouldn't
get
stuck
on
the
topics.
Yet
I
think
when
we
have
concrete
proposals,
we
can
do
in-depth
discussions
because
huge
is
already
gone
and
do
we
do
we
wanna
do
a.
I
G
C
Yeah,
the
only
other
thing
I
would
like
to
add
is:
I
think
that
we
need
a
more
specific
story
about
why
this
is
useful.
What
the
use
cases
here
are
like
the
graphql
guiding
principles,
do
say:
favor
no
changes
and
cater
solutions
to
use
cases
and
right
now.
I
personally
understand
that,
like
apollo
federation
is
a
use
case
for
this,
but
if
that's
the
only
use
case,
I'm
not
sure
how
compelling
it
is
and
for
people
who
are
coming
in
and
looking
at
this
rfc
that
don't
work
at
apollo.
C
I
I
I
I
I
didn't
that
just
to
point
out,
it's
not
apollo
in
specific
it's
distributed,
schemas
as
a
whole.
There
are
hazura.
My
company
is
doing.
That
apollo
is
doing
that
like
it's,
it's
one
of
the
use
cases
distributed
schemas,
where
it's
very
useful
to
have
metadata.
So
it's
not
just
apollo.
It's
like
a
whole
bunch
of
companies
that
doing
similar
kind
of
products.
C
Definitely
if,
if
the
only
use
case
we
can
come
up
with
is
for
distributed
systems,
then
I
think
that
is
an
important
thing
to
recognize
is
like,
let's
cater
this
towards
that
specific
solution.
If
it's
not
and
we
can
come
up
with
other
use
cases
that
may
be
far
more
arbitrary
and
expansive,
then
we
should
come
up
with
other
use
cases
and
give
examples
so
that
we
are
know
designing
this
with
what
we're
actually
intending
to
solve
in
mind.
H
By
the
way,
I
think,
regarding
distributed
and
large
schemas,
this
is
prop.
I
suspect
this
currently
what
we
have
a
workaround,
because
this
is
a
separate,
big
problem
waiting
for
solutions,
but
we
saw
with
with
extra
metadata
or
I
believe
there
must
be
some
real
solution
for
this.
So
we
have
to
keep
this
in
mind.
D
Another
example
of
stuff,
I
think,
like
stuff,
that
people
volunteer
to
write
is
a
run
subcommittee.
Yes,
yes,
schema
composition
is
a
big
use
case.
Another
use
case.
It's
like
experimental
idea
that
experimenta
or
like
there
is
resources
here
for
or
adding
feature
tracks.
It's
the
same.
We
need
that
paradox.
You
need
it
for
warnings
and
a
good
source
of
use.
Cases
is
like
an
issue
about
exposing
directives
that
all
created.
G
D
I
D
I
D
H
Just
be
active
on,
let's
just
be
active
on
the
threads
of
discussion.
Let's
agree,
yes,.
D
H
Except
one
thing
I
I
I
thought
technically,
it
might
be
better
for
discussing
issues,
maybe
instead,
that's
why
I
studied
separate
with
directives
purely
directives
right
so
keep
in
mind.
I
hope
it's
okay
right.
Can
we.
I
Yeah
input
units
we
did
the
same
thing
essentially
like
we
had
separate
documents
for
the
separate
proposals
in
the
end,
so
we
should
have
one
document
where
we
outline
the
points
that
we,
the
criterias
and
stuff
like
that,
like
an
overview
also
in
into
these
things
and
then
separate,
because
if
we
discuss
competing
solutions
in
the
same
thread
or
in
the
same
discussion,
it
becomes
very
confusing,
I
would
yeah.
I.
D
D
Ukraine
glory
to
the
heroes.
It's
like
a
ukrainian.
D
Else
before
we
finish
yeah
so
right,
very
safe
yeah
thanks
thanks
everybody,
but
yeah.