►
From YouTube: Thinking Out Loud #9 — with Ben Hutton
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
Hello
once
again,
folks
welcome
back
to
thinking
out
loud
one
one
more
week
thanks
everyone
who's
joining
already
in
the
chat
who's
been
messaging
me
privately
welcome
to
new
watchers
as
well.
For
those
who
don't
know
what
thinking
out
loud
is,
it
is
meant
to
be
the
most
boring
show
ever
so
this
is
not
a
show
at
all.
This
is
this
is
a
thinking
session,
and
so
I
regularly
invite
usually
weekly.
I
invite
guests
to
join
me
in
a
thinking
session.
A
Right,
so
we'll
be
thinking
about
something
every
week,
something
usually
different
but
related
to
async
api,
and
you
know
and
android
projects,
there's
no
script.
So
what
you're
seeing
here
is
I'm
improvising,
so
I'm
just
even
now,
I'm
improvising,
I'm
just
sharing
what
comes
out
of
my
head
and
and
yeah.
So
every
week,
like
I
said,
I'm
sharing
I'm
inviting
someone
to
to
share
thoughts
out
loud
right.
If
you
want
so
cool
welcome
once
again,
one
thing
before
I
continue.
A
I
want
to
make
this
clear
so
we're
live
on
youtube
on
on
how's.
It
called
the
amazon
platform.
I
can't
I
can't
even
remember
anyway.
Forget
I
forget
about
it
like
so
we're
in
multiple
streaming
platforms
right,
but
the
only
one
that
that
the
only
one
that
supports
closed
captions
is
is
youtube
for
now,
right
so
or
at
least
that's
the
one
that
we
figured
out
how
to
how
to
do
it.
A
So
if
you
have
some
ideas
on
how
to
make
it
work,
please
let
us
know
right.
So
if
you
need
closed
captions,
please
head
over
to
our
youtube
channel
and
enable
them
there
right.
So
it's
it's
really
enabled,
and
except
for
my
accent,
everything
should
be
working
perfectly,
so
so
cool
just
wanted
to
mention
that
that's
it,
it's
not
a
secret.
A
So
for
today's
episode
I
invited
ben
hatton
from
json
schema
specification
and
json
schema
project
who
also
happens
to
work
with
me
at
postman
and
and
yeah.
It
was
easy
for
me
to
invite
him
like
it
was
like
I
have
it.
I
had
it.
I
had
him
at
hand
right
so
so
it
was
like.
Yes,
we
still,
we
will
actually
speak
so
we,
I
don't
want
to
delay
this
more.
So
welcome
ben
hi,
hey.
B
C
Yeah
sure
hi,
I'm
ben
hutton,
thank
you
for
the
introduction
fran,
I'm
the
lead
on
the
jason
schemer
project
and
I
work
at
postman
full-time
on
open
source,
which
is
really
great
to
be
able
to
do
currently.
I
kind
of
describe
my
role
as
the
hat
stand
in
that
I
wear
many
hats
at
a
time
and
try
to
get
everything
done
that
nobody
else
wants
to
do.
Or
you
know
we
don't
have
enough
people
to
do.
A
Cool
introduction,
I
actually
support
your
description
of
wearing
many
hats.
I
I
can
feel
you
it
is.
It
is
weird
sometimes
look
at
me,
I'm
an
engineer
and
I'm
doing
a
live
stream
here
now
right.
So
what
am
I
doing
so
so
yeah?
I
can.
I
can
easily
relate
there
so
well.
We
have
people
in
the
chat
already
so
eric
vilde
welcome
and
hello.
I
also
want
to
take
the
opportunity
to
mention
that
you
can
join
the
conversation
anytime.
A
So
this
is
a
thinking
session
between
in
in
the
live
stream.
It's
going
to
be
between
ben
and
I
right,
but
anyone
can
join.
So
if
you
have
thoughts,
just
share
them.
If
you
have
questions
share
them
as
well,
so
don't
don't
feel
bad,
don't
feel
shy
about
it
and
and
share
your
thoughts.
Let's
make
it
like
a
community
live
stream.
A
If
you
want
cool
so
so
ben,
I
think
mandatory
question
right
now
is
what's
up
with
decent
schema
like
what's
I've
seen
that
there's
been
a
lot
of
movement
lately
and
you
might
want
to
give
us
a
summary
of
the
of
the
last
years.
C
Yeah
sure
so,
since
the
the
release
of
the
last
version
of
the
specification
we've
been
looking
to
see
what
issues
the
community
are
facing
and
how
it's
being
received,
particularly
how
open
api
is,
is
using
json,
schema
and
yourself
as
well
and
other
similar
products.
How
everybody's
using
json
schema
after
the
big
changes
that
we
made
in
the
last
version
of
the
specification
added
a
bit
more
complexity
for
implementers,
but
we're
seeing
more
and
more
implementers
pick
that
up
as
they
support
the
newer
versions.
So
that's
20
2012..
C
Excuse
me.
So
we've
been
working
a
lot
on
the
next
version
of
the
specification
which
is
going
to
focus
on
fixing
up
and
and
ambiguities
in
the
specification
that
anything
things
that
aren't
quite
as
we
intended
them
to
be,
or
things
which
are
very
certain
questions
or
could
be
interpreted
in
different
ways.
C
We've
nailed
down
most
of
those
we're
at
one
issue
left
now.
There
are
one
or
two
issues
left
a
couple
of
months
ago,
and
I
you
know
rather
stupidly,
put
out
a
treat.
Oh
we're
nearly
done
now.
We've
only
got
one
or
two
issues
left,
and
then
we
created
some
more
as
we
received
some
more
feedback.
A
lot
of
what
I've
been
doing
since
I've
joined
postman
is
is
more
to
do
with.
C
You
know,
outreach
communication
engagements
with
the
community
engagements
with
the
industry
and
that's
really
starting
to
pick
up
now.
We
have
one
published
case
study.
I
I
was
so
excited
to
be
able
to
publish
our
first
case
study
in
both
english
and
japanese,
we're
seeing
a
lot
of
uptake
in
jason,
schema
from
the
japanese
community,
the
japanese
speaking
community
anyway,
and
that's
really
great
to
see
such
a
big
discussions
on
twitter,
about
jason
schema
and
we've
made
out.
C
C
I've
been
finishing
up
a
case
study
today
on
a
rather
exciting
scientific
project
and
how
they're
using
our
data.
Fortunately,
unfortunately,
nasa
wasn't
able
to
do
a
case
study
with
us,
which
is
a
shame
because
they
do
use
jason
schema
and
that
would
have
been
really
great.
C
C
So
we
have
a
lot
of
structure
and
governance
in
place
that
enables
us
to
grow
and
mature
and
take
on
new
community
members
and
particularly
as
I
joined
postman,
we
wanted
to
assure
people
that
postman
isn't
looking
to
own
jason's
scheme
or
claim
any
sort
of
control
over
it,
and
it
is
it's
still.
An
open
project
and
and
owned
by
the
community
sounds.
A
Familiar
here,
yeah
familiar
topic,
right,
yeah,
that's
that's
really
cool
and
and
and-
and
I
think
actually
the
fact
that
you
also
joined
you
know
like
open
js,
or
did
you
finally
open
or
are
you
still
in
the
in
the
process
of
did
I
we.
A
C
For
openjs,
when
you're
an
incubator
project,
you're
fully
joined
and
we
sort
of
have
have
a
checklist
of
things,
they
would
like
us
to
do
and
we
sort
of
try
and
work
towards
a
different
project
status
by
completing
those
those
tasks.
A
C
A
C
C
Join
opengs,
I
think,
there's
a
sense
of
you
know
immediate
credibility.
There
are
not
hundreds
and
hundreds
of
products
in
the
opengs
foundation.
There
are
a
select
few
hello,
hello.
I
have
an
invite
another
guest.
So
thank
you
for.
C
C
Oh
yeah,
please
do
you
know
it
does
give
us
an
immediate
credibility.
One
of
the
one
of
the
pain
points
for
jason
schema
is
people
not
realizing
they're
using
it
a
lot.
We
often
get
people
going.
Oh,
we
just
use,
we
use,
we
use
ajv
or
this
other
library,
and
we
have
this
config
file,
which
enables
us
to
do
some
validation
and
and
we're
often
like
yeah,
that
that
could
be
used
by
other
implementations
in
other
languages
as
well
or
to
generate
documentation.
C
They're
like
whoa,
really
ajv
is
really
cool
right
and
I'm
like
no.
No,
it's
json
schema
and
that's
what
you're,
using
in
your
open
api
definitions
as
well
and
all
of
your
other.
You
know
your
your
library
generation
tools
and
things
that
you
use
to
generate
models
for
your
databases
and
and
yeah.
It's
often
surprising
to
people
so
that
immediate
credibility
of
being
a
product
in
its
own
right
and
the
recognition
that
it's
a
credible
and
sustainable
project,
I
think,
is
really
good.
C
People
are
evaluating,
json,
schema
versus
other
solutions,
and
you
know
a
lot
of
the
other
solutions.
Have
big
organizations
around
them
like
apache
thrift
or
google's
protocol
buffers
and
json
schema,
has
really
sort
of
been
on
its
own
in
that
sense
and
that
it
hasn't
had
a
major
backer.
C
It's
nominally
part
of
the
ietf,
but
it's
not
actually
part
of
any
ietf
processes.
So
it's
not
part
of
an
itf
working
group.
It's
what's
known
as
an
independent
submission,
and
anybody
can
make
those
independent
submissions
if
they're
of
a
reasonable
quality
and
they're
actually
at
some
sort
of
specification.
A
Yeah,
that's
that's
good
to
know.
Actually
you
mentioned
that
some
people
are
using
this
schema.
We
don't
know
when
they're
using
json
schema
and
that's
still
like
sounds
familiar.
A
So,
actually
I
wanted
to
share
something
that
I
don't
know
if
I
have
it
at
hand,
because
I
wasn't
expecting
you
to
mention
this.
So
let
me
share
this
screen
because
I
have
something
here:
where
is
it?
Okay?
C
A
A
Yeah,
no,
let
me
just
again.
A
So
it
is
actually
well
so
I
wanted
to
show
I
want
to
show-
and
I
hope
I
can
still
do
it
it's
so
I'm
tracking
lately,
I'm
trying
to
categorize
every
every
question
that
we're
taking
on
the
on
the
on
the
slack
workspace.
A
Usually
you
know,
like
all
the
questions
that
people
ask
about
the
spec
about
the
tooling
and
so
on,
so
I'm
trying
to
categorize
them,
and-
and
I
have
you
know
so-
I
I've
done
a
slack
app
to
just
to
help
me
with
this
with
this
process,
which
at
some
point
I'm
gonna,
I'm
gonna
probably
talk
about
it
and
and
share
it
with
the
rest
and
and
I'm
now
working
on
visualization
like
how
many,
how
many
times
are
people
asking
or
what's
what
is
the
the
most
frequent
category
of
questions
right
and
you
know
that
we
have
a
huge
problem.
A
I
will
say
in
in
async
api,
which
is
a
publish
and
subscribe
meaning,
and
you
probably
have
heard
of
them-
maybe
not,
but
man.
What
I
mean
is
that
if
you,
if
you
work
with
this
in
kpi,
just
five
minutes,
you
instantly
think
like
that's
weird
like
published,
but
I
really
subscribe
subscribe.
But
I
really
publish
everything
like
something
is
broken
here
right,
and
so
I
was
expecting
this
to
be
the
number
one
and,
to
my
surprise,
that
was
the
number
two
and
the
number
one
category
is
questions
about.
A
Json
schema
related
to
json
schema
not
facing
kpi.
So
people
come
to
the
async
api
workspace
to
ask
questions
on
how
to
on
how
to
define
their
their
data
with
this
schema,
which
is
another
point
that
I'm
gonna
mention
afterwards,
so
so
yeah
and
and
and
I
find
it
like
kind
of
frustrating
because
it's
like
yeah
people
are
not
realizing
that
this
is
just
a
schema,
even
though
we
mentioned
it
on
the
spec
like
no.
This
is
just
a
schema.
A
Here's
an
a
small
example
and-
and
you
can
go
to
the
website
or
to
the
ietf,
rfc
and
and
read
more
right
and
know
more
about
how
to
use
this
part
of
the
spec,
which
is
not
the
spec.
It's
just.
This
schema
right
so,
but
even
like
that
people
I
understand,
like
people
most
probably
are
not
reading
the
spec.
A
You
must
probably
learning
by
example
and
finding
that
there
is
a
chunk
here
that
lets
you
define
data
again
and,
and
then
they
yeah
they
just
come
to
us
and
to
to
ask
questions
right,
which
yeah
like,
like
I
said
like,
can
be
sometimes
frustrating
and
we
always
respond
like
we
don't
make
any
differentiation
like
nah.
This
is
not
our
problem.
You
go
to
jesus,
that's
luck
and
figure
out,
no
way.
That's
fine!
A
A
And
it's
like
yet
another
place
to
ask
questions
and
it's
a
little
bit
like
for
them.
It's
a
little
bit
of
a
broken
experience.
Right,
like
everything
is,
you
know.
C
I'm
wondering
if
we
can
connect
up
a
slack
channel,
because
I
know
we
both
have
oh
yeah,
that's
one
of
the
other
things
that
jason's
schemer
now
has
has
you
know
full
or
some
sort
of
paid
slack
access.
Well,
hey
at
last,
I'm
wondering
if
we
can
connect
up
some
sort
of
json
schema
async
api
channel.
So
people
can,
you
know,
ask
on
your
server
but
have
access
to
the
the
broader
depth
of
knowledge
from
the
json
schema
server.
A
Yeah,
I
was
wondering
now
as
well
like
this.
This
could
be
a
interesting
interesting
thing,
so
so
we
can
actually
send
people
to
the
channel
not
to
the
not
to
another
workspace
right,
yeah,
so
yeah,
so
yeah.
No,
definitely
something
I
mean,
let's
not
forget,
to
propose
this
on
on
the
slack.
A
So
so
we
can
do
it
and
yeah
and
there's
something:
hey
dave,
hey
so
answer
here
by
the
way.
So
there
is
something
that
that
I
said
before.
People
come
to
our
channel
to
our
workspace
and
and
ask
for
ways
to
define
their
data
using
json
schema,
and
that
itself
is
wrong
right
because
yeah
so
json
schema
is
not
for
defining
data
structures
and
correct
me.
If
I'm,
if
I'm
mistaken,
it
is
for
defining
validation
rules,
let's
say.
C
Is
that
correct?
Will
it
be
like
yeah?
I
mean
the
way
we
generally
sort
of
phrase
it
is
for
defining
constraints.
You
know
people
are
more
familiar
with
this
when
they
think
about
their
database
structures.
You
know
you
have
you
have
your
your
table.
C
Definition,
which
is,
is
your
your
table
schema,
but
then
you
also
have
constraints
that
you
can
place
over
those
columns
or
those
those
rows
as
well-
and
you
know,
json
schema
defines
the
constraints,
but
it
also
kind
of
defines
some
of
the
structure,
and
I
think
that's
probably
why
it's
it's
confusing,
because
it
doesn't
sit
strictly
in
that
sort
of
constraint
based
world
because
it
kind
of
also
constrains
the
the
different
types
of
data
you
can
have
in
what
you
traditionally
think
of
as
tables
or
in
an
object.
A
So
actually,
I
was
just
thinking
that,
like
when
I,
when
I
created
async
api,
I
was
like
at
that
time.
I
was
using
heavily
open
api
and
and
well
struggling
at
that
time,
and-
and
I
was
like
also
thinking
that
this
json
schema
part,
which
I
mean
in
the
case
of
open
api
swagger
older
versions.
It
was
like
in
the
mix
of
like
just
schema
with
something
something
different
like
it
was
a.
I
think
I
don't.
I
don't
remember
who
the
who
do
you
find
it's
like.
C
A
A
Aside
from
that,
I
was
understanding
this
as
a
modeling
tool
right
as
a
modeling
language
right
so
to
model
your
data,
which
or
or
mixed
with
validations,
to
be
honest
like
at
the
time
I
don't,
I
didn't
even
think
about
it,
like
I
somehow
understood
understood
it
like
this,
but
in
my
head
it
was
in
the
open,
apa
context.
It
was
like.
Oh,
this
is
to
model
my
request
or
my
response
shape
right
and
yeah,
and
you
can
also
place
validations,
which
is
cool
but
yeah
in
my
head.
A
It
was
all
about
modeling,
the
data
and,
and
that
was
translated
into
async
api,
of
course,
because
I
had
this
confusion
on
open
api
and
therefore
I
I
copied
the
that
confusion
to
to
async
api,
and
now
we
have
the
same
problem
missing,
kpi
right,
unsurprisingly
right
so
it's
like
so
so
what
happens?
Is
that
one
of
the
I
mean
aside
from
documentation,
one
of
the
biggest
use
cases
for
us
is
generating
code.
A
So
people
want
to
generate
code,
but,
depending
on
your
json
schema
definition,
it
might
be
easy
or
possible,
or
it
might
be
hard
or
impossible
right
and-
and
I'm
gonna
explain
myself
so
so
what
happens
so
for
those
who
are
watching
there
are
some
schema
constructs
that
are
like.
I
don't
know
like
additional
properties
that
not
keyword
one
of
any
of
all
of
right,
all
of
them.
A
All
of
these
features
are
really
cool
for
validation,
but
when
you
want
to
translate
this
into
code
generation
like
let's
generate
a
type
on
a
java
class
or
a
typescript
type,
or
something
like
that,
how
do
you
translate
the
not
or
how
do
you
translate
the
additional
properties?
Damn
it
right
yeah,
so.
C
That's
a
good
question,
and
it's
one
that
we
thought
about
for
a
long
time
and
we
kind
of
you
know
we
thought
about
it
for
the
before,
probably
not
before
ace
and
kpi
existed,
but
for
like
three
four
years
at
least
we
see
people
coming
in.
We
see
people
with
these
use.
C
Cases
which
are
beyond
validation
and
code
generation
is,
is
one
of
those
primary
ones
and
documentation,
generation,
form
generation,
all
the
sorts
of
generation,
where
you're
kind
of
using
json
schema
as
a
proxy
for
your
your
data
definition
or
your
interface
definition,
because
it
kind
of
looks
like
that
sort
of
structure.
So
why
not
use
it?
As
that
and
that's
you
know,
that's
that's
fine
to
do
in
all
honesty.
C
People
can
do
that,
but
each
each
tool
which
digests
that
schema
is
gonna,
do
so
in
a
slightly
different
way.
As
things
stand
right
now,
so
we
we
thought
about
how
we
can
enable
all
these
different
use
cases,
because
we
certainly
didn't
have
the
people
power
to
to
handle
those
ourselves.
C
We
were
kind
of
stretched
super
thin
as
it
was
did
we
do
we
lose
fran.
Can
you
still
hear
us?
Oh
I'm
happy.
C
B
C
Yeah,
like
we,
we
clearly
saw
all
these
needs
for
for
use
cases
beyond
validation,
because
json
schema
as
it
is
right
now
is
you
know
not
something
you
can
reliably
use
for
code
generation
or
for
form
generation
or
any
sort
of
other
generation,
and
we
kind
of
we
wanted
to
support
all
these
and
enable
these
use
cases,
but
empowering
others
to
pick
them
up.
So
we
developed
this
idea
of
vocabularies,
which
are
parts
of
or
jason's
theme
or
sets
of
keywords.
C
You
can
write
as
extensions
to
json
schema,
but
you
can
define
them
as
part
of
your
schema
in
a
way
that
makes
it
reusable
so.
The
open
api
initiative,
for
example,
have
their
own
dialect
and
vocabulary,
which
adds
a
couple
of
extra
keywords.
C
Those
additional
keywords
are
only
annotations,
so
they
don't
add
any
extra
validation,
but
people
have
written
their
own
extensions
and
there
are
various
implementations
which
are
for
their
own
extensions.
Some
of
them
were
before
the
notion
of
vocabulary.
Some
of
them
are
after,
but
I
think
this
is
the
direction
that
cogeneration
needs
to
go
and
there
was.
There
has
been
there
some
effort
to
start
that
discussion
and
there's.
C
There
is
a
special
interest
group
within
the
open
api
for
code
generation,
but
we
haven't
been
able
to
find
anyone
to
champion
the
idea
long
term,
having
watched
a
big
standard
organizations
observe
how
people
with
limited
time
and
resources
can
move
forward
with
projects,
particularly
when,
when
doing
that,
work
is
not
their
day,
job
a
massive
part
of
their
day
or,
if
they're,
mostly
trying
to
do
other
things,
and
the
standards
are
part
of
a
side
project.
C
If
you
like,
I
I've
seen
and-
and
I
agree
with
their
their
change-
to
need
to
identify
projects
or
initiatives
with
a
champion,
because
unless
there's
somebody
to
really
drive
the
work
forward
and
do
the
leg
work.
If,
unless
somebody
really
really
wants
it
to
happen,
it's
not
always
going
to
happen.
C
It's
got
a
greater
chance
of
succeeding
if
somebody's
there
to
champion
it
push
it
forward
and
chair
meetings,
talk
to
the
community
and
keep
engaging
on
those
topics,
because
the
reality
is
that
the
core
team
doesn't
have
the
time
to
do
that
with
one,
let
alone
all
of
the
other
various
use
cases
which
are
beyond
validation.
I
mean
we're
just
about
you,
know,
handling
the
validation
use
case
and
there's
still
so
much
work
to
do
there,
but
we're
certainly
here
to
enable
those
use
cases.
C
You
know
we've
been
engaged
with
the
the
starting
of
the
we're
calling
it
the
interface
description,
language
vocabulary,
that
work
has
started.
There's
been
lots
of
issues
and
questions
raised
and,
as
you
sort
of
dig
down
into
those
issues,
you
realize
they're,
quite
complex
and
they're
gonna
take
up
a
lot
of
your
time
and
then
people's
interest
sort
of
peters
out,
we've
also
engaged
with
our
database
vendors.
So
we've
engaged
with
oracle
and
with
mongodb,
and
there
is
work
on
creating
a
vocabulary
which
relates
specifically
to
databases
and
sql.
C
It's
slow
work,
you
know
it's
not
something.
These
people
are
focused
on
100
of
their
time,
and
you
know,
even
when
you
are
specification,
work
can
be
pretty
slow
because
you
want
to
do
it
in
an
open
and
collaborative
way,
and
although
that
takes
more
time,
I
believe
it's
the
only
way
in
which
these
standards
can
really
evolve
in
a
way
that's
meaningful
and
has
longevity
that
you
otherwise
wouldn't
have.
C
I
realize
that's
quite
a
long,
long
answer
to
the
question,
but
I
was
kind
of
we
can't
hear
you
fran.
At
least
I
can't
hear
you,
I
don't
know
if
everybody
else
can
hear
you.
C
A
Sorry,
man,
sorry
I
I
I
I
was
doing
a
huge
effort
to
hear
you
why
to
listen
to
you
while
trying
to
fix
the
problem
so
you'll
have
to
forgive
me.
Can
you
summarize
what
you
just
said
because
I
was
like
you
can't
imagine
disconnecting
and
connecting.
C
Okay,
it's
there.
If
anybody
has
the
the
passion
and
the
time
to
champion
it
and
try
and
push
it
forward,
we're
more
than
happy
for
someone
to
come
in
and
do
that,
but
we
just
don't
have
the
capacity
to
do
that
ourselves
as
we're
trying
to
do
everything
else
related
to
to
adjacent
scheming,
core
and
validation
and
all
the
bits
that
come
with
that.
A
So
that
they
just
said
that,
like
I
think,
there's
a
this
ideal
vocabulary,
I
think
if,
if
I'm
not
mistaken,
that's
the
name
right
idl.
A
It's
that's
the
name
of
the
the
of
the
reaper
so
that
that
is.
That
is.
I
think
that
that
will
be
like
a
cool,
a
cool
way
moving
forward,
but
I
was,
as
I
was
reading
to
I
was
reading
through
the
you
know,
the
issues
there
which,
by
the
way,
jonas,
who
works
with
azam
on.
B
A
Took
the
lead
there
and
started
creating
issues
and
and
starting
the
discussion
which
I
appreciate
what
I
was
finding
is
that
it
was
kinda
not
possible
or
not
yeah
not
really
possible
to
have
that
like
so
the
way
vocabularies
work
in
json,
schema
and
correct
me,
if
I'm
mistaken,
is
that
so
we
can
add
that
on
that,
on
that
vocabulary
we
can
add
stuff,
but
we
cannot
remove
some
stuff
from
using
schema.
Is
that
correct,
like,
like,
I
don't
know,
validation,
some
validation,
stuff.
C
I
mean
you:
can
we
very
very
strongly
advise
against
it,
because
you
break
the
interoperability
of
json
schema?
If
you
do
that,
and
that's
one
of
the
discussions
that
we
sort
of
had
to
have
a
lot
with
that
with
oracle
as
they
develop
the
databases
vocabulary,
you
know
if
people
come
in
with
their
existing
schemas
and
want
to
plug
them
into
another
tool
if
they
then
find
out.
Oh,
you
can't
use
that
schema
because
it
uses
these
keywords.
Then
they're
gonna
go
oh
well,
I'm
not
doing
that.
C
Then
they
might
not
even
have
any
control
over
the
schemas.
It
might
be
seen
with
some
other
places.
So
it's
it's.
It
seems
like
a
good
idea
for
new
projects,
but
there
are
so
many
existing
schemas
out
yeah
there
that
it's,
it's
just
an
interoperability
nightmare
to
do
it
and
it
and
it
defeats
yeah.
A
That
will
that
will
definitely
be
a
problem
but
yeah
sorry,
I
I
express
myself
incorrectly
here.
So
what
I
mean
is
that
you
can
you
can
pass
these
properties
json
schema
properties,
but
they
will
always
validate
as
true,
let's
say,
like
they're
always
valid,
like
you
effectively
ignore
them.
You
know
what
I
mean,
so
it's
like,
for
instance,
for
code
generation.
We
have
not.
We
have
additional
properties,
we
have
other
other
stuff
right,
all
of
a
one-off
and
so
on.
A
Could
it
be
that
we
define
a
new
vocabulary
that
effectively
like
when
it
finds
a
nut?
It
just
simply
ignores
it
and
an
additional
properties
gets
ignored
and
so
on
it's
ignored.
So
you
can
pass
a
full
json
schema
document,
but
for
code
generation,
specifically,
this
key
keys
will
be
completely
ignored.
You
know,
like
you
know,
I.
C
Mean
you
you
can,
you
can
totally
add
your
own
semantics
to
specific
keywords
and
if,
for
the
the
context
of
code
generation,
you
want
to
say
we
don't
use
the
not
keyword,
and
you
can
even
you
know,
create
tooling,
which
links
the
schemas
that
are
using
this
vocabulary
to
go.
Actually
we
really
don't
think
you
should
be
using
schemas
with
the
not
keyword
in
there,
or
at
least,
if
you
do,
you
should
be
aware
of
the
considerations
and
concerns
around
that.
C
C
So
that's
definitely
the
possible,
you
think
yeah,
it's
totally
possible
to
do
that.
Obviously
it
limits
the
the
uses
and
you
might
have
a
more
simplified
dialect
that
you
use
as
your
base
for
defining
the
code
generation
vocabulary,
but
it
can
still
be
used
with
validation
as
well.
I
mean
it
depends.
You
know
if,
if
the
context
is
multi-use
case
or
single
use
case,
obviously
it
has
more
utility
if
it's
multi-use
case,
but
a
lot
of
instances
and
situations.
People
generally
just
need
the
basics.
A
All
right
so
yeah,
so
let's
put
a
little
a
little
bit
of
context
here.
So
what's
what's
happening,
let
me
just
yeah
like
explain
why
I'm
am
I
asking
all
these
questions
right,
so
so,
I'm
currently
in
investigating
for
version
three
of
the
spec,
if
we
should
be
separating
data
definition
from
data
validation
right.
A
So
one
also
it's
clear
that
in
some
cases
you
will
want,
you
will
only
want
the
the
data
definition
like,
for
instance,
generating
a
type
generating
code,
as
in
code
I
mean
as
in
generating
classes,
types
and
so
on
interfaces,
so,
for
instance,
in
this
case
format
email.
I
don't
care
right.
It's
like.
I
don't
care
if
it's
an
email
as
long
as
it's
a
string.
That's
that's
all!
A
I
need
to
know
right
in
this
case
right,
but
I
still
want
to
have
format
email,
because
in
other
cases
it
will
be
useful,
for
instance,
in
documentation.
I
would
love
to
know
that
it's
an
email,
and
so
I
can
clearly
display
in
the
documentation
that
it's
an
email
right
and
even
I
can
maybe
that's
not
the
best
example,
because
validating
emails
is,
if
not
impossible.
A
It's
super
cool
but
let's
say,
for
instance,
with
numbers
so
h
and
it
has
to
be
above
18
right
so
so,
if
h
has
to
be
above
18,
I
may
want
to
also
generate
code
in
certain
contexts
where
it
really
validates
the
it
does.
It
does
the
validation
right
of
the
data,
but
that's
like
another
type
of
code
generation.
A
If
you
want
right,
so
I
it's
like
type
generation
or
interface
generation
and
other
code
generation
right,
so
my
cat
is
still
getting
around
and
up
and
I'm
afraid
that
she
breaks
something
else.
A
So
so
that's
a
I
was
investigating
on
that
like
how
we
could
do
it.
So
we
separate
the
definition
from
from
validation
and-
and
so
I
thought
like-
oh
so-
why
not?
A
Where
we,
where
we
let
people
specify
their
payloads,
for
instance
the
message
payload
or
the
message
headers
we
only
let
or
we
right
now
they
can
just
plug
the
json
schema
there
directly.
So
I
was
thinking.
Oh,
we
probably
can
split
this
in
two
and
say,
like
definition
and
here's,
your
css
schema
and
validation
and
here's
your
other
json
schema.
But
then
I
thought,
like
definition
with
json
schema,
why,
like
maybe
we
should
be
using
json
schema
in
the
definition
field?
A
Maybe
we
should
be
using
in
this
case
I
was
thinking
on
avro
jtd.
You
know
like
json
type,
dev
and-
and
I
was
actually
like-
investigating
a
little
bit
more
json
type
def
for
that
like
to
to
actually
like
propose
it
as
a
the
default
for
for
data
definition,
but
to
leave
json
schema
for
data
validation,
right
of
of
the
data
structures,
so
so
yeah.
A
So
I
was
I
was
at
that
point
I
was
I
was
at
that
point,
but
then
I
realized
like
yeah,
that
sounds
cool
in
theory
when
you
start
a
new,
a
fresh
project,
a
greenfield
project
right
and
you
have
nothing
defined
yet.
A
But
when
you
have
an
existing
project
with
lots
of
json
schema
documents,
you
don't
want
to
be
converting
those
to
jtd
or
avro
or
whatever
else
right.
So
you
want
to
use
your
json
schema
as
a
data
definition
language.
You
know
what
I
mean,
so
it's
like
as
I
as
as
people
are
expecting
that
this
will
work
there
right
or
not
there,
but
in
this
context
right
so
so
yeah.
A
I
was
wondering
like
what
options
do
we
have
here,
because
I
will
hate
to
have
to
propose
that
we
changed
the
def,
the
default
to
jtd
or
avro,
just
because
this
schema
doesn't
have
a
vocabulary
for
that
or
it's
impossible
to
have
to
have
a
vocabulary
for
that.
But
at
the
same
time
I
understand
that
you
might
want
to
remove
complexity
from
jesus
schema
and
and
not
go
in
this
direction
right.
So
I
don't
know
like
I
just
yeah
just
thinking
out
loud
like
that.
A
These
are
like
this
is
the
the
the
place
where
I'm
on
right
now
like
we
need
to
provide
these
two
capabilities
and
can
think
on
a
better
alternative.
C
Yeah
I
mean
it's,
it's
a
real
problem
right
and
this.
This
is
why
we
came
up
with
this
notion
of
of
vocabularies
to
enable
the
people
that
do
have
time
where
it's
really
really
important
for
them
to
work
it
out
to
go
away
and
and
and
write
those
I
mean
you
know,
there's
nothing,
stopping
you
creating
your
own
dialect,
which
you
define,
which
might
be
similar
to
a
decent
type
definition
that
is,
is
more
limited
or
is
more
expansive
than
jason
schumer.
You
know
we've
we've
talked
about.
C
Could
you
constrain
the
keywords
that
are
allowed
to
be
used
and
yeah?
You
could
totally
do
that.
C
That
is
an
option
that
you
could
explore,
but
then
you
are
going
to
be
limiting
the
interoperability
of
those
schemas
yeah,
so
that
there
are
always
going
to
be
trade-offs
in
terms
of
what
solution
you
go
with
the
other
one
is,
is,
you
know,
adding
some
keywords
by
adding
your
own
vocabulary,
which
enables
you
to
augment
simple,
schemas
or
more
complex
schemas
with
the
information
that's
required
to
generate
those
those
classes?
C
If
you
look
at
something
like,
I
can't
remember,
which
library
is,
there
is
a
library
to
do
with
form
generation
that
has
its
own
extension
to
do
with
with
the
ui
and
form
generation
where
you
can
define
all
the
things
like
the
field.
A
C
And
where
certain
things
go
and
the
styling,
it
might
even
be
called
like
ui
schema
and
it's
its
own
object
that
sits
alongside
in
an
adjacent
schema,
object
and
defines
loads
of
additional
and
extra
things
which
give
it
all
the
semantics
it
requires
and
to
fill
in
the
gaps
that
it
can't
with
json
schema
and
trying
to
overload
the
the
semantics
of
keywords
and
json
schema.
So
that's
that's
another
avenue
you
could
explore,
but
it's
it
limit
again.
C
It
limits
the
interoperability
to
in
terms
of
using
the
json
schema
for
code
generation
elsewhere,
because
you've
built
it
specifically
with
your
use
case
in
mind.
Building
building
generic
solutions
is
really
hard
and
that's,
I
think
why
people
haven't
done
it
yet,
not
only
because
it's
hard
in
the
first
place,
but
for
it
to
be
worth
bio,
it
needs
to
have
buy-ins
from
multiple
vendors,
which
is
is
why,
with
the
the
database
vocabulary,
having
multiple
database
vendors
on
board
is
is
really
important.
C
A
Yeah
now
I
mean
I
was
thinking
that
yeah.
I
was
trying
to
think
now
if,
if
there's
something
that
we
could
or
that
we
would
want
to
add
like
we,
we
probably
would
don't
want
to
add
anything
new
to
the
spec.
We
just
want
to
change.
We
just
want
to
ignore
stuff
right.
So
so
it's
like,
like,
like
I
said,
like
not
additional
properties,
all
of
one-off
and
probably
some
some
other
stuff,
like
format,
email,
for
instance,
format.
Datetime,
though,
might
be
not
ignored.
A
So
you
want
to
know
if
the
string
is
a
date
and
therefore
you
might
want
to
generate
a
date
type
instead
of
of
of
a
string,
I
mean
just
I
will
have
to
explore,
but
there
will,
I
think,
if
we
could
just
come
up
with
a
solution
where
we
can
ignore
certain
stuff.
So
if
you,
if
you
provide
this
a
full
json
schema
document
to
a
tool
that
is
accepting
only
only
the
idle
vocabulary,
then
I
mean
the
idea.
A
You
know
the
code
generation
or
type
generation
or
interfacing
race
or
whatever
vocabulary.
Then
you
should
be
able
to
do
it,
but
you
know
like
nothing
should
be
failing
because
it
has
a
not
or
it
has
a
additional
properties
or
whatever
right
just
it
will
just
look
into
properties,
probably
type
properties
and
so
on.
Just
the
basic
stuff,
and-
and
that's
it
right
like
I
think
it
will
be-
I
don't
know-
could
be
a
cool
solution.
C
Yeah
I
mean
it's,
it's
it's
a
viable
option,
but
obviously
there's
weighing
that
against
people
not
being
able
to
use
their
existing
schemas,
most
schemers
will
use
additional
properties
because
they
want
to
constrain
to
only
be
using
the
the
properties
that
are
defined.
You
know,
ignoring
it
kind
of
makes
sense.
There's.
Also
the
consideration
of
the
composability
people
are
using
unevaluated
properties
to
enable
schemas
to
be
composed,
but,
as
you
say,
it
might
be
completely
irrelevant
for
for
async,
api
and
code
generation.
C
It
might
not.
You
know
either
way,
if,
if
you
don't
use
their
validation
vocabulary
and
you
just
use
the
the
core
and
the
applicator
vocabulary,
you're
still
gonna
have
to
handle
references,
but
then
you
can.
You
know
if,
if
there
are,
if
people
are
building
schemas
or
modifying
their
existing
schemas
for
a
particular
use
case,
they
might
be
more
willing
to
do
a
bit
of
that
work,
to
mold
them
or
change
them
or
modify
them
as
part
of
the
standardized
process
to
get
that
code
generation
or
they
might
not.
C
I
don't
know
it's
just
something
you
have
to
investigate
right.
You
have
to
decide
how
much
time
you
want
to
invest
in
working
on
a
solution
and
decide
how
you're
going
to
evaluate
the
success
of
that
solution,
and
that's
it's.
It's
very,
very
tricky.
A
I
agree
it
is,
it
is
it's
you
can't
imagine
how
much
I've
been
fighting
against
this
myself.
C
For
this,
but
for
five
years
right
so.
A
A
If
you
want
and-
and
that's
it
that's
all
we
will
have
to
do
thing
is
that,
of
course,
we
will
want
this
to
become
like
the
way
people
generate
code
with
json
schema
right,
not
just
the
way
people
generate
code
with
you
know
with
this
in
kpi
I
was
just
getting
a
call
in
right
now
on
slack,
this
is
crazy.
Everything
is.
C
Happening
today
I
mean
there's:
there's
an
alternative
approach:
approach
where
you
you
don't
need
to.
You
know,
define
that
you
can't
use
specific
keywords
and
it's
using
annotation
results
from
the
validation
process
or
even
using
the
annotations
from
you
know,
from
from
a
schema,
as
as
part
of
what
you
used
to
generate
your
classes.
C
That
way
you
you
remove
all
of
the
issues
around.
You
know
how
does
application
work
or
how
do
I
know
how
to
handle
this
situation
or
references,
because
you
don't
have
to
do
any
of
that.
You
just
use
json
schema
to
give
you
the
the
validation
result
and
the
annotations
from
that,
and
then
you
could
generate
classes
using
those
annotation
results.
C
You
would
have
to
define
specific
annotations
additional
keywords
that
are
annotations
to
give
you
the
semantics
that
you
need,
but
it
would
certainly
be
like
sidestepping
all
of
the
problems
you're
facing,
but,
as
you
know,
working
out
the
specifics
of
how
that
would
work,
I
guess
is
a
challenge,
but
it
is
another
avenue
to
explore
that
would
wouldn't
exclude
your
users
from
from
being
able
to
use
the
schemas.
They
have
right
now.
A
How
how
often
does
this
conversation
come
up
in
the
schema
community
like
generating
code,
but.
C
Well,
I
kind
of
don't
count
anymore
because
people
come
in
and
they
there
are
a
number
of
solutions
which
work
well
or
at
least
good
enough
for
generating
types
in
typescript,
and
that
seems
to
be
the
number
one
thing
people
want
and
that
seems
to
work.
I
don't
I
don't
hear
many
complaints
or
problems
around
using
that
and
compared
to
code
generations
in
other
languages.
I
have
seen
many
more
questions
and
complaints
saying
it
doesn't
work
for
me.
A
C
Know
handling
all
the
cases
like
references
and
additional
properties
and
all
that
sort
of
thing,
and
it
may
be
because
people
are
building
schemas
new
for
this
particular
context.
Sorry,
what
was
your
original
question?
I've
lost
my
flavor
like.
How
often
do
you
get
this?
Does
this?
C
I
think
you
know
we've
we've
kind
of
stopped
counting
because
it
comes
up
as
a
lot
or
often,
I
should
say
regularly-
and
we
say
yes
that
would
be
lovely
we'd
love
to
have
a
co-generation
vocabulary.
Here's
the
repository.
C
Would
you
like
to
contribute
and
then
kind
of
don't
hear
anything
occasionally
you
know
one
or
two
people
do
go
and
leave
some
comments
or
have
a
look
at
the
issues,
but
it
comes
back
to
this
this
champion.
C
Somebody
needs
to
champion
the
work
to
drive
it
forwards
and
have
a
criteria
have
a
direction,
have
an
agenda
and
and
drive
that
work.
I
it
needs
multiple
people
to
be
involved
to
make
that
happen.
People
want
it,
but
they
don't
want
or
there's
nobody,
putting
a
strong
enough
business
case
for
people
to
put
money
down
to
make
it
happen.
Yeah.
You
know
who
who
needs
this
as
a
big
organization
and
who
needs
it
enough
that
they
can
budget
some
people
to
work
on
it.
A
Yeah
we
do,
I
can
tell
you
like
says:
yeah
like
this
is
a
a
dichotomy
that
we
have
to
solve
at
some
point
like
people
or
you
know,
people
either
thinking
it's
for
definition,
plus
validation
or
thinking
it's
only
for
validation
or
thinking
it's
only
for
definition.
Actually,
it's
not
the
dichotomy
anymore.
A
So
the
thing
is
that
we
have
to
remove
this
confusion
as
soon
as
possible
from
async
api.
I
think-
and
I
think
it
will
also
be
beneficial
for
open
api,
to
remove
this
confusion
as
soon
as
possible,
so
people
stop
using
json,
schema
to
generate
code
and
then
start
complaining,
because
jason
schema
doesn't
do
whatever
whatever
they
thought.
It
would
do
right
and
and
yeah
you're
lucky,
because
they're
not
going
to
get
some
schema
to
complain
that
you
do
some
schemas
like
to
complain.
C
My
kind
of
hope
on
this
that
the
vendors
would
be
you
know
looking
at
open
api
3.1
and
going
oh,
that's
new
jason's
schema.
Let's
read
about
that.
Oh
it
has
all
these
new
things
and
we
need
to
do
code
generation.
Let's,
let's
write
some
tooling.
That
will
do
that
and
then
share
it
openly.
C
C
I
haven't
seen
any
any
code:
generators
for
open,
apa
3.1.
I
would
love
to
see
some,
but
I
I
haven't
seen
any.
B
C
It's
there
I
don't
know,
I
I
assumed
that
vendors
that
support
open
api
3.1
would
that
have
code
generation
for
3.0
would
come
generation
3.1,
but
maybe
because
it's
seen
as
a
non
major
version,
they
haven't
necessarily
realized
that
they're
going
to
need
to
put
some
serious
investment
in
you
know
my
preference
for
open
api
would
have
been
to
jump
a
major
version
to
signal.
Hey,
there's,
there's
a
major
change
here
in
the
underlying
specification
that
you're
actually
using,
but
it
was,
it
was
decided
otherwise,
and
that's
that's
fine.
C
You
know
we'll
we'll
try
to
get
some
communications
out
there
we're
slowly
getting
there,
but
I
don't
think
many
people
realize
how
big
a
jump
open
api
has
made
from
3.0
to
3.1
in
terms
of
your
payload
definition
is
absolutely
huge
yeah
and
that
I
think
part
of
the
challenge
is
because
there's
nothing
in
the
specification
that
defines
how
you
use
it
for
code
generation,
for
example.
It's
just
a
definition
and
you
can
interpret
that
definition
any
way
you
like
compared
to
json
schema,
which
is
used
for
validation.
C
We
have
a
test
suite,
so
we
can
say
with
a
good
level
of
certainty
if
you
write
an
implementation,
whether
you're
compliant
or
not-
and
I
think
you
know
for
code
generation-
that's
something
we
also
need
so,
maybe
even
starting
with
with
a
test
three,
you
know
what
things
do
you
want
to
happen
in
different
situations
is
a
good
way
to
go,
but
the
the
ideal
vocabulary
repository
within
jason
schema.
I
don't
think
we
even
got
to
that
point.
C
There
was
still
some
sort
of
fundamental
foundational
discussions
and
and
talks
around
exactly
how
such
a
thing
might
work.
So
there
are
a
lot
of
unanswered
questions,
yep
and
yeah.
I
think
I
think
a
true
solution
for
this
is
going
to
take
a
couple
years
realistically,
but
it
still
needs
someone
to
champion
it,
and
that's
that's
the
big
challenge
at
the
moment.
I
think
that
that's
my
perspective
on
how
how
this
is
gonna
work.
I
think
I'm.
A
Gonna
give
it
a
try
myself,
just
just
a
champion.
I
mean
not
to
jump
in
the
whole
coming
up
with
the
final
version
of
final
first
version,
but
to
push
it
forward
a
little
bit.
Yeah.
C
A
B
A
At
this
I
always
try
to
make
everything
myself
and
that's
actually
a
problem
too,
so
so
yeah
well,
I
mean
so
we're
about
to
make
an
hour
already.
So
is
there
anything
you
want
to
mention
from
jason
schema
now
that
you
have
people
watching
and.
C
Yeah
people
are
still
here,
yeah.
Definitely
I
mean
the
big
thing
with
jason.
Schemer
at
the
moment
is
we're
trying
to
hire
some
people
we're
trying
to
hire
a
developer
and
we're
trying
to
hire
a
technical
community
manager,
and
they
you
guys,
are
trying
to
hire
people
as
well,
but
you
know
jason
schema.
C
We
currently
have
me
full
time
and
that's
that's
it
and,
as
I
say,
you
know
where
of
many
hats,
you
don't
wear
any
of
them
for
long
enough
to
make
big
dents
in
that
the
bigger
projects
that
require
doing
like
tooling.
So
both
the
positions
are
still
open.
C
I'd
say
the
technical
community
manager
is
more
challenging
to
fill.
So
if
you
are
a
technical
community
manager
and
you're
looking
for
work,
please
do
let
me
know
via
twitter
or
any
any
other
way
that
you
know
how
to
reach
me
or
our
slack
or
even
you
know,
I'm
in
the
chat
and
say
hello.
We
may
be
shortly
filling
the
developer
position,
but
that's
still
unsure.
So,
please,
you
know,
do
apply.
The
applications
are
on
the
postman
website,
placement.com
careers.
C
So
if
you
want
to
work
in
open
source
full-time,
but
also
have
the
assurance
of
working
for
a
company
with
the
reputation
like
postman
then
apply
there
as
well,
but
yeah.
Please
do
reach
out
to
me
personally.
In
addition
to
applying
it,
that's
going
to
be
a
huge
benefit.
A
Yeah
I
was
going
to
mention
that
like
is
it
for
postman
to
work
full-time
on
json
schema
or
is
it
to
work
on
this
game
organization,
because
we're
actually
thinking
of
hiring
people
to
work
on
the
skype
organization?
Not
for
postman
not
for
any
company
but
for
http
organization,
directly
yeah.
C
Yeah
I
mean
it's,
it's
yeah,
we
don't.
We
don't
have
enough
funds,
as
jason
schema,
to
employ
anyone.
That
would
be
quite
tricky,
but
it
is,
is
you
know,
full-time
for
jason
scheme
of
the
organization
paid
by
paceman,
so
yeah
employed,
very
placement
working
for
jason
schema.
A
Okay
sounds
good
cool
ben,
so
thanks
a
lot
for
joining
and
sorry
that
I'm
looking
to
the
side,
but
you
know
you're
now
there
I.
A
Oh
thanks
thanks
really
thanks
for
joining,
because
it's
really
you
know,
like.
I
think
it's
a
it's
a
hot
topic.
You
know,
like
jason,
schema,
it's
been
going
through
a
series
of
great
things
in
the
last
years,
partly
thank
to
you
as
well.
So
I
think
I
think
I
thought
that
we
should
be
speaking
about
it
and
also
you
know
all
these
concerns
about
code
generation
that
are
relevant
for
the
async
api
community
and
in
the
end,
this
is
for
the
asynchpa
community
right.
A
So
so
I
thought
that
we
we
it
would
be
cool
that
we
discussed
these
things
and
and
yeah,
and
we
we
think
a
lot
out
loud
about
this,
and-
and
I
think
this
is
kinda
cool,
like
we
think
here
we
don't,
you
don't
have
to
come
up
with
an
answer
like
it's.
Okay,
if
you
don't
have
an
answer
or
you
know
like
like,
like
we
did
today
right
like
we
learn
things,
I
learned
things
from
you,
so
so
that's
really
cool
and
and
that's
a
conversation
started
right.
C
You
know,
I
would
say
you
know
it's
not
just
me
and-
and
you
all
know
this
as
well,
that
it's
it's
the
community
stepping
up
and
taking
ownership
over
things
and
just
like
the
test
suite
I've,
I've
hardly
had
to
be
involved
in
that
at
all.
I
just
leave
that
in
the
capable
hands
of
the
people
that
are
making
it
happen,
and
if
I'm
asked
to
give
opinions
I
might
but
yeah,
I
I
rarely
touch
the
test
suite
or
the
website.
To
be
honest,
so
there
are,
there,
are
you
know
the
community?
A
That's
cool
so
thanks
again
for
joining.
A
Everyone
for
watching
and
commenting
and
yeah,
see
you
next
week
with
another
episode
I'll
be
announcing
who's
who's
coming
next
week.
Once
it's
confirmed,
you
know
how
it
goes
so
so
yeah
thanks
ben
thanks.
Everyone.
Thank
you
so
much.
Thank
you.
Bye,
bye,.