►
From YouTube: GraphQL Working Group - June 11, 2020
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
A
B
B
C
D
We'll
give
people
a
couple
of
minutes
to
filter
in,
since
our
attendee
list
is
a
little
bit
bigger
than
the
set
of
folks
here
here.
Right
now,
also
just
a
reminder
that
if
you
haven't
added
your
name
to
the
agenda
office
and
a
quick
pull
request
and
I'll
just
be
merging
four
requests.
Gonna
take
a
couple
of
minutes
just
to
catch
anything
that
we
might
have
missed.
D
E
F
G
D
Wendy's
been
sending
me
some
messages
to
about
improving
the
spec
MD
tool
to
be
more
resilient
to
those
changes
which
I
think
is
great
I'd
love
to
be
able
to
use
prettier
on
on
the
spec.
If
it
means
one
less
thing
for
people
to
worry
about,
it
doesn't
work
then,
like
we'll
find
out,
it
doesn't
work,
but
along
the
way
we
can
make
improvements
all
the
better.
It's.
B
One
trick
I
added
for
our
agendas
is
when
you're,
when
you're,
creating
markdown
or
Auto
formatting.
You
can
add
the
ignore
blocks
around
the
attendees
list,
because
people
will
usually
add
those
in
mine
without
creating.
You
know,
just
through
the
github
UI,
it's
I
found,
if
you
just
have
like
an
ignore
block
for
that
everything.
That's
usually
the
only
conflict.
You'll
have
I.
D
D
G
My
list
for
a
long
time,
I,
would
love
to
do
that.
Yeah,
so
I
think
we
need
to
consider
consider
awake
with
entire
roadmap,
so
I.
My
problem
with
current
approaches
that
grammar
rules
are
part
of
Martin,
so
always
always
tools.
Think
it's
like
text
so
around
or
Expo
checkers
project
I.
Think
if
the
Rama
Rose
is
like
a
text
other
those
actually
want.
One
thing
is
an
I
wanted
to
ask
your
opinion
about,
as
because
there
is,
there
was
discussion
about
translations
pack,
but
I.
G
Think
it's
like
too
much
work
to
keep
it
up-to-date
closet.
So
I
cannot
developer
documentation,
small
kiss
back,
but
one
things
that
will
help
non-native
speaker,
including
me.
If
we
can
limit
our
work
every
to
pretty
big
set
of
pores
but
still
work,
my
going
5,000
most
frequently
used
words,
because
some
of
the
words
is
inspect
the
havoc,
very
subtle,
meaning
they
make
it
our
to
that's.
D
Actually,
really
good
point,
you
know,
I
think
you
can
come
out
from
a
lot
in
different
directions.
You
come
up
at
from
whether
English
is
not
your
language
which
for
a
huge
chunk
of
the
graphical
community.
That
is
true,
but
also
just
like
your
your
level
of
competency
and
your
ability
to
interpret
the
spec
I.
Think
one
of
the
problems
we've
had
with
ambiguity
in
the
past
has
been,
and
actually
just
properly
interpreting
language
and
trying
to
be
more
crisp,
so
I
see
all
those
as
overlapping
concerns.
But
I
really
like
this
idea.
D
D
So
as
always,
you
kick
off
put
the
reminder
that
everyone
here
is
in
agreement
with
the
spec
membership
agreement.
Hopefully
all
signed
that
but
kind
of
by
joining
you
explicitly
agreed
to
that.
We
also
agree
to
participation
guidelines
for
how
we
operate
on
this
back
into
code
of
conduct
by
the
way,
any
additions
to
the
attendee
lists.
I
will
keep
looking
at
quo
requests.
So,
if
you
forgot
to
add
yourself
just
feel
free
to
add
one
of
those
in
the
next
few
minutes,
I'll
just
be
kind
of
merging
them
in
as
I
find
him.
D
Next,
as
we
always
do,
should
go
around
the
room
and
do
just
a
quick
name,
its
quick
intro.
They
notice
that
they're
talking
to
and
we'll
go
in
order
in
the
agenda
as
it's
written
right
now,
so
it
a
quick
reload
on
that
and
start
at
the
top
top
name.
Is
me:
everybody
Emily.
B
D
D
D
D
D
We're
gonna,
look
at
the
last
meetings,
action
items
of
course
and
see
how
much
progress
we
made
spoiler
alert.
That's
only
gonna,
be
so
much
they're
gonna
talk
about
graphical
scalars
hosting
and
how
we
coordinate
those
things.
Graphical
namespaces,
we're
gonna,
take
a
quick
look
at
input,
Union
criteria
and
adjustments
that
we
might
want
to
make
to
that.
And
then
we
can
give
an
update
on
the
last
subcommittee
that
we
broke
out
on
input
unions
and
talked
a
little
bit
about
tag
types.
D
All
right
with
that,
let's
take
a
look
at
the
last
meetings
action
items.
This
is
a
thing
that
I
did
last
night
in
preparation
for
this
meeting,
which
I
feel
like
should
really
do
the
day
after
these
meetings,
instead
of
before
them
but
I.
Hopefully
this
will
be
an
easy
thing
for
us
to
do
to
keep
us
on
the
hook
for
following
up
in
action
items.
D
I
just
literally
took
the
notes
from
the
meeting
scanned
through
for
the
board
action
copy
and
pasted
text
put
them
in
here
and
put
the
date
at
the
beginning
of
them
and
I
updated
all
the
links
in
the
agendas
to
show
all
the
actions,
whether
they're,
open
or
closed.
That
way,
it'll
be
easy
to
just
kind
of
scan
through
look
for
all
the
ones
that
have
a
particular
date
than
the
name
and
check
to
see
if
they're
open
they're
closed.
D
So,
if
that,
let's,
let's
kind
of
dig
through
them,
I'm
gonna
work
on
them
from
the
bottom
up.
The
first
one
was
making
sure
that
we
have
agenda
items
for
the
rest
of
the
year
that
we,
you
know,
do
we
have
those
through
December
and
then
in
another
month
or
two
I'll,
probably
start
filing
more
of
them
into
the
beginning
part
of
next
year,
so
that
we
have
a
clear
long
term
calendar.
D
Then
I
have
still
an
open
tax
to
take
a
final
at
its
royal
pass
on
the
custom
scaler
specification.
My
expectation
is
still
that
that
will
go
to
the
final
space
I.
Don't
anticipate
any
problems
with
that,
but
I
do
want
to
make
sure
I
have
some
time
to
take
a
final
look
and
make
any
like
produce
edits
before
putting
that
to
stage
three
and
merging
it.
So
that's
the
open
I
me
introspection
shortcuts
RFC.
D
This
was
discussed
as
a
potential
potential
stage,
one
RFC
last
meeting,
and
we
decided
that
it
needed
a
clear
problem
definition
to
have
a
move
forward.
That
I
believe
is
still
open,
update
the
input
union
RFC's
after
subcommittee
meetings.
We
mentioned
that
we
needed
to
do
that
last
meeting
after
the
first
of
those
subcommittee
meetings
which
we
hadn't
done
and
then
we
had
a
second
subcommittee
meeting.
D
D
This
was
a
good
suggestion
on
you,
I
explicitly
kind
of
wanted
to
call
this
out
as
a
separate
bullet
from
the
previous
one,
since
it
came
up
separately,
but
I
think
likely
will
probably
tackle
those
two
at
the
same
time
that's
still
pending,
and
then
this
last
one
I
believe
I'm
gonna
be
able
to
mark
as
completed
including
clear
problem
statements
for
the
fern
stream.
That
was
on
Rob
and
Rob,
actually
followed
up
quite
quickly
and
was
able
to
do
that
a
couple
of
days
after
the
one
to
me.
D
K
Quick
question
on
the
input
union
subcommittee:
I
guess
since
I
missed
the
last
few
meetings
in
the
spec
group.
Where
can
I
join
the
subcommittee
and
are
there
handy
links
to
it
because
I
cannot
find
one
at
the
top
of
the
RFC.
D
Subcommittee
is
maybe
giving
it
to
official
sounding
of
a
name.
It
was
literally
that's
a
quick
meeting
that
we
had
between
the
people
who
championed
one
of
the
various
proposals
in
that
input,
unions,
RFC,
docket,
and
so
that
was
Benji,
Evan
Vince
and
myself.
We
just
got
into
a
call
for
a
couple
of
hours
and
just
kind
of
worked
through
the
document
top
to
bottom.
Just
make
sure
that
it
was
still
up
to
date,
made
sense
and
talk
to
me.
D
Some
space
I
have
this
as
a
last
agenda
item
for
the
day,
because
I
feel
like
we
could
very
easily
get
into
the
weeds
and
spend
a
lot
of
time
discussing
it.
So
I
wanted
to
make
sure
you
have
plenty
of
time
for
everything
else.
We
won't
cover
to
that,
but
I'm
happy
to
give
more
updates
on
what
we've
been
up
to
in
those
subcommittee
meetings,
cool.
G
O
D
My
mind,
the
most
important
kind
of
philosophical
question
to
answer
is:
do
do
we
want
this
graph
khillski
other
site
to
become
to
have
like
a
barrier
of
entry
like
every
scalar
speck
on
there
has
been
vetted
discussed
and
agreed
upon
it's
something
that
everybody
should
use,
or
should
this
be
something
that
has
a
pretty
low
barrier
to
entry,
and
it's
purely
just
about
creating
a
centralized
hub,
so
I
can
see
trade-offs
to
either
path.
I.
G
Think
we
need
to
you
know:
it's
sorta
connect
problem.
People
need
to
start
using
with
custom
scours
and
they
wouldn't
start
using
or
it
will
be
like
fragmentation
of
community
if
we
don't
give
a
push.
So
actually
one
of
the
discussion
we
had
on
spark
is
that
I
want
you
with
India.
Is
that
I
want
to
use
with
like
custom
sky
work
for
daytime?
You
cannot
get
Jess,
so
it
will
push
adoption
through
the
ecosystem.
G
G
So
personally
for
graphic
interests
case,
it's
not
even
a
question
if
it's
official
mode,
it's
a
question
if
it's
like
reliable
or
not,
because
if
we
depend
on
some
URL
and
this
unit
will
disappear
to
have
the
same
situations
like
we
had
with
situation
with
graphical
cuts,
so
so
I
really
extreme
situation
with
Pollock,
but
like
it
stuff
like
that,
happens
people
what
interests.
People
like
something
happens
with
people.
I
O
D
Yeah,
there's
I
mean
there's
a
bunch
of
sort
of
like
technical
decisions
that
we
could
iterate
on
if
we
did
decide
to
take
this
out.
But
the
reason
why
I'm
asking
this
line
of
questioning
is
kind
of
how
we
proposed
this
and
how
we
suggest
it
to
people.
It
is
important
like
I,
don't
know,
I
have
a
strong
personal
opinion
on
this,
yet,
but
my
sense
that
it
would
be
more
valuable
for
it
to
be
centralized
than
it
would
for
it
to
be
blessed.
D
That
makes
sense,
blesses
an
overloaded
word,
but
like
I,
don't
know
that
we
want
to
say
every
single
spec
that
you
find
on
graphical
scalers.
Calm
is
gonna,
be
great
and
you
are
not
gonna.
Have
any
problems
with
it,
but
avoiding
a
scenario
where
every
single
graphical
scaler
is
hosted
by
a
different
domain
seems
seems
like
a
really
nice
thing
to
have,
especially
if
you
could
do
something
like
in
index,
and
you
want
to
be
able
to
say
like
what
are
all
the
scalars
that
are
out
there.
D
D
Yeah,
that's
a
good
point
it.
It
throws
up
all
the
traditional
questions
that
arise
with
with
shared
dependency
management,
like
name
collision.
You
are,
these
pages
is
mutable
like.
Can
someone
go
and
just
change
the
spec
like
they
can
Andy
go
update
the
state
times
back
and
say
like
oops?
Actually
it
shouldn't
have
had
this
clause
or
Oates
actually
needs
this
different
input.
Interpretation
clause
that
NPM
is
an
interesting
equivalency
to
draw.
In
that
case,
you
would
issue
a
you
know,
version
breaking
change
or
something
like
that.
K
D
That's
actually
right,
yeah!
That's
that's
already
true
today,
because
you
say
the
name
of
the
scalar
in
your
code
base
and
then
you
say
the
URL
that
represents
it.
So
this
URL
could
be
completely
opaque
or
betrayed.
You
know
it
could
just
be
like
a
hash
of
the
spec
and
that's
the
URL
and
you're
going
expect.
We
would
work
equivalently,
perfect
cool,
but
it's
a
good
point
for
like
search
ability
and
understanding.
D
G
Actually
think
we
can
have
sequential
numbers
like
RFC,
so
it's
way
simpler
and
it's
alright
for
small
changes
changes
and
it's
not
like
a
names
and
people
are
ok.
That
standards
have
numbers
so
like
if
somebody
get
like
wacky
number,
it's
a
good
thing,
but
it's
not
critical,
also
from
RFC
process
I
at
one
point,
I
actually
wanted
to
make
my
own
RFC
and
so
I
researched
it
a
little
bit
as
so.
G
They
have
waken
types
of
RFC.
So
there
is
like
I,
think
it's
that
number
for
called
informal.
So
criterias
for
that
is
a
you
sounded
editor
from
from
like
some
organization,
and
they
just
check
your
grammar
and
like
spelling,
grammar
and
other
stuff,
and
if
it's
correct,
they
publish
it.
So
they
don't
have
any
any
anything
to
say
about
content
just
like
for
Martin
and
proper
style
and
like
technical
document,
so
I
have
about
technical
documentation.
G
D
The
sequential
numbers
is
probably
better
than
hatched
in
terms
of
understandability
and
thanks
for
the
link
to
the
package
thing,
that's
very
interesting.
I
can
imagine
how
a
URL
proxy
pattern
would
just
the
you
know.
Most
recent
literary
major
is
what's
implied
by
that
URL.
It's
not
exactly
immutable
by
that
sense,
but
it's
an
interesting
way
to
kind
of
blur
the
line
between
URL
immutability
and
seven
for
logic
and
yeah.
You
know
it
seems.
O
D
O
But
I
don't
know
if
there's
anybody
who
has
the
time
and
interest
to
actually
do
that
or
we
should
just
let
nd
run
his
personal
site
for
a
while,
because
there's
there's
kind
of
need.
Somebody
needs
to
be
somebody
who
has
the
access
and
time
to
do
that
migration
and
build
that
artificial,
gradual
foundation,
side
of
things.
G
And
I
understand
he's
open
to
idea,
but
he
don't
want
a
lot
of
bureaucracy.
He
don't
want
to
spend
time
like
on
reviews
and
official
procedures,
so
wait
if,
if
we
say
it's
an
official,
it's
like
just
a
question
number
and
I
need
to
just
properly
format.
Your
document
I
think
I
can
do.
I
cannot
speak
for.
D
Him,
but
this
yeah
this
is
this
is
the
good.
This
is
the
heart
of
the
discussion.
I
think
I,
I
haven't
I
agree
with
you,
I
think.
There's
there's
appetite
for
the
project
to
be
a
foundation
project
and
therefore
you
know
be
granted
some
longevity
and
if
Andy
decides
that
he
wants
to
be
busy
with
something
else,
then
we
can
figure
out
how
to
make
sure
that
that
thing
has
a
long
life,
but
each
particular
document
to
the
bombs
point
should
like
probably
default
to
this
informal
style
or
something
so
you
know.
D
Maybe
the
right
next
piece
is
to
figure
out.
How
do
we
remove
even
more
from
from
even
more
you
know,
hurdles
to
jump
barriers
to
cross
like
you
even
need
to
get
a
pull
request
merged
like
what's
the
what's
the
pathway
you
needed
to
follow
in
order
to
get
something
in
there
and
then
how
do
we
answer?
Questions
like
when
people
disagree
about
a
scalar?
D
Can
we
just
allow
them
to
disagree
and
then
have
a
way
to
to
make
that
super
clear,
like
I'm
I'm,
watching
NPM
certain
starting
to
push
people
towards
really
encouraging,
including
the
org
or
username
as
part
of
the
package?
You
know
you
have
to
like
that.
Whatever
slash
your
package
name,
do
just
want
to
start
with
that
convention
and
you
just
kind
of
know
like
Andy's
date/time
scalar
here
just
becomes
graphical
scaler,
/
@
+
e
/
date/time.
K
O
O
What's
the
word
I'm
looking
for
survivability
not
like
that,
but
just
like
confidence
that
you
know
whatever
URL
we
end
up
using
for
these
things
is
not
going
to
go
away
because
Andy
decides
to
stop
paying
for
the
domain
name
and
I.
Think
like
that
is
at
least
as
easily
solvable.
That's
just
clubbing
that
Romania
is
transferred
to
the
foundation
so
that
you
know
we
can
ensure
that
it
at
least
stays
up.
O
N
I
I
D
Nice,
this
is
kind
of
why
I
was
asking
about
you
know
what
what
do
we
want?
The
mechanism
for
B
to
be
for
people
to
submit
stuff,
because
I
just
anticipate
an
outcome
where
there's
like
a
bunch
of
pull,
requests
up
to
add
new
scalars
and
nobody's
there
to
review
them,
and
that
would
be
a
sad
fate
and
and
Gabe
you're
right
to
point
out
that
the
foundation
is
more
of
a
legal
structure
than
a
technical
structure.
Right
like
we
were
there
to
place
safe
harbor
for
IP.
D
But
ultimately
it's
also,
you
know
showing
up
from
our
various
institutions
that
are
gonna
work
together
on
something
like
this
I.
Do
think
that
you
know
if
we,
if
we
made
it
really
clear
what
needed
to
be
built
and
kind
of
put
that
together,
it's
just
back
and
said,
like
hey
here's,
what
we
have,
but
like
here's
the
gap
between
that,
what
we
want
and
then
asked
if
anybody
was
interested
in
such
a
project
beyond
just
this
working
group,
you
know
we
could
like
tweet
it
out
or
something
or
just
go.
Ask
our
respective
teams.
G
Hope
suggestion
first
finger
I
think
we
need
to
involve
in
this
conversation
because
he
came
in
because
he
created
we
think
and
do
we
want
adopted.
Do
we
want
to
do
something
forever
and
so
and
another
thing
I
think
like
it
will
be
easier
to
find
people
who
just
can
wait.
Work
in
algorithm
is
harder
to
find
to
write
some
way,
basically
and
I.
Don't
think
we
need
to
overcomplicate
it
and
think
about
all
possible
situation.
G
For
example
in
this
working
group
we
don't
like
it's
already
three
years
and
we
don't
have
a
rights
about
voting
or
about
sheets
and
everything
work
morris
como,
so
we
don't
need
to
farm
our
store,
so
I
would
suggest
one
thing:
can
we
schedule
a
call
discuss
like
we?
Then
you
went
20
have
a
time
and
schedule
like
one
hour,
maybe
hour-and-a-half
and
actually
discuss
with
schools
and
write
them.
I
think
it
would
be
enough
time
to
do
that.
G
I
I
can't
I
can't
remember
how
many
different
versions
people
have
suggested
and
different
ways
that
they've
suggested
of
doing
it.
The
one
thing
that's
clear,
I
think
from
just
reading.
That
issue
is
that
it's
really
contentious
so
in
this
in
this,
what
I'm,
gonna,
try
and
do
is
not
really
argue
for
any
particular
syntax,
but
for
the
usefulness
of
namespaces
in
particular,
and
how
that
comes
to
fruition
later,
if
it
does
get
included,
is
for
another
discussion,
I
think
so
again.
I
The
argument
that
has
been
given
a
couple
of
times
is
that
you
can
achieve
the
same
thing
by
prefixing
or
even
suffix,
in
type
with
whatever
you
would
use
for
a
namespace,
and
that
argument
is
perfectly
valid
in
a
lot
of
cases.
You
can
do
that
to
achieve
almost
equivalence.
The
problem
starts
for
us
when
we
have
in
in
our
setup.
Every
organization
has
a
realm,
so
you
would
have
a
realm
name,
and
the
these
realms
can
then
have
apps
inside
them,
and
each
app
can
have
one
or
more
releases.
I
So,
in
order
for
us
to
know
that
tightly
unique,
we
would
have
to
use
all
three
of
those
components
as
a
prefix
or
a
suffix
to
every
type
which
again
or
a
lot
of
cases
isn't
the
end
of
the
world.
You
can
do
that.
The
title
become
a
bit
long,
but
it's
not
the
end
of
the
world
where
it
starts
to
become
a
problem.
One
second
just
jump
through
these
is
when
you
start
to
do
a
lot
more
automated
stuff,
as
we're
doing
in
our
platform.
I
I
In
with
what
comes
back
in
some
cases,
they
know
some
of
the
types
that
they're
expecting
so
then
they
have
to
actually
start
typing
some
of
this
stuff
out
and
because
we're
generating
the
type,
the
type
names
and
the
function
names.
It
starts
to
become
very
unreadable.
So,
if
you
look
at
the
introspection
results
from
our
some
of
our
API,
is
that
have
a
bunch
of
apps
included
the
generated
names?
You
can't
even
see
the
full
signature
in
in
graphical
in
some
cases
and
it
makes
it
really
hard
to
work
with.
I
I
I
This
starts
to
become
a
real
problem,
because
if
you,
the
more
apps
you
inherit,
you
end
up
with
an
explosion
of
these
types
and
an
explosion
of
these
scopes.
You
then
have
to
basically
create
these
catch-all
authorization
policies
to
try
and
capture
all
of
the
cases
that
are
coming
in
from
apps.
That
you're,
depending
on
that
makes
the
authorization
policy
is
very
brittle.
It's
either.
You
do
that
or
you
write
something
that
then
generates
individual
authorization
policies,
but
that
again
is
not
really
maintainable
by
hand.
I
You
have
to
automate
all
of
it
and
not
all
of
our
customers
have
the
capability
to
be
able
to
write
something.
That's
automate
all
of
them.
That's
the
other
thing.
That's
just
a
way
from
you
could
equivalent.
You
can
get
the
equivalent
behavior
by
prefixing
Ora,
so
that
in
in
our
case
as
well,
the
example
that
I've
just
given
is
relatively
okay,
so
Facebook.
What's
that
message?
I
It's
not
very
long,
but
you
have
some
companies
who
would
use
a
longer
prefix
for
their
for
their
own
name,
for
example,
and
then
you
literally
get
something
that's
going
off
the
screen.
If
you're
looking
at
a
120
or
180
view
of
things,
the
names
that
are
being
generated
are
just
completely
unreadable.
I
That's
as
much
as
I
think
I
can
argue
for
this.
It's
the
same
argument
that
you
would
use
for
namespaces
in
any
modern
language
that
has
namespaces
I
I,
wasn't
really
prepared
to
do
this.
I
I
put
this
together,
just
as
we
started
doing
this
call.
But
those
are
the
examples
and
the
use
cases
that
I
could
think
of,
and
in
our
case,
in
most
of
art
for
most
of
our
customers,
they
don't
get
the
full
benefit
of
the
graphical
ecosystem.
I
So
they
don't
have
the
tools
to
be
able
to
do
the
generate
stuff
because,
again,
like
I,
said
some
of
the
stuff
that
they're
doing
is
happening
by
just
doing
introspection
and
then
some
combination
of
stuff,
like
they
can't
take
full
advantage
of
the
compile
time
or
statically
generated
stuff
that
you
might
do
if
you
were
to
use
the
generators
from
the
rest
of
the
ecosystem,
so
I
think
I
just
talked
about
all
of
that.
Without
going
to
this
slide,
that's
that's
really
all
I
had
to
say
on
the
matter.
I
I
I
gave
an
example
of
what
we
implemented
to
try
and
see
what
it
would
take
to
make
this
work
in
the
ticket.
So
I
think
it
was
about
a
year
ago,
if
not
more
Lee
suggested
that
one
of
the
things
that
we
could
do
is
just
to
implement.
It
see
what
it
would
take
to
implement
it
and
then
report
back
and
I
posted
a
long
comment
on
what
we
dim
planted
and
what
we
did
do
was
something
that
was
similar
to
namespaces
in
C++.
I
So
you
do
namespace,
you
give
it
a
name
and
then
all
the
names
all
that
the
definitions
that
come
after
that
are
in
that
namespace
and
there
were
no
major
challenges
in
getting
this
implemented.
In
fact,
we
used
growth
to
our
Java
library
and
I.
Think
the
modifications
took
about
two
days
for
the
developer
to
start
actually
playing
around
with
it.
So
implementation
wise.
It
wasn't
a
huge
burden.
What
became
a
real
problem
was
after
we
got
a
few
customers
to
try
and
use
it.
I
They
completely
lost
all
the
graph
QL
ecosystem
right,
so
what
little
they
do
have
through
our
platform.
Just
evaporates
it
because
the
there
was
no
support
for
namespaces
in
any
of
the
libraries
that
they
were
using
like
Apollo,
etc.
So
everything
just
went
ya
know
which
became
a
real
problem
for
them.
So
we
haven't
rolled
this
out,
but
I
I
do
think
that
it
makes
life
a
lot
easier
for
our
customers
and
I.
I
D
Cool
that
makes
sense
yeah.
Most
of
my
concerns.
I,
remember
from
a
previous
comment,
were
not
necessarily
complications
in
the
SDL
I
think,
most
of
the
time
when
people
talk
about
this,
they
talk
about
it
in
terms
of
the
SDL
and
it's
relatively
straightforward
to
imagine
some
STL
syntax
that
you
might
use,
but
not
everyone
uses
graph
field
via
the
STL,
a
lot
of
the
music
via
a
code
library
or
via
introspection,
and
in
those
cases
that's
most
of
where
my
complexity
concern
comes
from,
is
in
those
cases
it's
far
less
clear.
D
I
Yep,
so
in
in
the
comment
that
I
posted
I
addressed
some
of
those,
including
a
simple
algorithm
for
how
you
could
do
default
names
basis
to
try
and
maintain
backwards
compatibility
in
the
syntax
that
I
showed
in
the
example.
The
way
we've
done,
it
was
so
that
you
could
optionally
have
the
name
space
if
it
was
missing,
then
stuff
goes
into
a
default
namespace
and
that
ensured
that
exists
in
STL
schemas
didn't
need
to
change
if
the
parser
didn't
support
it.
I
So
if
you
just
didn't
have
names
by
says,
it
would
just
be
as
if
it
doesn't
exist
and,
for
the
most
part,
I
admit
double-check
this,
to
confirm,
but
I'm
sure
that
none
of
the
customers
that
we
had
try.
It
has
to
change
their
existence,
Amos
to
actually
start
using
the
new
version.
In
fact,
I
wasn't
sure,
because
this
is
turned
on
from
my
account
and
I
did.
I
did
a
demo
on
my
account
two
days
ago,
and
there
were
no
issues.
I
O
I've
made
you
sense
in
terms
of
like
namespaces
would
also
be
useful
for
us,
as
Shopify
schema
has
done
very.
Very
large
internally
like
be
fixing
has
worked
for
us
as
a
workaround
or
as
it's
kind
of
the
available
option
right
now,
but
first-class
support
would
be
nice.
It's
not
the
most
important
thing
facing
us
right
at
this
moment
with
crappy
bill,
but
it
would
definitely
be
a
nice
to
have.
O
Mean
you're
ever
we
have
our
schema
is,
is
enormous
internally
right
now,
I
mean
our
public
scene
was
pretty
big
too,
but
we
have
a
great
deal
more
of
it.
That's
private
and
just
in
terms
of
keeping
keeping
names
distinct
when
they
refer
to
similar
things
across
different
parts
of
the
company
in
different
parts
of
our
technical
stack.
We
end
up
with
kind
of
change
names.
Prefix
names
like
online
store,
bla,
bla,
bla,
bla,
bla,
bla,
bla,
bla,
bla,
bla,
bla,
bla
page.
You
know
like
the
the
classic,
whatever
java
factory
factory
instance.
F
O
M
D
O
Yeah,
that
would
be
nice,
I
think
in
practice.
We
mostly
only
hope
like
if
we
were
to
translate
our
current
schema
into
namespaces,
we'd
I
think
have
at
most
two
or
three
layers
I
think
like
it
wouldn't
be.
It
wouldn't
be
super
deep
at
the
moment.
Definitely
we
have
cases
that
are
more
than
more
there's
more
than
one
layer
right
now.
I
D
I
D
Honestly,
this
is
the
most
interesting
I
I
think
this
came
up
in
the
the
thread
long
in
the
past,
but
most
of
the
original
motivations
for
namespaces
that
honestly
I
was
really
underwhelmed.
By
was
this
idea
that
different
parts
of
a
company
wanted
to
isolate
themselves
from
each
other
and
think
about
schema
design
in
a
distributed
fashion.
D
We
should
do
the
thing
that
works
best
for
them,
but
this
other
use
case
I
think
is
way
more
interesting
and
compelling,
which
is
like
a
truly
distributed
schema
where
it's
not
just
that
they're
different
parts
of
the
company
that
I
want
to
be
able
to
terminate
their
isolate
or
not,
but
they're
like
different
companies
or
different
organizations
or
whatever,
where
you
could
kind
of
start
to
evolve.
This
intermeshed.
I
So
we
we
actually
have
functionality
that
allows
customers
to
do
exactly
that.
So
one
of
the
features
that
you
can
use
is
when
you
create
an
app,
you
can
specify
an
open,
API
specification
and
will
automatically
generate
type
definitions
and
methods,
so
queries
and
mutations,
and
for
customers
that
are
basically
using
us
on
our
graph
QL
API
as
a
gateway
to
these
API.
Is
it
you
end
up
with
an
explosion
of
types?
G
Some
idea,
because
it's
actually
not
a
new
problem
and
we
discussed
it
with
Prisma
guys.
The
experiences
were
years
ago
and
the
after
whisk
package
called
graphical
import.
It's
basically
all
you
to
say,
use
a
comment:
syntax
because
you
don't
have
to
follow
directives.
Yet
we
discussed
it,
but
oh
my
champion
champion.
So
so.
Instead
they
used
commands
and
basically
it's
like
import
and
type
name
from
and
we
discussed
reserves
they
didn't
implemented.
But
we
discussed
with
them
that
you
can
also
add
custom
prefix.
G
So
in
JavaScript
you
do
import
something
as
something
and
it's
basically
so
so
I
can
type
problem
for
graph.
Here,
it's
little
bit
more
complex,
because
types
can
depend
on
other
types,
so
you
can
adjust
the
name
type
which
we
import,
because
it
will
bring
other
types
inside,
but
you
can
provide
custom
prefix,
so
I
think
white
fool
for
a
case
where
you
imported,
like
small
number
of
four
party
types.
G
We
can
just
allow
people
to
do
custom
custom
prefix,
not
after
generate
preferences
for
them
like,
and
if
you
have
to
generate
prefixes
I
would
do
one,
but
if
customer
can
provide
preference
for
importing
time,
it
can
be
pretty
short
and
it
can
be
like
every
customer
can
choose
whatever
prefix.
They
want
to
say
this
year.
So
I
give
some
example
inside
inside
Commons.
If
somebody
interested
yeah.
I
So
we
in
the
comment
that
I
posted
on
that
issue,
we
actually
more
implemented
support
or
aliases
and
partial
imports.
So
I
just
mentioned
the
open,
API
examples
that's
available
in
the
platform
we
added
support
so
that
you
could
do
import
from
namespace
and
specify
the
types
that
you
want
imported.
So
you
didn't
have
to
import
the
entire
stripe
API,
but
also
added
support
for
doing
import,
namespace
type,
as
some
other
tightening
to
address.
What
at
the
point
you
just
raised.
So
we
don't.
G
D
I
I
No
so
I
mean
from
from
from
our
perspective,
I
guess
figuring
out
whether
the
graph
guild
community
wants
to
take
this
forward
is
one
thing,
but
also
if
we
needed
to
do
anything
because
we're
quite
keen
to
get
this
in.
So
if
that
meant
right
in
the
IRC
or
something
else
or
if
there
was
a
strong
opposition
to
it
or
whatever,
having
I
guess
some
action
items
for
where
to
go,
how
to
go
forward.
I
think
is
the
the
thing
that
the
main
reason
I'm
on
this
call
today.
I
So
what
from
me
would
be
useful
is
a:
is
there
any
strong
reason
not
to
have
this,
and
if
there
is,
can
whoever
has
those
opposition's
explain
that
if
it's
okay
and
it's
something
that's
the
community
spoken
to
exploring
beyond
that
issue?
What's
the
next
step?
Is
that
an
RFC
and
I
guess
yeah?
That's
it
what
what's
the
next
step?
What
do
we
do
for
this
I.
D
Mean
personally
I'm
I'm
still
concerned
that
it
adds
a
layer
of
complexity
and
there
are
some
reasonable
workarounds,
even
though
they
have
downsides
so
I.
Think
a
worthwhile
next
step
would
be
a
clearly
stated
RFC,
which
documents
the
problem
kind
of
as
you
post.
It
here
explains
why
the
existing
solutions
are
inadequate
to
solve.
That
problem
explains
why
this
problem
is
widespread
enough,
that
it
warrants
addition
to
the
spec
and
then
starting
to
outline
the
exact
shape
of
that
solution
and
to.
H
D
Then
sort
of
like
size
of
problem
statement
right,
so
how?
How
likely
is
it
that
the
typical
graphical
user
will
use
this
so
and
put
another
way?
What
I
want
to
avoid
is
graphical
having
a
ton
of
Fringe
features
which
are
used
by
very
few
members
of
the
community,
but
accumulate
to
quite
a
large
amount
of
complexity
and
sort
of
things
that
you
have
to
learn
in
order
to
understand.
What's
going
on,
this
back
feel
so
you
know.
D
Then
that's,
usually
that
makes
it
clear
argument
for
adding
additional
complexity
to
the
to
the
system
in
the
language
in
the
spec.
Then
you
know,
then,
there's
all
the
practical
questions
of
backwards
compatibility
you
know:
are
there
degenerate
cases,
water
scenarios
where
you
can
break
a
schema?
There's
like
lots
of
those
things
are
typically
will
come
up
when
we're
talking
about
stage.
1
or
stage
2
rfcs
or
what
are
all
the
various
ways
that
this
can
bite
us.
What
are
all
the
various?
What
gums
are
introducing
and
making
sure
that
we're
addressing
those
things.
O
Yeah,
as
far
as
making
a
case
for
the
value
and
the
first
step
of
that
I
think
I'm,
like
the
PA
use
cases
you've
presented
here
today,
are
a
good
first
step
towards
that
they
didn't
need
you
know
heating,
up
and
writing
down
and
and
presenting
in
a
way
that's
going
to
work
for
posterity.
Basically,.
D
But
it
sounds
like
where
we
are
is:
there's
certainly
I
mean
I
would
say.
The
opposition
that
you'll
hear
will
be
about
caution
and
not
about
rejection,
which
means
the
right
next
step
is
to
charge
forward
and
start
to
clarify
that
caution
and
make
it
clear
that
each
piece
is
either
unwarranted
or
able
to
be
mitigated
and
that'll
make
a
clear
path
forward
to
making
this
happen.
G
Yeah
some
notes,
because
I'm
actually
I'm
Leslie
said
them
concerned
about
what
so
what
does
the
same
time
totally
folks,
poor
and
bad,
because
it's
not
the
first
time
we
discuss
it
like
even
on
working
group.
We
discussed
that
a
couple
times,
so
we
need
to
formalize
with
discussion
and
to
really
go
deep
at
some
point
we
need
we
need
to
to
do
something
to
address
was
even
explaining
what
concern
we
have
with
sauce
and
butter.
One
thing
so
I
for
me
personally,
I'm,
like
I,
don't
have
graphical
API
and
I,
don't
use
graph.
G
So
from
a
mother's
point
of
view,
what
will
help
me
if
you
control,
like
your
fork
or
in
some
other
way,
to
show
how
much
changes
it's
involve
or
grafting
Java
so
like?
Is
it
like
you
change
hundred
to
a
so
it's
like
a
couple
thousand
ones,
because
we
one
of
the
things
we
have
a
composite
a
budget.
Every
features
that
we
add
into
roughly
strategy
will
be
implemented
in
all
the
languages,
so
I'm
interested
if
to
nearing
the
size
of
the
changes,
not
particular
changes,
but
quite
just
like
a
size.
I
D
Nice,
alright,
let's
move
on.
Let's
talk
about
input,
unions,
I
think
there's
a
ton
of
kind
of
stuff
to
get
through
here
and
we
can
spend
the
remainder
of
our
meeting
on
input,
unions
and
then
index
I
sorted
your
your
bit
to
the
top
just
to
make
sure
that
you
had
an
opportunity
to
kind
of
speak
to
this.
D
K
It's
about
this.
This
criteria
that
I
added
that's
many
about
developer
ergonomics
of
input
unions,
so
one
issue
have
seen
with
the
some
of
these
suggested
solutions,
and
that
is
that
it
makes
it
really
hard
to
freely
combine
different
input
types
to
an
to
an
input
union
and
they
place
some
constraints
on
on
which
input
types
can
be
combined
in
the
first
place
or
how
they
have
to
be
composed
in
order
to
be
able
to
be
combined.
D
Yeah
I
merged
your
pull
request
because
it
actually
matched
really
well
a
discussion
that
the
few
of
us
that
went
deep
on
input
unions
had
it
ultimately
led
us
to
decide
that
at
a
minimum
were
ruling
out
that
option
number
four
and
I
I
think
actually.
The
reason
that
we
ruled
it
out
was
almost
exactly
for
the
this
constraint
that
you're
suggesting
we
kind
of
found
ourselves
there,
but
had
a
difficult
time
articulating
exactly
what
that
looked
like.
D
But
if
I,
if
I
can
recap
the
discussion
and
then
saw
revenue,
Benji
feel
free
to
jump
in
and
correct
me.
One
of
the
things
we
thought
about
was
what
does
schema
schema
evolution.
Look
like
with
any
of
these
things.
What
does
it
look
like
to
add
an
additional
type
to
the
Union?
Or
what
does
it
look
like?
D
It
would
make
it
so
that,
like
once,
you
had
to
find
an
input
Union
with
some
input
types
involved.
It
would
make
both
those
types
and
the
input
Union
itself
pretty
tough
to
evolve
from
that
point
forward,
and
that
was
reason
enough
to
disqualify.
It
I
think
that
lines
up
very
well
with
what
you're
talking
about
but
make
sure
I'm
not
misunderstanding.
Your
constraint
predict
yeah.
K
K
D
Yeah,
for
in
particular,
is
is
very
seriously
affected
by
this
to
a
degree,
although
my
expectation
is
that
people
would
use
those
field
constraints
kind
of
globally
rather
than
in
each
type.
So
in
practice
it
might
have
a
slightly
less
serious
effect
than
for
three
it
has.
It
could
potentially
have
an
effect
but
kind
of
the
way
that
algorithm
works
for
three
I
think
probably
works
around
that,
but
we
also
kind
of
agreed.
Another
thing
that
came
up
in
this
sub
community
meeting
was
three,
as
it's
posed.
D
Right
now
is,
is
not
enough,
so
we're
actually
in
the
process
of
combining
aspects
of
solution,
one
in
solution,
three
together
as
like
a
solution
six
in
this
list
that
in
part
actually
specifically
to
get
ahead
of
this
problem,
but
what
Benji
I've
been
convinced.
Let
me
know,
if
there's
other
pieces
to
this
discussion,
that
I'm
missing.
K
One
aspect
about
three:
that
is
not
really
a
part
of
any
criteria
so
far,
but
I
think
it
sure,
via
the
way,
the
algorithm.
The
way
the
algorithm
works.
Kind
of
always
has
a
way
to
determine
a
match.
Sure,
but
I
really
don't
like
the
way
that
it's
fuzzy
in
a
way
so
and
I
think
that
most
of
the
time,
that's
absolutely
not
what
you
want
to
be
to
have
your
inputs
somewhat
interpreted
by
the
backend,
so
that
could
lead
to
some
really
really
nasty
bugs
yep.
D
H
H
We
also
talked
about
things
like
the
nested
complexity
that
could
be
introduced
if
you're
not
specifying
a
type
explicitly.
If
you
have
tree
like
structure
for
example,
then
you
you
can
get
this
sort
of
combinatorics
issue
where
to
determine
exhaustively
whether
you've
got
the
right
type.
You
actually
need
to
check
each
type
at
each
level
and
if
you've
got
an
object
tree,
that's
maybe
just
four
different
options
and
four
layers:
Teebs,
that's
already
16
possibilities
before
you
know
that
it's
exhaustively,
none
of
them
and
you
should
raise
an
error.
H
So
there
there
was
some
various
issues
like
that
and
basically
I
think
Li.
Correct
me
if
I'm
wrong
here,
I
think
what
it
came
down
to
was
the
difference
between
nominative
typing.
As
in
saying
it
is
explicitly
this
thing
versus
a
more
structural
typing,
where
you
just
sort
of
say,
I
have
a
thing.
It
has
a
name
and
it
has
an
age
store,
as
whatever
you
want.
H
Backends
and
the
the
the
structural
typing
is
very
flexible,
but
that
flexibility
does
come
with
the
the
cost
of
it's
like
very
nice
for
users
to
use,
but
it's
actually
a
lot
harder
for
the
the
backend
to
to
implement,
and
rather
than
being
say,
oh
one,
it
can
become
o
n,
or
maybe
Oh,
n,
squared
or
possibly
even
worse.
So
that's
kind
of
the
things
that
we
were
sort
of
discussing.
H
You
could
express
it
as
a
large
number
of
different
syntaxes
and
we
looked
at
what
some
of
those
meant
well
they're,
effectively
equivalent,
but
we
looked
at
what
they
are
and
what
they
imply
about.
What's
going
on,
we
also
talked-
and
this
is
relevant
to
an
earlier
discussion.
We
have
today
about
what
the
exception
handling.
No
sorry,
it
was
an
issue
I
reviewed
today.
What
the
exception
handling
is
for
the
null
ability.
So
what?
H
Where
would
the
error
be
thrown
because
effectively
we're
introducing
this
intermediary
layer
so
rather
than
having
an
object
that
inherently
has
its
type
inside
of
it?
We're
using
a
tag
on
the
outside
to
say
the
thing
is
going
to
be
of
this
type
so
now
we're
two
layers
deep
rather
than
just
one
layer.
So
what
happens?
If
say
you
had
an
ID
field
on
that
that
said,
it
was
non
na
label
but
gave
a
naught.
Then
we
threw
an
error.
H
Would
the
era
be
thrown
at
that
field
level
within
the
tacked
Union
or
would
it
be
thrown
at
the
parent
level
where
the
tagged
Union
was
referenced
and
things
get
more
interesting
there?
So
what
we've
effectively
considered
at
the
moment
is
that
just
doing
this
as
a
as
a
directive
as
a
tag
on
an
existing
input
type
is
maybe
not
the
right
direction
to
go.
There's
too
many
exceptions
to
it.
There's
things
like
it
does
not
have
arguments.
It
will
never
have
arguments
it
may
or
may
not
have
support
for
directives.
H
That's
not
quite
clear
yet
on
the
individual
entries
between
bit
inside
the
tag,
it
has
custom
handling
of
null
ability,
and
maybe
we
need
to
expose
in
an
explicit
way
how
we
handle
that
no
ability
it
would
be
great
to
be
able
to
reuse.
Our
existing
null
ability
and
error
handling
as
the
errors
cascade
through
the
tree,
so
if
we
can
define
it
in
such
a
way
where
we
can
reuse
those
things,
that
would
be
great.
H
So
what
we're
thinking
at
the
moment
is
take
the
concept
that
we've
got
of
this
one
of
rename
it
it's
going
to
be
called
something
like
tagged,
unions
or
something
like
that,
we're
not
sure
exactly
yeah
and
then
give
it
a
concrete
new
type
in
the
graph.
Your
schema,
rather
than
just
reusing
the
input
type
and
one
of
the
interesting
things
that
this
allows
us
to
do
as
well,
is
expand
what
it
means,
potentially
to
output
types
as
well,
so
certain
systems
may
already
be
in
a
in
a
shape,
we're
exposing
it
as
a
tagged.
H
Li
raised
an
interesting
part
of
graph,
your
history,
which
is
that
actually,
when
they
were
implementing
unions,
originally
this
shape
was
actually
considered
for
a
fair.
While
before
we
took
the
Union
approach
and
there's
there's
certain
things
that
the
tagged
approach
doesn't
allow
so
easily.
So,
for
example,
spreading
on
an
unnamed
on
a
named
type
is
more
challenging
because
you
have
to
do
it
within
a
field
rather
than
say
over
all
the
things
that
implement
this
particular
interface.
Then
you
know
whether
it
be
cat,
dog
or
giraffe.
H
H
So
what
we've
ended
up
with
there
is
that
I
will
be
writing
up
the
RFC
again
effectively
previous
arrow
to
as
a
small
modification
to
input
this
time,
I'm
going
to
write
it
up
as
a
full
implementation
of
a
new
type
within
the
graphical
type
system
and
we're
going
to
evaluate
it
against
all
of
our
different
use.
Cases
see
if
we
can
find
the
problems,
see
how
complex
it's
going
to
be
to
implement
and
what
it
means
for
everything
else.
D
G
We
can
go
one
one
thing,
but
I
mean
my
kind
of
interesting
complicating
it
more
as
I
can
dial
exit.
It's
super
simple.
It's
like
you
know,
with
the
same
questions
that
everybody
has
why
it's
not
only
one
field,
why
it's
not
like
a
couple
of
groups
of
youths
and
pizza
with
each
other,
so
I
think
it
would
be
great
if
you
also
include
two,
like
you,
probably
discuss
it,
and
you
have
my
cargo
mat.
G
G
H
Interesting
point
even
I've
thought
about
this.
A
lot
and
in
particular,
I've
brought
this
up
a
few
times,
I'm
interested
in
not
just
the
input
types
and
the
output
types,
but
also
field
arguments
which
is
like
a
completely
different
thing,
but
also
very
much
the
same
as
input
objects,
so
I'm
interested
to
see
where
it
could
potentially
go
there,
but
we
fortunately
separated
that
to
a
separate
RFC
that
will
get
rejected
late
I
mean
applied
later,
but
yes,
so
I.
H
Think
broadly
with
like
the
example
that
you
raised
for
dates,
I
think
what
we
would
do
in
that
case
is
have
another
input
object
that
represents
these
separate
parts
and
then
reference
that
as
a
one
field.
But
the
there
is
value
in
addressing
that
and
basically
I
think
the
answer
comes
down
to
it's
unnecessarily
complex,
to
try
and
deal
with
this
idea
of
having
multiple
groups
of
things.
H
That
said.
If
we
were
able
to
expand
it
to
arguments,
then
it
could
become
more
valuable
because
that's
something
that
is
very
commonly
needed
in
arguments.
But
you
know
we'll
have
a
look.
This
is
still
very
much
in
the
thought
process.
So
I've
got
to
write
it
up
formally
and
then
try
and
analyze
all
of
the
different
solutions
against
it
and
I
haven't
sadly
had
enough
time
yet.
Yeah.
G
What
is
in
our
mind
why
it's
probably
magic
and
you
can
apply
it
to
other
input
union
proposals,
it's
about
after
completion,
when
people
like
after
completion
is
a
big
part
of
graphical
success
in
a
sense
and
if
we
have
to
complete
one
field,
it's
like
natural
full
right,
but
if
it's
group
of
fields
so
after
completion
experiences
became
really
weird.
So
I
cannot
have
a
trade
off
of
moving
everything
to
the
right.
D
H
Also
so
I
hear
what
you're
saying
with
the
auto
completion
of
the
single
versus
many
fields,
but
moving
on
to
another
auto
completion,
the
the
whole
tact
union
approach
is
easier
to
autocomplete
than
doing
fragment
spreads.
For
example,
it
involves
the
user
needing
to
know
a
lot
less
things,
it's
easier
for
tools
like
graphical
Explorer,
for
example,
to
just
like
check
the
checkbox
on
that
field,
and
now
you
get
access
to
this
tree,
so
I
think
it
should.
H
The
tagged
unions,
I,
think,
will
be
very
easy
and
nice
for
beginners
to
use,
though
I
think
one
of
the
big
things
that
I'm
gonna
have
to
answer.
Whilst
writing
this
RFC
is
rules
on
when
should
you
use
a
tagged,
Union
versus
when?
Should
you
use
the
existing
Union
types
that
we
have
in
graph,
QL
I?
Think
that's
going
to
be
a
fun
question
for
me
to
try
an
answer.
Yeah.
L
We
had
the
option
of
considering
something
in
the
future,
like
an
additional
new
type,
perhaps
called
a
struct
which
would
have
features
such
that
it
could
be
used
both
in
inputs
and
in
outputs,
as
is
which
wouldn't
require
necessarily
a
different
input
type
in
the
different
appetite
you
would
have
to
restrict
things
like.
You
can't
have
arguments,
and
you
know
some
other
details,
but
that
is
with
this
tag.
Unit
approach
like
that
is
a
possible
future
which
could
bring
some
real
benefits
and
is
quite
an
interesting
Avenue.
H
Yeah
definitely
I
think
the
the
idea
of
structs
is
effectively.
You
can
allow
the
existing
scalars
which
work
both
as
input
and
output
and
the
structs
themselves,
which
workers
input
and
output
and
have
that
work
throughout
the
whole
tree
potentially.
But
what
it
would
do
is
break
from
our
existing
input
and
output
types.
H
L
H
That's
a
great
question
so
currently
no
I
have
thought
about
it
previously,
with
the
previous
version
of
the
tact
Union
and
in
migration.
Paths
was
really
easy,
but
for
assuming
that
you
already
build
things
in
that
pattern,
but
when
it
comes
to
the
the
new
form,
no
sorry
that
was
not
fair.
If
you
already
have
tact
unions
in
your
schema,
then
you
could
convert
them
over
to
the
new.
You
know,
directive
approach,
tagged
unions
very
easily,
and
it
would
just
be
effectively
stronger
validation
of
what
you
already
have.
H
So
I'm
not
sure
that
there's
gonna
be
an
easy
way
of
supporting
that
I'm
at
the
moment.
I
think
it's
probably
just
gonna
have
to
be
a
new,
a
new
field
and
deprecated
the
old
field,
which
is
unfortunate,
but
it's
definitely
something
I'll.
Give
thought,
because
that
was
one
of
the
main
things
I
wanted
to
support
was
existing
usages
of
tagged
types,
yeah.
K
I
think
actually,
the
immigration
purpose
as
you
as
you've
mentioned,
there
might
already
be
users
who
to
actually
implement.
Thank
you,
Nance,
just
not
release
from
validation,
so
for
some
it
would
not
change
anything
just
validate
what
they've
done
before,
whereas
on
the
other
hand,
the
approaches
that
introduced
an
additional
discriminative
field,
nothing
like
that
really
exists
formally.
D
That's
right,
yeah,
the
the
tags.
Union
pattern
is
already
pretty
common
for
inputs,
where
you
want
an
input,
Union
and,
and
that's
part
of
I,
think
the
motivation
for
this
path
is
looking
out
to
existing
schema
and
seeing
for
people
who
want
this
feature.
What
are
they
already
doing
and
the
time
time
Union
pattern
is,
is
somewhat
pervasive,
but
there's
actually
two
different
migration
paths
that
are
completely
incompatible
with
each
other,
and
so
we
just
have
to
pick
one.
D
One
of
them
is
looking
for
existing
uses
of
unions
and
seeing
what
people
are
doing
and
then
finding
a
way
to
help
them
in
and
that's
a
case,
that's
a
vote
in
favor
of
something
like
a
tag
Union
or
one
of
because
that's
a
common
pattern.
The
other
is
a
field
that
or
an
input
that
currently
is
yet
a
union
but
would
like
to
become
a
union.
So
it's
going
from
a
single
input
and
then
wants
to
become
multiple
inputs.
D
So
maybe
it
previously
took
a
string,
and
now
you
want
it
to
take
a
string
or
an
object
that
they're.
The
sum
of
the
other
proposals
make
that
potentially
non-breaking
change,
and
this
would
not
provide
a
non-breaking
change
for
that
path.
You'd
have
to
you
know,
provide
a
different
shape
to
your
input
to
allow
that
to
happen.
So
you
know,
there's
trade-offs
there
and
I
think
it's
kind
of
similarly
for
outputs,
there's,
no
clear
path
for
how
you
would
convert
like
if
you
decided
that
your
typical
union
is
actually
a
better
model.
D
K
D
Yeah,
so
this
I
think
this
doesn't
account
for
that
going
from
one
to
many
going
from
like
many
to
even
more
many
like
that
works,
going
from
existing
in
formal
tags,
unions
to
formalize
tagged
unions,
that's
gonna
work
really
well
going
from
one
thing
to
many
things:
I
think!
That's
that's
a
breaking
path!
If
you
do
it
directly,
you
got
to
find
a
way
to
do
it.
The
introducing
a
new
thing
and
deprecating
the
old
thing,
which
you
know
that's
like
I,
think
it's
inevitable,
like
the
other
way
around
has
the
same
problem.
D
You
know
if
you
looked
at
one
of
options,
one
through
five,
which
might
make
it
easy
to
go
from
a
single
field
to
many
fields.
But
if
you
go
look
at
all
the
people
who
are
asking
for
input
unions
and
see
what
they're
doing
they're
doing
something,
it
looks
like
a
tag
Union
and
it
would
be
a
breaking
change
to
migrate
from
a
tag
Union
to
one
of
these
other
proposal
for
an
input
Union.
So
either
way
we
face
some
amount
of
breakage.
D
You
will
just
have
to
kind
of
document
them
and
make
a
judgment
call
for
which
is
the
best,
but
right
now
it
seems
pretty
favorable
that
the
tagged
union
is
probably
the
most
promising
path
for
its
simplicity
and
and
for
its
ease
of
adopting
system
use
cases.
D
I
mean
you'd
have
to
migrate.
The
the
problem
with
that
is
you'd
have
to
migrate
an
existing
scalar
to
a
tagged,
Union
and,
and
that
would
be
breaking
for
existing
clients
that
are
sending
this
to
plain
scaler.
That's
what
I
meant
about
the
breaking
path,
but
you're
exactly
right
that
that
topic
came
up
in
our
or
some
community
discussion,
and
you
end
up
having
to
do
kind
of
clever
things
like
evaluating
the
scale
or
last,
and
it
kind
of
gets
right
back
into
the
whole
complexity
of
like
not
being
able
to
predict.
G
One
one
thing:
I'm
like
I,
don't
really
like
it's
called
the
Union
I
think
if
we
have
like
two
things
in
the
Union
as
a
kind
of
Union
and
to
create
a
bunch
of
confusion,
so
I
also,
if
we
go
one,
if
we
discussed
by
all
five
opportunities,
I
think
input
union
is
appropriate.
If
we
stop,
can
we
can
converse
him
on
one
off
I?
G
Think
like
we
need
to
think
like
variant
or
like
actually
in
some,
some
one,
which
is
called
the
memes
in
rust
and
Swift
and
I
usually
was
another
point
which
is
work.
I
actually
think
it's
worth
to
capture
in
are
you
see
is
that
I
was
opposing
one
of
initially
and
man
document?
Was
it
add
one
additional
where
in
output,
but
when
I
walk
why
programming
languages?
They
actually
do
that
and
nobody
have
a
big
issues
with
that.
G
Even
those
that
you
put
like
one
one
additional
thing
off
one
thing:
I'm
really
interested
into
exploring
is
one
of.
Why
can
rock
above
when
it's
like
separate
groups
of
one
separate
group
of
exclude
mutually
exclusive
views?
Not
one
group
but
separate,
and
its
have
like
an
additional
benefit
that
migration
pathways
good,
because
it's
you
basically
can
can
put
it
inside
any
input?
G
Union
you
want
I
need
to
type
you
want
if
it'd
help,
if
it
doesn't
have
required
fields,
you
can
just
work
through
one
open
side
and
duplicate
over
the
fields
and
I
think
what
it
will
boxing
is
I.
Think
boxing
is
necessary
price
to
pay,
but
by
warming
like
for
you
to
have
couple
boxes
in
one
level,
it
will
save
a
lot
of
boxing
a
lot
of
unnecessary
Aware's,
especially
why
s
understand.
G
D
That's
a
good
idea.
One
thing
I
do
want
to
highlight
that
I
think
is
a
great
suggestion
of
honest.
It's
being
careful
about
the
naming.
You
know,
I
I
think
we
could
maybe
kind
of
shape
her
way
around.
If
we
had
two
types,
one
type
was
called
Union
and
one
type
is
called
input
Union
like.
Maybe
it
would
be
somewhat
straightforward
to
explain
the
difference
between
those
two
I
think
if
we
have
Union
and
tagged
Union
and
one
of
them
like
tagged
unions
can
also
be
using
outputs
like
we're
just
aiming
for
confusion
there.
D
Whenever
someone
says
the
Union,
we're
gonna
have
to
ask
them
to
qualify
exactly
what
they
mean
by
that
one
of
the
thing
I
mean
even
just
in
the
in
our
little
subcommittee
meeting,
we
were
like
shedding
a
bit
I,
think
naming
and
it
started
with
one
of
and
then
we
realized.
Oh,
these
are
actually
kind
of
tagged
unions
and
we
were
using
that
terminology
I
think
the
naming
for
this
is
up
in
the
air
and
the
RFC
should
kind
of
make
that
clear
and
kind
of
pull
it
out.
D
A
couple
paths
that
we
can
use
for
naming
of
intentionally
in
the
agenda
just
called
this
tag
type
instead
of
tagging,
Union
type,
I.
Think
that's.
If
you're
gonna
go
with
something
like
tags,
then
I'd
I,
just
ditched
the
word
Union
and
the
the
you
know,
aspiring
CS
degree
holder,
can
read
tagged
and
and
note
that
that
means
tag,
unions
and
everyone
else
can
just
see
tag.
They
are
also
eating
them
types.
D
I'm
glad
that
you
brought
that
up,
because
looking
at
that,
like
dang
it
we
just
reinvented
Swift
enums
and
we
already
have
a
type
called
Deena,
and
actually
it
would
not
make
any
sense
at
all
to
merge
these
two
together,
just
because
the
the
grammar
that
we
have
doesn't
make
that
a
reasonable
thing
to
do,
but
but
yes
and
some
languages
called
exactly
this
type
in
you
know,
but
like
point
taken,
we
need
to
be
kind
of
flexible
with
the
naming
and
hopefully
we'll
arrive
at
something.
D
K
D
K
Point
out
one
thing
about
what
Benji
has
written
up
and
it's
just
which
I
found
that's
really
good
and
really
useful.
So
I
really
like
the
examples
that
use
the
the
name
of
the
type
to
ask
the
field
names,
because
in
a
way,
what
we
really
what
we
want
is
a
way
to
uniquely
identify
which
type
it
is
as
the
Union
and
type
names
already
give
us
that
uniqueness.
So
that's
one
bit
of
redundancy
removed
and
one
last
thing
to
think
about
as
a
developer
or
as
a
schema
writer.
H
That's
that's
interesting.
I
I
was
also
I,
also
quite
like
that
approach,
but
I
also
like
the
flexibility
of
not
having
to
have
that
approach
and
one
of
the
biggest
values
that
we
get
from.
Not
having
that
approach
is
this
symmetry
between
the
input
and
the
output,
so
input
objects
and
output
objects
cannot
have
the
same
name
so
like
you
might
have
a
cap
on
the
output,
but
I
can't
input
on
the
input.
H
So
when
we
do
that
in
a
tagged,
we
could
actually
potentially
have
two
different
tags
that
have
the
same
structure
and
they're
both
called
cat,
even
though
one
of
them
is
the
input
type
and
is
called
a
cat,
which
is
a
cat
input
and
the
other
one
is
a
can
output
type
which
has
cat,
which
is
just
a
cat.
Sorry,
if
that
was
confusing.
H
How
is
that
that
but
yeah,
basically,
that
symmetry
is
a
good
reason
to
actually
go
the
slightly
more
verbose
version
and
give
you
the
flexibility
to
name
the
fields
whatever
you
want
to
call
them.
That
said,
I
also
agree
that
the
shortened
form
is
is
very
nice,
so
I
think
for
now
we're
gonna
stick
with
the
named
version,
but
it
is
definitely
interesting
having
it
I'll.
D
Tell
you
why
I,
why
I
really
recommend
the
name
version
and
and
would
be
cautious
of
using
the
type
name
instead.
Two
two
reasons:
one
is
for
semantics.
So
if
you
see
an
input
that
says
string
colon
and
then
it's
a
string
looking
at
that
in
isolation,
it's
not
immediately
clear
what
that
means.
But
if
you
see
something
that
says,
filter
colon
and
string
you're
like
oh,
that
must
be
filtering
by
the
string.
D
D
But
in
that
scenario
you
have
to
define
every
single
type
to
each
end,
up
being
a
unique
type
in
your
schema
and
and
that
ends
up
with
some
kind
of
SDL
and
an
introspection
below.
So
it's
kind
of
nice
that
the
tag
type
just
encapsulates
all
those
in
a
single
definition.
Instead
of
spread
across
multiple
definitions,
so
trying
to
make
sure
you
didn't
miss
that
point.
H
D
D
Obviously,
the
next
step
there
is
to
actually
draft
an
RFC
that
captures
everything
I,
think
that's
our
action
item,
keyword
for
the
nose
to
make
sure
that
we
have
that
and
then
hopefully,
we'll
have
something
more
concrete
to
discuss
in
one
of
the
future
meetings,
but
any
other
questions,
comments
or
concerns
on
the
input,
unions
and
intact
types,
discussion
and
direction.
I.
K
Wonder
if
there's
value
in
having
both
the
discriminator
field
approach
and
the
tank
union
in
regards
to
symmetry
to
what
we
now
have
has
output
union
types.
So
the
discriminator
field
approach
would
mirror
that
pretty
pretty
well
in
a
way,
not
in
the
sense
that
you
can
just
dump
the
whole
structure
there,
but
semantically
it's
kind
of
the
same
and
I'm
sure
they
are
use
cases
for
it.
But
it's
nicer
to
use
than
the
tact
approach.
D
That's
a
really
good
question.
You
know
I
think
our
we
should
lean
in
the
direction
of
fewer
concepts,
but
that
doesn't
necessarily
mean
that
the
right
answer
here
is
that
more
than
one
of
these
things
is
warranted.
I
think
we'd
have
to
make
a
clear
case
because
anytime,
you
have
more
than
one
way
to
do
it.
You,
then
you
have
to
kind
of
have
a
post
somewhere.
D
That
says
like
here's,
how
to
think
about
whether
to
use
option
A
or
option
B
to
model
things,
and
so
that
that
just
costs
that
will
have
to
factor
into
that,
but
you
may
be
right,
I
think
actually
in
an
earlier
discussion
on
silly
this
last
meeting,
but
a
previous
one.
We
did
actually
discuss.
Maybe
maybe
we
need
to,
and
it
wouldn't
be
totally
surprising
if
we
ended
up
back
there,
so
I'm
glad
you
called
that
out.
It's
something
we
should
continue
to
consider.
I.
G
Have
a
question
so
I
personally
white
one
off
and
it
look
like
we.
We
we
go
in
there,
but
I'm
interesting
I
have
some
ideas
for
variation
of
100:1.
That
I
suggested
about
groups
in
which
an
exclusive,
when
some
other
white
things
that
I
want
to
suggest
a
one-off.
But
to
put
it
in
the
same
document,
it
will
create
more
confusion
and
make
it
bigger.
So
what
the
right
place
to
discuss
variations
I.
H
Think
I'm
the
best
way
to
do
that
and
correct
me
if
I'm
wrong
Lee
would
be
to
propose
it
as
an
additional
solution
in
the
input
unions,
RC
document,
so
solution
7,
for
example,
I-
think
if,
if
it's
sufficiently
different,
otherwise
you're
welcome
to
just
chat
it
over
with
me
and
we'll
see
whether
it's
something
that's
worth
encapsulating,
but
it
sounds
like
some
of
these
are
more
broader
changes
and
may
actually
be
a
different
solution.
Just
like
our
solution,
six
is
a
combination
of
one
and
three
yeah.
D
Yeah
I
think
that's
reasonable,
although
you
know
I
view
this
as
a
little
bit
of
an
inflection
point
in
the
discussion
on
you
put
unions,
you
know
like
this.
This
last
phase
has
been
about
understanding
the
problem
domain,
existing
examples,
research,
exploring
the
solution
criteria
and
starting
to
see
what
the
potential
paths
forward
looked
like.
It
feels
like
now
we're
creating
some
pretty
serious
gravity
around
this
direction
and.
D
D
There
were
the
best
way
to
do
that
is
to
hop
in
on
slack
I.
Think,
that's
how
we've
been
scheduling
them
in
the
past
is
usually
instant,
sometimes
Benjy
will
say:
hey,
we
should
meet
again
one's
a
good
time
and
then
people
will
chime
in
so
I
think
you've
been
doing
that
in
the
working
group
channel.
H
D
We'll
just
try
to
keep
that
in
the
me
channel
that
way.
Anyone
who
who
wants
to
participate
in
those
breakout
sessions
can,
although
I'm
hoping
I,
mean
those
have
been
incredibly
helpful,
but
I
do
hope
that
we
can
keep
some
momentum
happening
asynchronously.
They
are
writing
up
these
documents,
but
those
meetings
are
a
good
deadline
and
hold
us
to
making
sure
we
maintain
progress
so
and
I
think
it's
worthwhile
to
keep
doing
them.
The.
D
This
is
great.
You
know,
I
we've
been
talking
about
this
one
for
for
literally
years,
which
is
not
that
uncommon
for
for
graphical
RFC's.
It
takes
a
while
to
land
on
something
that
we
feel
I
can
stand
the
long
test
of
time,
but
you
know
I
think
I
think
we
can
confidently
say
we're
making
very
steady
progress,
especially
this
in
the
last
couple
of
months,
so
really
proud
of
all
the
work.
That's
happened
there
so
far.
D
D
D
I
I
H
Cool
so
yeah,
basically
I
was
doing
this
as
a
proof
of
concept
to
see
whether
it
would
be
feasible
or
not.
So
you
know:
I've
picked
up
your
mind
a
little
bit
over
this
and
I.
Think
the
graphical
spec
is
a
great
test
of
this,
because
it's
quite
a
big
spec
and
I
have
achieved
it.
As
far
as
I'm
concerned,
there
were
a
few
subtle
changes
to
the
graphic
your
spec
formatting,
to
allow
it
cerise
to
the
spec
and
the
formatting
to
allow
for
it.
H
H
Text
set
set
text
that
would
make
sense.
It
needs
an
extra
T
but
yeah
fine,
whatever
so
I've
since
prettier
only
wants
to
output
the
the
hash
form
of
their
headers
I've
come
up
with
a
new,
simpler
form
of
that
which
is
to
bold,
then
the
word
within
the
title.
So
you
have
the
hash
and
then
you
have
bold
the
thing
so
hash
double
asterisk
title
and
that
works
just
fine.
So
effectively,
all
of
your
headers
are
all
hashes,
but
the
main
one
is
also
bolded,
which
obviously
it's
already
bold.
H
So
you
don't
see
any
difference
in
the
output,
but
it's
enough
for
the
spec
MD
to
pull
out
that
difference.
I've
had
to
do
a
lot
of
unescape
of
the
markdown
that
was
escaped
dollars,
underscores
and
asterisks
in
particular,
I've
had
to
rewrite
the
way
that
you
handle,
like
the
underscore
character
that
you
use
for
white
space.
I've
had
to
tweak
that
I've
introduced
another
one
which
is
double
underscore,
which
represents
like
white
space
and
at
most
one
new
line,
so
that
existed.
H
D
H
H
H
A
HTML
div
to
an
absolute
minimum,
so
maybe
that
would
be
a
better
as
a
follow-up
check,
so
yeah,
basically
it
exists,
I
hacked
it
together.
It
took
me
longer
than
I
was
hoping
it
would
I
think
it
was
best
part
day
hours
in
the
end,
but
that's
because
I
massively
minimized
the
amount
of
differences
in
the
the
graphical
spec
itself.
H
I've
also
done
all
the
graph
QL
changes
to
the
spec
that
I
needed
to
in
a
separate
pull
request
such
that
you
can
see
that
there
is
no
difference
for
those
yeah
anyway,
so
it's
all
theoretically
easy
to
follow,
but
broadly
what
I
need?
Okay
from
on
on
you
is.
Are
you
happy
with
my
changes
to
spec
MD
because
those
are
necessary
for
them?
The
changes
to
the
graph
go
spec.
D
G
I
just
might
match,
because
it's
like
so
when
I
changed,
my
exam
for
much
I
just
met
Benjamin
and
like
Benji,
provide
gifs
and
URLs
that
it's
not
breaking
anything
so
awake
yeah,
except
like
one
thing,
because
I
I
reviewed
it
to
real
things
and
actually
like
it
was
what
some
changes
in
grammar.
We
constantly
forget
to
add,
remove
something
your
name's
Athenian
drummer,
because
we
have
it
multiple
ways
we
have
like
in
every
section.
G
Small
pieces
of
grammar
and
Appendix
B
with
grammar,
so
like
one
of
the
changes
is
how
wait
format,
rules
and
I've
just
done
shared
on
the
each
other
yeah,
so
I
went
to
create
a
great
script
screenshots
and
actually
like
he
did
like
really
good
research
about
how
to
do
it
properly.
I
would
never
guess,
but
official
mortals
back
says
you
need
to
add
workspaces
at
the
end
of
the
wine
for
for
it
not
to
like
format
as
one
wine
but
I'm
having
concerns
about
well,
because
it's
hard
to
after
why
a
lot
of
people.
D
That
one's
rough
is
I
know
my
editors
auto-config
to
strip
trailing
whitespace
is
from
lines
I.
Imagine
other
people's
probably
also
is
yeah
and
crappy.
F
G
Like
every
time,
I
get
wake
Sam
PR
with
changes
inside
the
grammar,
even
if
it's
strictly
datura,
if
somebody
just
picks
on
something
I
need
true,
it's
why
I
click
on
include
preview
leans,
but
it's
everything
comforts
and
for
me,
it's
like
it's.
This
issue
is
just
I'm.
Okay
with
like
this
doing
well.
G
If
whether
we
run
some
spell
checker,
it
can
be
triggered
on
some
words
inside
the
grammar,
even
though
they
were
correct
so
like
for
everything
else
for
names
for
like
wearables,
for
name
of
the
average
they
like
distinguish
in
some
way,
which
is
like
understandable
for
photos,
but
grammar
rules.
They
way
they
say,
except
for
spec
and
be
no
other
tools.
No
is
it
like
Grandma
rule,
or
is
it
like
a
text?
So
I
I,
like
I,
agree
with
benches
that
put
it
in
code
box.
D
Don't
know
I'm
nervous
about
that,
because
a
lot
of
like
kind
of
the
whole
original
purpose
of
this
was
that
the
markdown
should
look
good
like
when
you're,
when
you're
editing
this
you're
you're
not
typically
running
a
loop
with
the
like
spec
empty
tool
and
loading
up.
The
HTML
page
jump
to
right
place
like
editors,
have
built-in
formatting
of
markdown,
and
it's
a
it's
a
good
way
to
got
check
that.
D
The
thing
that
you're
writing
makes
sense,
especially
since
there's
often
formatting
within
grammar
rules
and
algorithm
rules,
and
those
formattings
have
been
have
been
chosen
to
work
well
with
markdown.
So
I
really
I
would
like
to
avoid
having
to
just
say,
like
well
they're,
not
marked
out
anymore,
just
wrap
them
in
a
code
block
I
think
that
kind
of
defeats,
the
purpose
of
spec
MD,
but
I
do
think.
There
are
other
paths
like
I,
I
kind
of
agree
that
having
to
add
trailing
spaces
is
too
fragile.
D
H
F
H
Doesn't
matter
to
the
grammar,
what
the
format
is
that
you
render
ER
in
the
docs
right
if
we
were
to
trim
off
one
of
these
double
spaces
and
join
those
lines
together.
The
actual
output,
like
the
actual,
the
true
what
the
graph
your
spec
says,
would
still
be
the
same
thing.
It's
just
the
formatting
of
that
output
be
slightly
different.
Not
so
it's
just
a
formatting
concern.
Yeah.
D
D
M
and
n
right,
like
it
breaks
between
m
and
n,
because
it
puts
this
in
a
clean
four
column
display
that
makes
it
easy
to
see
all
the
alphabet
characters
and
any
other
formatting
would
make
it
harder
to
read.
So
it's
kind
of
intentional
that
this
leaves
it
in
a
spot
that
gives
you
some
control
over
that
formatting,
but.
H
My
concern
is,
if
you
add
bullets
here
in
the
markdown
you're,
making
it
less
clear
what
that
actually
means,
so
the
people
who
would
read
it
now
were
like
well,
it's
one
of
either
this
row
or
this
rail
or
this
row,
this
row
yeah
and
and
now
there's
this
extra
concept
of
bullets,
whereas
it
is
pure
formatting.
So
I
can
see
how
advanced
solution
of
sticking
in
a
code
block
so
that
the
the
formatting
is
persisted,
but
the
meaning
stays.
The
same
is
a
potential
solution.
The
other
thing
that's
worth
raising
I
mean.
C
D
D
H
F
H
D
D
Know
or
a
strict
white
space
at
the
end
of
a
line.
Probably
why
I
didn't
know
about
this
feature
is
that
my
editors,
always
just
stripped
them
out
I,
am
pretty
nervous
that
this
is
fragile.
You
know,
I
think.
The
the
only
place
where
I
would
be
concerned
about
a
bulleted
list
is
letter.
Letter
is
the
only
one
that
that's
you
could
potentially
read
as
confusing
digit
they're
all
on
one
line.
Anyway,
it's
like
you
could
even
just
delete
that
new
line
and
probably
be
fine.
D
The
directive,
location
ones
are
already
formatted
out
as
a
list
like
each
one
appears
on
their
own
line,
and
so,
if
you
put
bullets
in
front
of
each
of
them,
the
markdown
semantics
would
be
exactly
as
you
expect
them.
They
would
be
and
so
like.
If
it's
a.
This
is
a
quirk
that,
like
hey,
we
want.
We
want
to
preserve
this
grid
formatting
for
letter
and
the
quirk
of
how
we
do
it
is
bulleted
lists.
D
That
seems
like
the
the
least
bad
option.
If
what
we
want
is
the
ability
to
use
automated
tooling
to
do
formatting,
because
then
that
gives
us
control
over
that
formatting
and
that's
that's
really
what
we
care
about,
but
but
yeah
I'm,
pretty
nervous
about
trailing
spaces
as
it's
solved,
because
there
are
enough
tools
out
there
that
don't
understand
markdown,
they
just
understand
text
files
and
they
just
strip
trailing
whitespace
or
they
like
read,
highlighted
or
otherwise
kind
of
flag
it
as
a
problem.
I
think.
H
D
H
D
G
D
Plenty
of
other
places
in
here
where
I
like,
if
someone
is
formatting
anything
else
in
this
document
and
they
have
trailing
whitespace,
it's
almost
definitely
a
problem
right
like
any
of
these
other
grammar
rules
that
are
bulleted
lists
of
options.
If
you
had
trailing
whitespace
after
one
of
those,
then
that's
reading
problem
and
your
editor
is
right
to
point
out
that
that's
a
failure
so
like
I
do.
This
is
just
the
weird
quirk
of
markdown,
as
you
know
like.
How
else
would
you
differentiate
between
a
line
break
in
a
line?
D
G
H
H
One
one
comment
in
favor
of
this
is:
it
makes
the
existing
markdown
render
better
like,
as
is
in
the
graphical
spec
right
now,
and
also
this
works
with
the
existing
spec
nd.
So
we
could
like
merge
this
and
then
update
spec
MD
to
do
the
asterisks
and
and
then
migrate
to
that
as
a
second
phase.
My
main
aim
with
this
was
to
minimize
the
differences
to
the
spec.
G
D
This
is
just
a
matter
of
like
what
is
the
appropriate
way
for
us
to
format
multiple
lines
of
a
multi-line,
one
of
in
the
original
markdown
form
and
I,
really
don't
like
trailing
whitespace
just
because
tools
can
get
confused
and
I'm
I
really
don't
want
to
have
to
include
editor
config,
because
I
think
there's
plenty
of
other
places
where
trailing
whitespace
would
be
considered
an
error.
So
I,
you
know,
I
think
like
a
the
bullet
in
the
front
is
also
it's
semantically.
D
G
H
D
There's
there's
two
forms:
there's
one
outs
that
appear
it's
basically,
the
difference
between
like
an
inline
or
a
block.
Html
element
right,
like
one
in
line,
is
just
a
space
separated
list
and
the
other
one
is
a
grid.
It
just
so
happens
that
the
executive
create
declarative,
location
and
I
became
a
declared
of
location
or
directive
locations.
Those
are
a
grid
that
happened
to
have
one
column,
whereas
digit
is
a
grid
that
has
one
row
and
letter
is
a
grid
that
has
multiple
rows
and
columns.
H
To
argue
against
myself,
one
one
advantage
of
using
the
bulleted
approach
as
well
is:
it
means
where
the
syntax,
that
you're
using
leatherback,
tix
and
whatnot
make
the
line
rap.
Where
you
don't
want
it
to
the
asterisk
would
say
explicitly.
Here's
is
what
will
be
a
line
even
if
it
actually
wraps
in
the
mark
time.
So
that's.
D
That's
kind
of
the
whole
point
of
this
grid
form
and
I.
Think
that's
probably
part
of
why
you
see
me
kind
of
turning.
My
nose
at
this
approach
is
the
whole
point
of
the
second
form
is
to
give
you
control
over
how
that
grid
lays
out.
The
other
thing
that
we
could
do,
which
would
be
maybe
even
more
weird,
is,
is
actually
format
it
like
a
table.
You
could
format
it
like
a
markdown
table,
just
it
header
header
columns.
D
G
One
thing
we
need
to
consider:
that's
why,
like
I'm,
gonna,
guess
tables
people
in
academia,
they
like
grammars
and
the
right
to
publish
research
on
grammars,
so
I
expect
if
you
could
have
killed
continuum
directory
of
success.
People
start
publishing
academic
papers
about
graphically
grammar
and
everybody
in
academia
will
have
facepalm
if
we
start
doing
one
of
the
tables
because
they
wait.
G
G
D
I
mean
it's:
it's
a
quirk.
It's
like
half
on
one
half
on
the
other,
this
this
quirk
is
borrowed
from
the
C
API
in
the
JavaScript
API.
Both
format
they're
they're,
literal
identifiers.
This
way,
just
as
a
matter
of
like
fitting
there,
how
do
you
describe
your
like
what
letters
and
numbers
are
allowed
in
identifiers
in
an
ad
column
document?
They
line
break
it
and
they
line
break
it
in
this
form,
because
it's
easiest
to
read.
G
G
What's
your
proposal
I'm
like
so
when
my
main
concern
is
that
if
we
able
to
use
like
technical
writers,
linters
a
lot
so
I
know
action
item
for
me
is
to
try
it
in
wake
in
much
of
I
will
try
to
find
some
time
like
and
the
end
of
this
week
next
week
to
try
to
configure
something
because
I
I'm
not
sexist,
but
I
never
tried
them.
So
I
need
to
pick
one
and
yeah.
D
My
hope
is
that,
if
the
goal
here
is
to
be
able
to
use
prettier,
then
as
long
as
we
run
that
one
last
in
a
in
a
whole
phase
of
winters,
then
Islanders
can
do
whatever
ill-fated
dicks
that
they
want,
because
prettier
were
always
kind
of
format
it
correctly
in
the
end,
but
your
right
that
we
should
test
it.
I
mean.
G
White
winters,
in
a
sense
that
they
will
check
why
controls
they
check,
because
one
of
the
issues
is
that
venture
you
doing
a
great
reviewing
because
I'm,
not
a
native
speaker,
so
I'm
like
I'm,
totally
not
touching
anything
related
to
to
grammar
or
spelling
or
British
English.
So,
like
I'm,
worried
that
we
will
have
like
make
sure.
G
For
example,
you
use
some
British
wards
and
somebody
use
American
words
and
because
I'm
my
co-founder
in
one
of
stuff-
and
we
do
in
stuff
for
technical
writers,
I'm
aware
that
the
research
tools
this
solace
problem
of
having
like
you,
can
specifically
forbid
like
saying
it's
only
American
English
or
British
English,
and
not
like
a
mix
of
both
so
actually
like.
Okay
to
turn
taboo,
which
I
will
try.
It
and
I
will
report
inside
the
nation.
Okay,
I'm,
okay
with
Mike
and
anything
that
work
with
such
tools
sounds.
D
H
I
wanted
to
highlight
a
couple
of
things.
One
is
this
is
just
a
hack
type
code
to
make
it
work.
It's
not
like
I
haven't
bothered
to
structure
it
for
full
code
review.
I
want
you
to
okay,
the
concepts
that
I'm
doing
before
I'll
worry
about
structuring
the
code
right.
Secondly,
it's
a
breaking
change,
so
it
would
be
a
major
version,
but
I
think
broadly
like
it
would
run
against
the
existing
graph,
your
spec
without
any
change
of
behavior
but
I'm,
not
sure
other
other
people
using
spec
MD
that
you
know
what
there.
D
Are
other
people
that
are
using
it,
but
certainly
graphical
is
the
biggest
so
I
think.
As
long
as
we
can
kind
of
point
to
in
what
scenarios
it
will
break,
then
we
can
at
least
talk
about
them
and
see
if
there's
a
way
to
reduce
the
break
surface
area,
and
if
we
can't
then
we'll
just
kind
of
talk
about
it,
when
we
make
a
version
bomb,
I
think
probably.
H
H
Yeah,
mostly
it's
just
a
change
to
the
to
the
grammar
subtle
changes,
but
by
O'hara
underscores
are
handled.
I've
had
to
split
a
few
tokens
up
into
more
production
so
that
we
can
handle
them
in
the
way
and
also
I'm
not
familiar
with
them
with
Peggy
is
like
this
is
the
only
time
I've
used
it.
So
if
there's
things
that
I'm
doing
the
wrong,
what
could
be
done
better
I'd
love
that
people
I'll.
D
H
Yeah
and
the
other
thing
I
guess,
is
this:
this
change
with
the
asterisks
would
that
be
for
existing
users
of
speck
MD?
Is
that
gonna
cause?
Any
ambiguity
like
is
there?
Is
it
already
accepted
that
a
hyphen
or
asterisk
could
be
an
entry
in
a
one
of
rather
than
the
five
a
it
makes
a
bullet?
If
you
see
I
mean
oh.
D
H
D
I
think
that's
the
safest
approach,
because
that
means
that's
the
that's
actually
the
worst
breaking
case,
because
it
could
be
that
people
are
using
multi-line
windows
but
like
having
a
bullet
as
actually
an
option
in
one
of
your
one
of
sand.
It
just
happens
to
be
the
first
character
in
the
list.
It's
like
that
is
a
theoretical
possibility,
shirt
someone
could
be
using
it.
That
way.
Are
they
I,
don't
know,
but
like
someone
using
a
multi-line
one?
D
Probably
and
then,
if
we
made
it
a
requirement
to
have
those
lines,
then
that
makes
me
migrating
more
difficult.
Also,
I
think
it
would
be
nice
if
what
we
can
do
is
first
make
changes
to
spec
MD.
Do
we
release
pull
that
release
into
the
graphical
spec
and
run
it,
and
then
now
we
have
the
new
capabilities,
and
then
we
can
start
landing
any
additional
changes
so
like.
If
you
wanted
to
add
the
bullets
in
the
one
of
right
now,
the
resulting
HTML
output
would
be
incorrect
right.
H
Yeah,
okay,
that
that's
reasonable
I
was
trying
to
think
of
ways
that
that
would
break
but
I
think
so
long
as
we're
not
running
prettier,
yet
we'd
effectively.
What
I
keep
on
having
to
do
effectively
is
is
do
the
changes
you
make.
The
changes
to
the
the
spec
that
need
to
be
made
run
prettier
on
it
check
the
output
of
the
spec
MD
HTML,
make
sure
it's
the
same
and
then
go
back
to
the
beginning.
Again.
Is
it's
quite
cumbersome,
work
but
yeah
I
think
that's
probably
the
best
route
for
ya.
F
D
No
HTML
changes
and,
depending
on
how
we're
able
to
do
that,
we
might
actually
be
able
to
get
away
with
a
change.
That's
not
version
3.
You
know,
it'll
make
it
so
that
all
existing
documents
continue
to
format
as
expected,
and
so
we
can
make
a
decision
whether
it
warrants
a
breaking
breaking
change.
You
go
to
version
3,
I,
think.
H
G
G
Another
another
thing
know
because
you
get
so
much
github
issues,
another
thing
not
to
discuss
here,
but
just
we
had
discussion
about
google
Summer
of
the
season
of
documentation,
sucks
seasonal
docs
here,
so
we
will
get
like
the
one
or
two
swords
and
we
have
like
four
projects.
If
you
want
something
to
increase
their
weight,
I
think
like
it
will
be
great
to
help
to
have
some
help
with
suspect,
but
not
this
free
month
and
not
from
a
person
who's
not
really
familiar
with
I'm.
G
So
Judy
as
part
of
preparation,
we're
worried,
is
championing
moving
crackle
deport
gets
bit
without
touching
any
content
so
idea,
so
I
don't
touch
anything,
don't
redesign
anything
because
previous
attempt
failed.
You
remember
with
a
tonigh
he
champion,
but
it's
not
his
fault.
Just
like
nobody
way
reviewed
his
work.
Nobody
wake
give
him
direction.
What
to
do
so
reiteration
is
not
to
change
anything
even
like
style
course
leave.
Everything
is
ease.
Just
move
like
system
to
get
me
I
like.