►
From YouTube: Spec 3.0 meeting (March 30th, 2022)
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).
C
B
A
A
All
right
so
hello,
everyone
welcome
to
another
3.0
spec
meeting
before
we
get
going
with
the
agenda,
just
a
quick
reminder
that
if
you're
watching
on
youtube
twitch
or
any
of
the
other
platforms,
you
can
join,
live
as
well.
In
the
discussion
here
and
zoom.
A
B
B
That's
why
you
find
constructs
like
one
of
any
of
all
of
not
things
like
this,
which
are
not
easily
translatable
to
a
type
system
right
and
precisely.
There
is
what
I
want
to
go
so
when
we're
generating
code,
one
of
the
things
that
we
do
in
this
api
aside
from
rendering
documentation
and
and
other
stuff,
is
generating
code.
We
want
to
generate
out
of
the
payload
definition.
B
B
So
how
do
you
map
one
of
all
of
not
and
things
like
this
additional
properties?
How
do
they
map
to
a
type
system
in
java
or
in
typescript,
or
go
whatever
you
can't?
Basically,
these
things
can
can't
be
mapped,
but
they're
still
there
right
and
they
need
to
be
treated
somehow
so
I've
been
investigating
a
little
bit.
B
What
to
do
with
this?
If
we
should
be
so
ideas
that
I
came
came
up
with
was
we
should
probably
splitting
inside
async
api
itself
between
definition
and
validation
concept,
so
there
should
be
a
place
where
you
define
the
shape
of
your
payload
and
optionally.
B
There
will
be
another
place
where
you
can
add:
json
schema
to
validate
your
payload
and
and
then,
when
we're
generating
code.
For
instance,
we
don't
look
at
an
addition
at
the
validation.
We
look
at
the
definition
part,
but
yeah
like
that
sounds
well
sounds
good
in
theory
for
new
projects,
but
if
you
already
have
a
bunch
of
json
schema
definitions
in
your
company,
the
last
thing
that
you
will
want
to
do
now
is:
oh.
I
have
to
now
transform
this
json
schema
definitions
to
something
else
that
we
might
come
up.
B
Most
probably
that's
the
last
thing
that
you
will
want
to
do
right,
so
so
yeah.
So
one
idea
that
I've
been
investigating
there
is,
like
I
said
like
splitting
that
another
another
idea
that
came
to
my
mind
is
okay.
B
We
create
a
json
schema
vocabulary,
which
is
a
new
concept
from
json
schema
and,
and
we
make
it
we
can
start
with
our
own
like
the
async
api
code
generation
vocabulary,
and
what
will
it
mean
is
when
we
find
things
like
not
like
one-off
additional
properties,
these
things
that
don't
map
well
to
a
type
system.
B
We
simply
ignore
them
right.
So
it's
like
you
can
still
use
your
json
schema
definition,
but
they
will
produce
nothing
when
generating
code,
but
they
will
produce
something
when
generating
dogs
or
using
it
for
something
else
for
validating
a
message
payload
or
something
like
that,
so
it's
still
useful,
but
but
not
for
code
generation.
B
Right
thing
is
that,
on
my
last
thinking
out
loud
episode
last
week
with
ben,
I
was
already
spiking
the
idea
with
ben
there,
if
that
that
would
be
possible
right,
that
we
have
that
from
jason
schema
and
so,
and
so
we
don't
have
to
create
the
async
api
code
generation
vocabulary
because
yeah
that
that's
not
the
standard
right,
we
want
to
use
as
many
standards
as
possible.
So
if
json
schema
could
be
offering
this
as
a
code
generation
vocabulary
vocabulary,
that
would
be
amazing
right,
but
yeah.
B
His
response
was
something
that
I
completely
agree
is
like.
They
need
help
with
this.
They
they
can't
cope
with
everything,
of
course,
so
so
people
need
help
there
need
to
help
there.
B
That
is
not
really
a
problem
yet,
and
we
can
just
go
with
the
flow,
knowing
that
this
is
not
quite
right
and
then
eventually
fix
it
on
that
f4
version
or
five
version,
or
something
like
that.
D
A
So,
instead
of
us
defining
that
we
should
always
use
json
scheme
and
we
have
our
own
async
api
json
schema
the
wrapper
object.
I
guess
we
can
call
it
right,
it's
basically
get
removed
and
we
just
have
standards.
You
can
use
avro,
you
can
use
json
schema.
You
can
use
json
type
definition.
You
can
use
whatever
standard
you
want
to
to
use
right,
but
each
set
of
standards
come
with
each
set
of
pros
and
cons.
A
D
Is
there
any
equivalent
to
what
we
have
with
this
json
scheme
and
stuff
in
open
api?
I'm
just
curious.
If
we
can
learn
from
that.
B
So
actually
open
api
is
using
json
schema.
It's
using
a
newer
version
of
json
schema,
which
will
eventually
adopt
once
tooling
is
catches
up.
Basically,
so
the
problem
with
the
new
version
is
that
there's
almost
no
tooling,
that's
why
we
didn't
update
yet.
But
yeah
like
what
you
see
on
open,
open
api
is
exactly
what
you
see
on
async
api.
It's
the
same
type
of
it's
just
a
schema
behind
the
scenes.
B
Yeah
like
thing
is
that,
for
instance,
with
json
schema
we're
treating
we're.
So
we
have
message
payload
field,
for
instance,
which
is
let's
say
with
the
default
format,
which
is
json
schema.
B
We're
saying
that
this
is
your
place
to
define
your
payload
but
you're,
not
defining
your
payload
you're,
defining
a
set
of
constraints
that
will
apply
to
your
to
your
payload,
which
is
different
right
and
if
you
suddenly
use
avra,
for
instance,
then
you're
not
using
validation,
you're,
not
defining
validation,
constraints,
you're,
defining
the
shape
of
your
message,
so
avro,
for
instance,
is
for
the
shape
of
the
message
is:
is
a
typing
system,
after
all
like,
if
you
think
about
it,
just
this
json
format.
B
If
you
use,
if
you
use
a
json
type
dev,
for
instance,
it's
it's
a
json,
it's
a
it's
a
definition
of
your
format.
It's
not
a
validation.
Of
course
you
can
apply
basic
validations
like
this
is
a
string.
Is
this
a
number
yeah,
but
nothing
else
beyond
that
right,
so
so
the
thing
is
that
it's
a
little
bit
inconsistent
from
this
in
kpi
point
of
view
that
we're
offering
a
place
where
you
can
use
whatever
standard
you
prefer,
but
some
of
these
standards
are
for
different
things.
B
One
some
of
them
are
for
defining
shapes,
and
some
of
them
are
for
defining
validation,
constraints
and,
and
we're
not
doing
anything
about
that
right,
so
so
being
being
strict.
If
we
were
to
be
to
be
strict
here,
we
shouldn't
probably
be
allowing
json
schema
to
define
data
shape
right
because
that's
not
what
it's
for
people
are
using.
Json
schema
for
data
definition,
but
that's
not
what
it's
meant
for
what
what
is
it?
What
it's
yeah
suggestion
scheme
is
not
meant
for
that.
C
I
think
one
of
the
one
of
the
issues
we
have
is
that
we've
got
customers,
who've
already
got
all
their
schema
definitions
and
we
can't
go
and
tell
them
that
they
have
to
change
stuff.
You
know
to
accommodate
async
api
right,
so
I
think
you
know
my
first
thought
is
our
code
generators
kind
of
have
to
do
the
best
they
can
with
whatever
we
throw
at
them,
and
we
could.
We
could
make
recommendations,
we
could
say.
C
Well,
you
know
if
you
use
sort
of
this
restricted
set
of
json
schema
you'll
have
a
better
experience
with
the
code
generation,
but
I
think
that
that
we
still
have
to
be
able
to
at
least
from
my
point
of
view
from
my
code
generation.
I
have
to
be
prepared
to
deal
with
whatever
gets
thrown
at
me.
You
know
when
so
you're
right
like
have
the
any
of
or
all
of
whatever
is
a
challenge.
C
You
know
in
java
you
end
up
just
saying:
okay,
let's
just
call
it
an
object
and
we
don't
really
know
any
better,
which
isn't
an
ideal
situation,
but
you
know
it
kind
of
yeah.
I
mean
it's,
it's
definitely
a
challenge
and
I
I
like
the
idea
of
having
sort
of
a
restricted
set
that
describes
the
data
shape
that
maybe
doesn't
have
the
olive
and
any
off,
but
but
then
we
can't,
we
can't
insist
on
that.
Like
I
don't
at
least
at
least
with
us
and
our
customers.
C
B
B
I
mean,
I
think
all
of
you
know
me,
I'm
always
looking
for
improving
the
user
experience,
the
end
user
experience
right
and
or
the
developer
experience
in
this
case,
and
that
will
then
improve
the
developer
experience
that
will
make
it
really
like
worse
and
also
in
some
cases,
especially
big
companies.
It
will
be
like
impossible,
like
a
manageable
like
to
transform
all
this
information
or
to
maintain
the
same
information
in
different
formats.
B
So
that's
now
that's
silly,
but
yeah.
What
I
was
suggesting
wasn't
so
much
about
not
allowing
people
to
use
json
schema,
so
yeah.
A
B
Allow
people
to
use
using
schema
the
same
way
we're
allowing
people
to
use
avro
now
and
other
formats
ramble
data
types
as
well,
but
it's
more
about
what's
the
default
right.
So
what's
the
default
format,
what's
the
suggested?
What's
the
recommendation
for
recommended
format
like
so
the
default?
B
Is
you
do
it
like
this,
and
everything
should
be
work
perfectly
right,
but
if
you
can't,
you
can
just
use
json
schema
for
for
everything
right
for
validation,
for
data
shape
and
so
on,
but
yeah,
but
beware
that
when
generating
code,
it
might
not
work
as
expected,
so
so
yeah,
which
sounds
cool
in
theory,
but
in
practice
it
might
mean
that
we
over
the
years
we
tend
to
forget
about
what
is
not
recommended
and
we
can.
B
A
And
how
like
what
the
take
is
kind
of
similar
discussion.
B
B
E
Okay,
yeah,
it
feels
weird
because
probably
you're
red,
whenever
you
know
after
a
few
minutes
but
forget
about
the
first
one,
I'm
just
whatever
I
said
about
the
keywords,
so
I'm
just
confirming
what
jonas
said.
Well,
he
posted
this.
This
link,
basically,
which.
E
Read
this
open
api
issue
about
keyword,
restricting
keywords,
and
what
I
was
saying
is
that
maybe
the
motivation
for
moving
forward
or
out
of
json
schema
for
model
declaration
or
type
declaration
is
more
on
the
developer
side,
rather
than
the
user
right,
because
most
of
those
that
most
of
the
paints,
for
example,
upgrading
from
one
person
to
the
other
sorry
because
I've
been
working.
It's
it's
an
example.
Is
this
right,
a
keyword
that
we
don't
use
tons
of
keywords
that
we
don't
use?
C
B
No
problem
yeah,
actually
the
new,
so
the
newest
version
of
jesus
schema,
which
is
what
open
api,
is
supporting,
also
adds
yeah
like
a
ton
of
new
keywords
that
yeah
like
most
probably,
you
will
ever
need,
but
we
will
still
we'll
have
to
support
it
right.
If
we,
if
we
declare
that
we
support
this
version,
then
our
tools
will
have
to
support
them
so
yeah.
So
that's
also
something
to
consider,
of
course,
yeah.
B
B
Everything
is
like
with
annotations
for
those
missing
features
that
are
in
avro
or
in
grammar
data
types
that
have
nothing
just
on
schema,
but
but
we
have
like
a
custom
format,
internal
format
for
tools,
but
it's
based
on
json
schema,
basically,
so
so
yeah.
I
wonder
if
this
will
be
over
the
years.
This
will
be
the
the
format,
but
I
don't
know.
B
Oh
yeah
validation
is
one
of
the
main
cases
also
like
validating
the
data
payload
the
message
payload
as
validating
the
the
message
body
when
when
they
arrive
like,
for
instance,
you
subscribe
to
the
topic
and
you
receive
some
message
and
you
want
to
compare
what
you
receive
with
the
definition
of
an
async
api
and
see
if
it
matches
and
if
it
doesn't
you
fail
somehow
that
all
depends
on
people
or
you
let
it
pass.
B
B
They
cannot
behave
like
a
broker
from
the
consumer
point
of
view,
but
when
you
publish
a
message
to
to
this
apa
gateways
using
the
kafka
protocol,
they
support
having
these
kpi
definitions
attached
to
specific
topics
and
publishers
and
subscribers,
so
they
can
so
that
the
ap
gateway
itself
is
the
one
validating
this.
So
you
don't
have
to
do
this
on
your
code.
B
B
I
was
hearing
some
noise
and
I
I
wasn't
sure
where
where
was
it
coming
from
so
yeah?
So
the
thing
is
that
there's
there's
another
case
for
validation,
which
is
there
like
happening
on
api
gateways
or
brokers.
B
So
that's
the
main
case
for
validation,
yeah
also,
for
instance,
glee.
The
framework
that
we
created
at
async
api,
one
of
the
main
points
or
selling
points
is,
is
that
you
can
forget
about
these
things,
because
the
framework
will
use
basically
definition
to
validate
this
information.
For
you
right.
D
Basically,
so
do
you
think
there'd
be
any
complications
in
taking?
I
don't
know
some
gnarly
json
schema
and
converting
it
to
a
a
schema
registry
like
in
classical
schema,
be
it
available
or
json
or
protocol.
B
Well,
there
will
be
cases
where
there's
not
even
a
a
a
schema
registry
or
there
couldn't
be
any
schema
register
involved
like
as
far
as
I
know,
I
think
not
all
schematic
registries
or
not
our
all
products
support
the
uses
of
schema
registries
right
so,
for
instance,
says
say
you
are,
I
don't
know
using
mqtt
with
mosquito
or
something
like
that.
D
I've
seen
some
interests
for
people
like
so
I'm
coming
from
a
perspective.
Yeah
I've
seen
interest
in
provision,
so
that
would
be
taking
a
spec
and
then
auto,
generating
schemers
in
the
catholic
scheme
of
the
registry.
People
are
interested
in
doing
stuff
like
that.
B
That'll
know
know
must
that
more
than
that,
I
will
say,
like
I
think,
there's
there's
interest
in
people
integrating
async
api
with
with
schema
registries,
so
so
not
generating
what
you
define
on
this
in
kpi,
not
not
cloning.
What
you
have
in
one
place
into
another
but
more
like
telling
us
in
cape
directly
to
directly
access
the
schema
registry.
B
Grab
the
format,
the
json
schema
definition
or
the
avro
definition,
or
that
we
have
seen
it
we
have
seen
it
done
like
there
are.
There
are
people
doing
these
things
so
in
just
in
the
sync
api.
You
can
just
use
the
dollar
ref
and
point
to
a
a
schema
registry
url,
so
so
that
you
don't
define
this.
The
the
data
yourself
in
the
same
kpi
file.
You
define
it
on
on
the
schema
registry
right,
so
so
so
yeah,
but
still
like
from
a
code
generation
point
of
view.
A
It's
a
bit
it's
a
bit
unrelated,
so
it
just
finished
discussing
okay,
okay,
you're
the
host
here,
sir.
Now
I
don't
interrupt.
That
would
be
what's
called
unkind.
A
No,
but
it
it
it's
following
sergio's
thought
about
like:
where
is
the
problem
exactly
it's?
Actually
not
when
you
design
your
apis
that
you
want
to
split
these
definitions
like
defining
the
like
the
the
structure
of
the
message,
payload
and
then
validation.
It's
not
really
from
a
design
point
of
view.
That's
the
problem.
B
B
So
when
it
a
mistake,
is
common
enough,
it
stops
being
a
mistake
and
then
the
problem
is
on
the
other
side
for
not
adapting.
So
obviously
like
this,
that's
the
problem
right.
B
That's
why
I
said
like:
maybe
what,
if
we
so
encourage,
something
is
more
from
the
like
from
the
perspective
of
what's
the
default
way
of
doing
things,
it's
not
that
we
can.
We
don't
support
it.
We
should
still
support
it,
but
we
should
be
recommending
people
to
do
things
in
a
different
way
or
to
use.
B
B
B
Soft
complaints
like
this
is
weird
just
mention
this
is
weird,
but
I
fear
that
if
we
make
it
grow
and
we
go
in
this
direction,
this
problem
is
going
to
bite
us
hard
in
the
future
like
publishing,
subscribe,
did
and,
and
that's
why
so
so
I'm
trying
to
put
it
in
a
balance
now
like?
Is
it
like
really
early
decision
heavily
or
like?
B
Are
we
like
taking
care
of
something
that
is
not
the
problem
yet
and
might
not
even
become
a
problem
in
the
future
or.
B
A
That
is
confusing,
I
mean
that's,
why
we're
having
the
discussion
right
yeah,
but
it's
also
to
follow
what
michael
said
that,
regardless
of
whether
we
fix
it
for
version
three
or
four
yeah,
we're
gonna
have
this
problem
with
all
the
specifications
for
a
while
and
in
order
to
solve
that.
We
have
to
solve
it
at
this
tooling
level,
because
if
we
fix
it
at
a
tooling
level
and
where
we
interpret
whatever
specification,
you
use
for
defining
the
message
payload.
As
long
as
your
tooling
have
access
to
the.
A
B
A
But
that
could
coincide
with
changing
the
spec,
so
maybe,
instead
of
changing
the
spec
for
now,
maybe
it's
better
to
focus
on
the
tooling
and
how
we
can
accommodate
this
problem
right
or
solve
it
in
in
that
level.
So
that's.
B
That's
what
you're
saying
is
probably
like
my
suggestion
that
we
make
it
clear
then,
when
generating
code,
we
interpret
jason
schema.
This
way
like
we
ignored
this,
or
you
should
be
ignoring
this
or
maybe
we
can
even
put
it
on
the
spec
like
if
you're
building,
if
you're
yeah
like
if,
when
building
tools
for
or
when
processing
the
message
payload,
you
should
process
it
as
a
when
processing.
B
Now,
when,
when
generating
code
out
of
the
message
payload,
you
should
process
it
as
whatever
vocabulary
we
come
up
with
still
in
the
spec,
just
a
paragraph
saying
that
hey,
if
you're,
building
a
tool,
remember
that
you
shouldn't
support
every
every
keyword
in
json
schema
for
generating
code,
because
that's
going
to
be
impossible.
B
Not
because
there
are
a
lot,
it's
just
because
they're
impossible,
it's
impossible
to
generate
types
out
of
one
of
or
any
off
for
instance,
so
so
yeah
like
we
make
it
clear
like
if
you
want
to
generate
code
or
you're,
building
a
tool
to
generate
code.
You
should
follow
this.
This
guide
here
somewhere.
F
Yeah,
that's
fine.
I
mean
if
you
ignore
some
properties,
that's
easy
yeah,
but
I
can
only
do.
A
F
C
A
A
A
A
And
to
summarize
for
specification
changes,
major
version
changes,
we're
gonna
have,
or
at
least
that's
the
suggestion
at
the
moment.
We're
gonna
have
branches
called
next
major
spec,
and
these
will
be
branches
that
will
be
what's.
It
called
like
released
alongside
everything
else,
as
a
pre-release
branch,
meaning
that
you
can
take
it
into
testing
and
you
can
use
it
in
all
other
libraries
that
you
want.
A
A
G
Yeah,
why
not
I
mean
like
technically
I
don't.
The
change
makes
sense
right.
So
the
only
thing
we
can
question
is
just
the
names
of
the
branches,
so
yeah,
I
think
next
week.
Is
it's
fine,
but
like
just
curious,
why
you
asked
me,
like
I'm
just
cause.
A
A
The
new
bundle,
json
schema
documents
and
what
it
boiled
down
to
was
that
when
we
bundle
when
we
bundle
all
of
the
schemas
together,
we
bundle
the
json
schema
specification
document,
meaning
this
exact
schema.
A
A
So
that
was
the
one
problem.
The
next
one
is
when
you,
when
you
have
this
meta
schema
like
you
define
that
this
schema
should
follow
draft
7,
this
exact
schema
here,
then
you
cannot
have
this
meter
schema,
bundled
here,
because
then
you
have
a
bit
of
a
problem
of
mismatching
ids
in
validation
tools.
A
A
A
A
G
Okay,
what
was
it
like?
So
do
we
already
have
something
for
three
zero
that
is
so
advanced
that
somebody
next
week
will
create
an
open
like
open
pr
for
spec
json,
jason,
schemarico.
A
I
have
a
feeling
that
sergio
is
just.
I
know
he
has
the
next
minor
version
of
the
spec
as
a
as
he
wants
to
release
right,
but
I
think
many
of
the
changes
that
france
suggested
from
the
spec
confusion
is
kind
of
just
in
waiting,
because
there
is
no
branch
to
target
the
changes,
there's
no
way
forward
yeah,
and
so
I
would
say
yes
but
yeah.
A
G
A
G
A
It's
not
paying
yeah
okay,
so
I
guess
I
will
try
to
see
if
I
can
get
through
with
the
implementation
today,
but
otherwise,
let's
see
if
I
run
into
problems,
maybe
there
isn't
one
and
we
can
easily
merge
it
this
week,
but
yeah,
let's
try
and
see.
If
we
can't
base
the
spec
3.0
of
the
new
split
definitions,
yeah.
That
would
be
preferred.
I
think.
A
A
A
A
G
G
B
I
actually
think
it's
the
opposite,
like
we
should
be
releasing
the
next
major
version
of
the
parser
much
before
the
spec
okay,
so
so
that
we
can
actually
test
it
right
before
we.
We
release
version
three
of
the
spec.
A
A
A
B
Yeah,
so
we're
going
on
thinking
out
loud
now
in
two
minutes.