►
From YouTube: Spec 3.0 meeting (December 7, 2022)
Description
A
B
You
know
where
we
have.
We
have
listed
up
everything,
work
on
three
point:
zero
release,
and
just
so
I
don't
make
any
mistakes,
but
yeah
I
would
actually
like
to
propose
that
we
we
remove
stuff
from
3.0
I
mean
not
from
3.0,
but
that
we
don't
release
these
things
on
3.0
a.
B
B
All
right,
let
me
share
so
here's
the
issue
where
I'm
looking
at
and
I
think
there
is
no
issue
specifically.
This
would
be
one
but
I
think
it
was
close.
I
tried
once
and
then
I
closed
it.
So,
like
I,
don't
know
three
years
ago.
Probably
so
I
don't
remember
anyway,
so
this
is
ISU
and
if
you
scroll
down
to
the
second
one
in
the
list
of
under
progress.
B
B
Specifically
discussions
about
dollar,
ref
million
dollar
ref
augmentation
right,
the
meaning
of
augmenting
the
meaning
of
the
ref.
So
right
now
what
happens
is
that
dollar
ref
is
is
for
Json
structures.
B
So
so
we
cannot
use
dollar
ref
as
as
is
but
but
yeah.
One
way
is
that
we
augmented,
we
have
meant
its
meaning,
let's
say
and-
and
we
end
up
with
a
new
mechanism
to
reference
any
kind
of
any
kind
of
structure
data
structure,
not
just
Json
but
yeah-
that
that's
a
huge
one
right,
because
I
don't
know
if,
if
it's
a
discussion
that
is
linked
there
yeah
it's
the
one,
there
there's
one
discussion
linked
there
that
says
reference
tool
in
this
casual
requirements.
B
B
One
day
right,
maybe
person
four
but
yeah
like
I,
see
it
like
it's
just
it's
just
kind
of
gonna
make
it
it's
just
gonna,
be
complex
too,
to
get
it
done
by
by
April
or
May
or
origins,
or
because
it's
it's
too
much,
and
if
we
just
accept
that
we
we're
gonna
include
it,
then
We're
not
gonna
be
releasing
version.
Three,
probably
not
probably
we're
not
gonna,
be
releasing
version
three
in
the
in
the
first
half
of
next
year
for
sure.
B
If
we
include
this
one,
because
that's
gonna
that
that
along
it's
gonna
require
a
lot
of
testing
and
trying
and
see
and
Tool
in
development
as
well
as
well
and
yeah,
it's
going
to
take
time
so
yeah
thoughts
about
it.
Specifically,
you
journals.
D
C
C
Excuse
me
I'm
not
going
to
go
into
details
like
what
other
options
are
there,
but,
first
of
all,
I,
don't
think
it
will
trigger
for
zero
like
we
can
just
have
a
parallel
I
mean
additional
solution.
Next
to
the
ref
object,
we
can
always
say
that
you
can
have
rev
object
or
some
other
object
that
you
can
use
to
reference
other
schemas
and.
C
I
mean
if
we
really
like
for
the
for
the
for
making
dollar
ref
to
support
for
the
buff
and
others
like
we
can
forget
about
having
3-0
pretty
soon
so.
I
would
definitely
suggest
that
we
explore
other
options
if
we
want
to
have
it
for
3-0.
C
But
for
me,
I
am
a
I'm,
a
fan
to
having
3-0
3-0.
That
only
is
focused
on
breaking
changes.
C
So
we
are
not
adding
new
features
if,
if
they
can
be
added
later
without
breaking
the
3-0
and
we're
only
focusing
on
this
core
stuff
that
actually
triggered
the
whole
discussion
about
3-0,
because
3-0
was
triggered
by
public
subscribe.
Basically
and
the
the
limitation
of
current
structure
of
the
document
request
and
reply
was
kinda
added,
but
it's
super
Advanced,
so
it
can
go
into
3-0,
but
with
with
referencing.
C
That's
not
something
that
we
that
we
have
to
have
430,
especially
that,
like
still
not
really
many
people
come
with
protobuf
again
it's
just
few
people
coming
and
asking
about
it.
Not
that
not
a
lot
so
my
opinion
is.
We
can
definitely
limit
the
scope,
but
is
this?
But
the
question
is:
is
it
the
only
candidate
for
limiting
the
scope
or
foreign.
B
I
would
like
to
to
scope
three
zero
to
Breaking
changes,
mainly,
but
also
add
in
some
traditional
features,
like
request
response
right,
so
that
people
feel
encouraged
to
to
migrate
right,
but
at
the
same
time
it's
like.
We
really
listen
very,
very
frequently
right,
more
or
less
like
every
three
months,
two
three
months
right.
B
So
so,
if
something
is
not
in
the
spec
on
three
zero,
it
would
be
everyone
right
on
three
two,
a
few
months
after
so
so
that
is
not
a
problem
right
and,
and
it
will
let
us
start
already.
You
know
like
getting
three
zero
out
right,
so
so
yeah,
so
just
I
would
like
just
to
add
that
and
the
other
one,
the
other
candidate.
B
B
Schemas
not
only
have
Json
schema
or
schema
objects
right,
but
but
to
have
something
else
to
have
I,
don't
know
averse
there
or
to
have
eventually
protobufts
there
as
well
or
whatever
other
kind
of
schemas
right
yeah,
so
that
one
as
well
seems
like
a
very
innocent
one,
but
on
the
surface,
but
when
it
comes
to
specially
when
it
comes
to
tooling
and
how
not
totally,
but
specifically
when
it
comes
to
how
things
reference
to
each
other
in
composition,
like
are
you
allowed
to
have,
for
instance,
inside
an
Avro
object
to
have
a
reference
to
a
Jesus
schema
object,
how's
it
going
to
work
right.
B
If
that's
the
case,
complexity
is
like
close
to
the
Moon
right.
Basically,
so
so
yeah
so
I
mean
that's,
not
a
problem
that
can
actually
be
discussed,
but
yeah
see
in
this
state
of
of
it.
I'm,
just
like
thinking
that
maybe
this
can
be
added
later
so
so
yeah
and
what
else.
C
But
this
one
it's
as
far
as
I,
remember
I
mean
we
didn't
discuss
it
for
long,
but
as
far
as
I
remember,
it's
actually
related
to
Breaking
changes
right.
D
Yeah
we
want
to
remove
the
schema
format
from
message,
object
and
move
to
the
exactly
the
schema,
entertainment
yeah.
It's
one
of
the
brown
kitchens
yeah.
B
So
that's
why
I
was
saying
like
I.
Don't
I,
don't
know
how
we
could
add
this
later,
but
without
the
breaking
change,
but.
B
B
If
that's
the
case
like
I,
don't
think
it's
going
to
take
less
than
a
year
to
be
honest,
to
develop
this
and
to
finish
all
of
this
right,
only
these
two
so
seeing
seeing
how
much
it
took
us
to
to
complete
the
rest
of
the
list,
which
is
way
simpler
to
implement
I
think
these
two
are
probably
just
one
more
year.
B
Assuming
we
don't
go
the
dollar
halfway,
assuming
we
Implement
our
own
I,
don't
know
ref
without
dollar
or
link
or
Inc
include,
or
something
like
that.
Whatever
so
assuming
we
create
our
own
mechanism
and
we
have
complete
freedom
to
do
it.
B
If
we
assume
that
it's
going
to
take,
if
we're
gonna
use
the
ref,
then
it's
probably
more
than
it's
going
to
take
three
years
or
more
so
easily,
because
that
will
involve
this
schema
and
other
communities
as
well.
So
that's
going
to
be
easy,
so
yeah,
but
yeah
like
coming
back
to
this
specific
issue
about
the
schema
formats,
I'm
happy
to
include
it
but
I'm.
Seeing
that.
B
We
might
be,
we
might
be,
including
too
much
for
version
three.
C
But
why.
A
C
D
No
at
the
moment,
I
don't
have
time
for
it.
But
as
I
remember
in
the
previous
discussion
about
this
issue
this
proposal,
we
conclude
that
probably
we
wanna
only
allow
to
define
the
different
schemas
on
the
component
schemas
level
and
that's
it.
So
you
shouldn't
have
the
possibility
to
define
the
nested
custom.
Schemas
yeah
combine
the
server
with
Json
skin
or
something
like
that,
and
then
you
can
only
make
the
reference
to
the
message
payload
from
the
component,
schemas
of
course.
A
A
B
That
exactly
so
one
option
is
just
saying
explicitly
saying
that
that's
not
allowed
and
that
should
not
be
supported
by
parsers
and
so
on.
So
that
should
be
that
will
trigger
an
error.
Basically,
so
so
yeah.
That's.
Why
I'm
saying
like
I'm
fine
with
that
one,
if
we
reduce
the
scope
and
especially
about
cross-referencing
right
and
we
make
it
clear
because
otherwise,
cross-reference
and
stuff
is.
B
Sounds
powerful
but
useless
to
me
like
it's
powerful,
but
at
the
same
time
it's
like.
Why
will
I
want
to
combine
different
kind
of
schema
languages,
but
because
I'm,
not
a
headache
and
a
lot
of
headache
on
the
tall
inside,
specifically
specially
that
Avro
is
not
and
Jason
schema
are
not
the
same
kind
of
thing
so
average
to
define
the
structure
of
the
of
an
object.
Is
a
data
model?
Language
and
Json
schema?
B
Is
a
data
constrained
language
right
say
it's
not
it's
not
about
data
modeling,
even
though
we
use
it
as
such,
but
so
they
will
not
combine
well
so
yeah
I
have
another
I
mean,
on
the
other
hand,
I
I
I
have
another
proposal
that
I
never
proposed
yet
to.
B
No,
no,
no,
no
I
have
another
proposal,
but
it's
it's
completely
unrelated.
But
since
we're
talking
about
breaking
changes,
this
one
will
create
a
breaking
change
and
it's
dropping
support
for
well,
let's
say
drop
in
the
default
support
or
the
default
schema
object
will
not
be
Json
schema
right.
The
the
default
schema
definition
language
will
be
something
else,
I
don't
know
avra
or
something
else,
or
this
jtd
or
whatever
other
a
schema
definition.
Language.
Actually,
a
schema
modeling
language,
not
a
not
Json
schema.
B
That
is
actually
meant
to
for
something
else
or
or
a
vocabulary
of
Nissan
schema,
which
could
also
work,
reduce
for
schema
definition,
language
and
then
separating,
for
instance,
payload
will
be
separated
by
the
definition
and
the
validation
right.
So
this
is
the
definition
of
the
of
the
payload
chunk
right.
So
it
will
have
these
fields
here
and
additionally,
you
can
have
another
field
optionally
and
it's
called
validation
and
there
you
can
throw
your
Json
schema
right,
which
is
which
will
be
used
to
validate
your
payload
if
you
want
to.
B
But
so
it's
not
completely
dropping
support
for
Json
schema.
It's
not
it's
not
so
much
about
dropping
completely
the
support
of
this
schema,
even
in
definition,
you
will
be
able
to
specify
explicitly
in
the
schema
format
that
you
want
to
use
using
schema
for
the
definition.
Then
it's
up
to
you.
You
will
find
unexpected
consequences
like
we'll
find
in
now
and
and
yeah,
but
I
on
purpose
didn't
propose
anything
but
yeah.
So
I'm
saying
because
I
have
more
ideas.
B
So
we
can
follow
and
then
once
3-0
is
out,
I
will
make
a
few
proposals
that
will
break
again
the
spec
right
so
probably
not
probably
going
440,
not
not
urgent
at
all
for
sure,
not
origin,
not
like
the
one
that
we
had
at
hand
with
public
subscribe.
That
was
a
little
bit
more
urgent.
I
would
say
these
ones
are
just
like
we
can
be
with
three
we've
made
very
sorry,
major
version
three
or
years
I.
Don't
care
if
just
give
us
there
for
years,
for
definition
or
not.
A
B
A
From
my
point
of
view,
it's
it's
it's
still
getting
started
and
the
discussion
is
probably
going
to
happen
way
after
3.0
is
released.
I
have
a
feeling.
It's
gonna.
Be
that
because
it's
as
you
said
it's
not
it's
not
that
easy,
especially
if
you
want
tooling,
alongside
it
as
well
so
I
but
I
get
that.
Maybe
we
should
just
remove.
A
B
And
and
to
be
honest
like
when
it
comes
to
sorry
Lucas,
you
wanted
to
say
something:
yeah
I.
C
Mean
basically
questioning
word
scope,
I
wanted
to
question.
What's
called
because,
like
we
like,
it's
released
like
any
other
Janus
is
released
coordinator
and
we
never
had
scopes
for
releases.
It's
just
about
like.
What's
it's
like
what
we're
doing
now
and
what
template
is
followed
by
Jonas,
it's
just
basically
the
usual
release,
so
there
are
candidates,
it's
not
that
we
scoped
like
that.
I,
don't
know
like
maintainer
scoped
the
release
to
some
number
of
issues
like
it's
there
on
the
list.
C
It's
a
possible
candidate
because
it
has
a
champion
and
Champion
is
aware
of
the
facts
that
we
are
gonna
release
3-0
in
few
months,
so
the
champion
can
work
on
it
like
if
he
has
time
to
do
it.
I
mean
continue
like,
but
it
should
not
block
release
it
right.
So
wouldn't
it
be
just
better
like
because
we
I
mean
at
least
my
feeling
is
that
we
really
want
to
release
next
year
right.
C
I
think
we
can
agree
on
this,
like
3-0
is
next
year
yeah
and
from
our
experience.
September
is
not
a
good
time
for
release
if
it
comes
to
our
Windows,
because
September
is
right
after
holidays.
Nobody
gives
a
about
working
on
holidays,
so
we
can
wreck
it
already
forget
about
September
that
we
will
have
some
extra
time.
So
why
not
just
saying
I
mean
and
I'm
suggesting
it
to
release
coordinator?
C
Why
not
just
saying
like
let's
say
we
have
four
Windows
right.
We
have
April
June
September,
this
actually
January
January
April.
Why
not
saying
like
Okay?
C
So
we
have
we
want
to
release
next
year
and
we
say
that
that,
like
April
is
deadline
for
candidates
to
reach
I,
don't
know
which
RFC,
let's
say
three
two
something
to
discuss
and
then,
if
you
reached
a
stage
in
April
that
allows
you
to
merge,
then
we
then
you're
getting
in
you
have
extra
time
to
get
the
implementation
in
parser,
Json
schema
and
we're
planning
release
on
on
June.
So
we
have
a
lot
of
time
to
think
work
on
tooling,
but
we
basically
set
some.
C
Maybe
we
should
just
set
some
deadline
like
not
hard
deadline
but
like
they
could
so
so-called
gentleman
agreement
like
like
folks,
like
that's
a
yeah.
B
C
B
Actually,
a
hard
deadline,
but
of
a
month
right.
So
it's
not
that
hard.
I'd
say
it's
like.
We
can
agree
like
a
month.
I
don't
know
on
March,
usually
have
part
of
out
of
three
out
of
C3
ready
and
then
yeah,
because
we
want
to
release
in
June.
B
So
so
we
need
at
least
three
more
months
to
not
just
to
implement
tooling,
but
to
give
people
the
opportunity
to
to
test
it
and
and
test
it
with
companies
to
see
if
it
works
as
intended,
or
if
it's
creating
more
problems
that
we
didn't
foresee
so
so
yeah
I
agree
with
that.
I
will
actually
go
a
little
bit
farther
and
restrict
changes
to
the
spec.
I
mean
that
changes
to
the
spec
changes
that
go
into
sngpi3
February.
B
So
whatever
is
not
in
February
January
I
mean
now,
whatever
is
not.
So
if
you
don't,
if
your
proposal
doesn't
reach
out
of
out
of
C3
in
February
right
in
the
mount
in
the
month
of
February,
it
will
not
make
it
to
version
3.0,
because
the
month
doesn't
have
to
be
related
to
the
release
months.
You
know
the
deadline
can
be
something
else
right.
B
A
Yeah,
this
actually
also
goes
into
the
discussion
about
whether
we
should
have
a
freeze
period
for
for
the
release
process.
A
So
it's
actually
just
straight
hand
in
hand
with
what
you're,
saying
and
I
think
it's
I
think
it's
a
good
idea
that
we
try
one
see
what
happens.
Let's
say
that
it's
two
months
before
release,
so
that
will
mean
that
end
of
February
there's
no
new
change.
That
can
happen
for
the
spec
and
then
the
rest
is
implementation,
wise
and
tooling,
and
let's
just
see
how
it
goes.
B
I
mean
just
to
just
to
be
clear:
you
can
keep
working
on
the
spec,
but
it's
not
oh
yeah
for
sure
the
thing
is
not
going
to
make
it
into
the
3.0
version,
so
you
can
keep
adding
stuff
to
this
pack,
but
it's
gonna
end
up
on
3.1
right,
not
on
3.0.
So
yes,
so
they're
not
going
to
be
merged
until
we
release
version
3.0
right
exactly
so
so.
B
Just
so
we
have
some
time
to
test
it,
so
between
February
and,
let's
say,
may
right,
because
I'm
not
counting
June,
because
June
is
the
at
some
point
in
June.
It
will
be
released.
So
we
know
that
it's
probably
gonna
be
on
30
of
June
right,
not
on
the
1st
of
June,
but
but
that
could
be
potentially
first
of
June
right,
so
some
counting
until
May,
so
that
we
have
three
months
right,
three
months
period
and
or
three
months
and
a
half
or
more
or
less.
B
And
then
we
try
to
involve
as
many
companies
and
people
as
we
can
to
migrate
to
version
three
or
two
early
adopt
person.
Three
candidate,
of
course
right
the
release
candidate
that
we
have
at
that
time,
and
so
we
have
three
months
of
fixing
stuff
right
as
well
opportunities
to
fix
stuff
right
to
to
make
some
patches
here
and
there
clarifications
things
like
this.
A
What,
if
I,
make
a
new
issue
for
just
this
discussion
about
hot
deadlines
for
release
of
3.0?
And
we
can
keep
the
discussion
there
and
take
a
decision
within.
B
C
C
C
A
A
B
A
C
B
We
can
make
it
clear:
it's
not
so
much
that
until
February
someone
will
come
and
add
something
it's
more
than
until
June
someone
will
come
in
at
something
right,
that's
the
thing,
so
we
we
just
need
to
make
it
clear
so
that
between
February
and
June,
nobody
adds
anything
right
or
I
mean
they
can
add,
but
they
should
expect
that
it's
not
going
to
end
up
in
3-0.
That's
only
that
right.
B
Yeah
for
sure,
from
it's
from
here
to
February
at
at
most
you'll,
get
some
of
some
pull
requests
from
me
and
that's
it
that's
it.
B
B
So
yes,
because
other
than
to
be
honest,
like
other
than
the
breaking
change
stuff,
what
I
find
exciting,
let's
say
for
people
that
could
be
exciting
for
people
and
other
yeah
well
other
than
the
breaking
chain
stuff
yeah
that
can
be
exciting,
for
people
will
be
request
response.
B
This
is
a
major
thing.
I
will
say
this
is
a
huge
one.
I
will
say-
and
it's
been
requested,
I
think
since
the
first
year
of
the
spec.
B
B
So
yeah
so
I
think
getting
the
breaking
changes
alongside
a
a
really
cool
feature
that
many
people
will
want
to
have
it's
more
than
enough
to
release
a
major
one
right,
I,
don't
like
releasing
major
versions
that
only
change
stuff
around
move
stuff
around
and
doesn't
provide
you
anything
new,
because
that
sounds
like
the
user
will
be
like
I.
Don't
care
you're,
not
providing
any
value
to
me,
but
and
I'm
already
used
to
this
public
subscribed
confusion.
So
who
cares
so
so
yeah?
B
So
that's
why
I
want
to
provide
some
good
value
other
than
that
right,
additional
value,
let's
say,
but
we
already
have
it
I
mean
it's
almost
there.
It's
almost
request
response.
It's
almost
done.
B
B
Yeah
and
I
forgot
to
tell
why
I'm
proposing
this,
it's
been
long,
that
we've
we've
been
working
on
version
three
already,
it's
been
probably
I,
don't
know,
I
haven't
counted,
but
more
than
a
year
now
or
a
year,
more
or
less
so
yeah
people
are
starting
to
get
a
little
bit
like
in
in
some
one-on-ones
that
I
had
with
you.
You
already
communicated
this
frustration,
feeling
that
3.0
Is
Never
Done
Right
and
it's
never
releasing
yeah
and
it's
a
little
bit
frustrating
so
yeah.
B
We
need
to
take
care
of
the
users,
but
we
also
need
to
take
care
of
the
contributors
so
so
yeah.
It
will
I
think
it
would
be
a
really
cool
motivation
boost
between
the
contributors
right
that
something
is
actually
released.
Right,
three
point
series
release
and
it's
like
yeah.
We
made
it
finally
right
and
then
we
can
keep
a
bit
more
stuff
later.
B
A
But
yeah
I'm
gonna
create
an
issue
for
the
release.
Schedule
and
I'm
gonna
create
a
separate
issue.
I
think
I
am
not
as
a
comment
just
to
have
it
have
that
discussion
clearly
in
one
place
and
I
am
gonna,
remove
the
referencing
stuff
and
create
a
separate
issue
for
that
as
well
and.
B
Second,
about
before
before
you
proceed,
so
we
don't
make
decisions
on
meetings
right.
So
so
that's
just
a
suggestion
we
saw
this
will
be
proposed
somewhere
right,
I'm
happy
to
leave
this
comment
somewhere
or
if
you
create
a
new
suit.
I
can
live
there
but
at
the
same
time
to
be
pragmatic
with
three
spec
maintainers
here
in
the
call.
So
if
I
mean
we
still
have
to
propose
it
right,
we
cannot
just
go
ahead
and
surprise.
We
have
a
new
decision
that
you've
never
heard
of
right,
but.
A
B
A
A
A
A
I'm
gonna
remove
it
from
the
list
of
progress
because,
okay,
there
are
no
reason
to
have
it
there
as
it
just
creates
clutter,
as
we
already
know,
probably
most
likely.
This
will
not
happen
in
3.0
unless
some
magic
progress,
all
of
a
sudden
happened,
and
we
all
agree
all
of
a
sudden
but
I,
don't
think
that
will
happen.
So
that's
why
and
I'm
gonna
leave
a
comment
as
well.
In
the
end,
okay.
D
B
D
B
Different
kinds
of
schemas
I
think
that's
actually
fine,
like
like
Jenna,
said,
there's
nothing
new,
so
making
it
super
clear
in
the
spec
that
this
is
not
supported.
This
is
not
allowed,
which
will
actually
improve
the
current
spec
because,
as
jealous
said,
it's
already
possible
so
actually
in
the
current
spec
it's
we
should
have
said
that
this
is
not
allowed,
but
I
guess
it's
kinda
like
clear
right
like
because
the
resulting
object
will
not
be
valid.
Aggro
or
validation.
D
A
D
B
Valid
definition,
if
you,
if
you,
if
your
schema
form
it
has
abroad
right,
yeah,
you're,
right
and
you
end
up
with
a
invalid
abroad
file,
what
was
what
magic
was
proposing
is
that
inside
the
schema
you
propose
like
now,
this
dollar
ref
is
pointing
to
an
average
or
to
a
distance
schema,
and
then
you
end
up
with
a
yes
here
that
people
will
expect
to
work,
but
it's
wouldn't
right,
probably
so
so
yeah.
If
we
make
it
clear
that
this
is
not
possible,
that
we
don't.
B
Also
I,
remember
specifically
about
that.
You
were
I,
think
you
were
adding
something
like
schema
format
or
with
another
name:
I,
don't
remember
the
ski
at
the
schema
level,
right,
yeah
or
the
schema
in
Json
schema.
We
can
take.
B
We
can
take
the
leadership
here.
Let's
say
we
don't
have.
We
have
Json
schema
and
we
have
the
three
new
properties.
We
can
add
a
fourth
one
if
we
want,
if
a
format
right,
that's
completely
fine,
but
if
the
schema
that
I'm
using
is
avra,
I
cannot
add
an
additional
one
right,
because
we're
not
augmenting
avra
we're
augmenting
gestures
and
schema.
So
you
could
reference
from
Json
schema
to
an
Avro
file,
but
not
the
other
way
around
right,
so
so
yeah,
but.
D
Can
yeah
okay,
yeah.
B
B
My
personal
opinion,
this
is
like
it's
probably
not
even
needed
that
it's
probably
just
I
mean
schemas,
so
having
the
schema
format
and
the
schema
definition
inside
components,
yeah.
D
B
A
D
Sorry,
so
maybe
we
should
drop
it
and
only
allow
to
Define.
You
know
this
Avro
in
separate
files
and
that's
it
or
in
line
in
the
message
object.
As
now
we
have.
B
D
B
D
Remember,
yeah
I,
remember
one
one:
guy
from
Community
want
to
add
something
like
that:
I
mean
Avro
in
components,
but
the
problem
that
in
the
Json
schema
we
forced
to
use
the
Json
schemas.
D
So
it
means
that
in
the
payload
is
exactly
the
any
type.
So
you
can
even
write
the
string,
but
yeah
in
the
components
need
to
Define
it
as
the
object.
So
I.
Don't
remember
me
or
Rihanna
suggest,
to
create
the
extension
in
components
like
the
X
over
schemas
and
inside
it
Define
the
average
schemas
and
make
the
reference
to
the
payload
I.
B
B
B
Maybe
some
people
at
Milford,
of
course,
so
we
didn't
make
more
sense
if
they
are
just
components:
average
or
Average,
schemas
components,
Jason
schemas.
Whatever
sounds
like
that,
and
then
we
have
schemas
average
schemas
and
Json
schemas,
for
instance,
and
then
Json
schemas
will
contain
inside
the
version
of
digital
schema
or
actually
it
doesn't
need
it
because
listen
schemas
have
this
dollar
schema
stuff
that
yeah,
so
it's
not
even
needed,
however,
will
probably
need
the
version
somewhere
there
and
schemas
will
be
our
our
schema
object
right.
B
Our
and
then
parameters,
headers
and
all
this
stuff
will
be
our
skim
object
and
the
others
will
be
just
whatever
you
prefer
like,
for
instance,
in
the
payload.
The
payload
definition
will
be
whatever
you
want,
probably
an
average
schema
or
adjacent
schema,
and
that's
it,
and-
and
we
still
make
clear
that
we,
you
cannot
nest
things.
Of
course,.
B
C
A
B
Want
that
is
a
yeah
that
is
a
misdefinition,
let's
say
because
it
is
like
this
because
yeah
it's
the
responsibility
of
the
parser
to
understand
if
this
is
supported
or
not
so
so,
that's
completely
fine
I
mean
I,
think
that's
open
to
to
there,
and
then
you
can
reference
to
some
weird
kind
of
schema
language
that
you
might
have
in
your
company.
B
C
Just
when
you
create
the
issue
with
proposal
of
like
explanation
of
3-0
release
that
there's
no
scope
but
there's
proposed
deadline
when
it
could
happen,
Etc
then
send
me
a
link.
I'll
share
it
on
social
medias,
so
yeah
for
better
reach.
B
B
And
I
think,
with
this
we'll
be
happier
we'll
be,
will
feel
more
relief
right
that
we
can
finally
release
it.
We
can
start
adapting
to
the
new
world
right
and
then
slowly
or
constantly
iterating
on
that
new
world,
instead
of
ever
like
forever
waiting
for
the
perfect
four
to
arrive
right.
So,
yes,
yeah.
B
A
B
A
B
B
B
Of
course
they
were,
it
was
just
from
from
Swagger
to
to
open
apk3,
which
is
just
that
rename.
It
was
mostly
mostly
just
a
rename,
not
webhooks,
but
callbacks.
That's
the
only
thing
they
added
something
like
that.
C
C
B
You
could
have
paused
and
security
stuff,
but
I
don't
remember
how
probably.
B
C
C
B
I
say
a
lot,
but
I
mean,
but
it
was
like.
The
majority
of
people
are
not
having
a
problem
with
this
like
it's
just.
It
was
just
like
I'm
defining
my
production,
API
right,
so
I
don't
care
because
most
people
were
using
it
for
for
directing
dogs.
So
you
were
not
using
swagger
to
generate
code,
local
code
or
anything
you
were
using
it
to
generate
docs
production
Ducks.
So
there
was
only
just
one
URL
right,
so
that's
why
it
was
like
pretty
pretty
much
what
you
needed
right.
You
didn't!
B
You
didn't
need
much
so
and
that's
why
many
people
are
not
migrating
still
right
still
nowadays,
because
there
there
were
no
major
changes
as
major
as
in
user
value
right
because
they
had
one
major
change
on
3.1,
which
is
aligning
with
Json
schema
right,
so
schema
object
is
a
pure
Json
scheme.
Object,
that's
a
huge
one,
but
it's
a
huge
one
as
in
the
amount
of
change,
but
again
it's
probably
not
providing
any
value
to
the
user,
because
users
are
fine
with
draft
4
or
whatever
it's
just
more
than
enough
for
them.
C
B
Otherwise,
it's
like
yeah,
you
guys
made
a
good
job
now
that
it's
easier
for
you
to
create
tooling
and
to
do
stuff.
But
it's
still
the
same
for
me.