►
From YouTube: Spec 3.0 meeting (April 13th 2023)
Description
B
A
A
A
D
D
D
A
D
D
A
B
B
B
D
B
F
B
D
The
reality
is
that
if,
unless
libraries
are
checking
for
it
like
it
must
be
only
dollar
ref
and
nothing
else,
then
yeah
it's
backwards
compatible,
but
if
some
library
is
checking
that
it
must
be
only
dollar
ref
and
nothing
else,
then
it's
not
that
work.
It's
backwards,
compatible
and
I'm.
Assuming
that
many.
D
But
I'm,
assuming
that
some
implementations
might
be
checking
for
the
uniqueness
of
dollar
ref
there
are
uniqueness,
is
in
the
sense
that
this
is
the
only
property
allowed
that
object,
because
yeah,
because
they're,
probably
using
decent,
schema
to
verify
that
to
validate
that
dollar
rate
is
the
only
property
of
the
reference
object.
Probably
probably
we
are
and
our
Json
schema
definition,
probably
maybe
we
we
have
additional
properties
follows
or
something
like
that
will
be
a
big
change.
B
E
D
B
B
D
B
D
D
D
F
B
A
A
C
A
B
I
mean
like
for
me
from
back
perspective,
it's
breaking
because
again,
like
the
specs.
Has
that,
like
we
had
totally
different
description
of
the
reference
object
than
the
open
API,
so
for
us
it
was
just
it's
the
same
as
Json
reference
and
Json
reference
says
clearly
that
you
cannot
have
other
fields
than
dollar
refin
reference
object.
It's.
C
B
Like
so
in
in
the
world
where
I
have
some
API
and
I
would
have
an
endpoint
and
I
would
add
a
property
I
would
say
it's
not
a
breaking
change,
but
here
it's
like
it's
a
different,
because
we
were
saying
that
there's
no
other
field,
so
somebody
can
in
his
code
in
the
tools
of
course,
look
I,
don't
see
a
difference
between
spec
breaking
and
tools.
Breaking
somebody
can
assume
that
there
will
be
no
other
fields
than
the
ref
correct.
B
A
B
A
I
think
it's
also
because
my
assumption
of
my
assumption,
of
enabling
references
from
non-json
schemas
will
not
be
a
breaking
change
like
the
solution
for
allowing
that
is
not
going
to
be
a
breaking
change
from
a
spec
perspective.
It's
going
to
break
tooling,
especially
if
they
all
of
the
sudden
encounter
a
reference
that
all
of
the
sudden
reference
a
protobar
file
that
earlier
in
the
spec,
spec,
two
or
three
wouldn't
be
a
allowed.
A
C
E
D
Well,
actually,
that
that
that's
a
that's
a
good
point,
so
even
preparing
this,
the
spec
like
like
Lucas,
did
I
think
it
will
still
be
a
breaking
change
in
the
future
because
we
will
be
changing
the
dollar,
rep
and
dollar.
Ref
will
be
pointing
to
I,
don't
know,
approachable,
schema
right
and
then
that
value
that
dollar
rate
will
not
be
compatible
with
previous
versions
right.
So
that's
back
working
backwards,
compatible.
F
D
D
D
C
C
D
So
what
we
could
do
instead,
maybe
is
that
we
can
have
a
reference
object
that
in
the
future
might
be
like.
Okay,
you
can.
You
can
now
have
dollar
rev
or
product
above
URL,
whatever
or
product
ref,
either
one
or
the
other
right,
and
in
this
case
it
might
be
backwards
comparable
debatable,
but
still.
But
if
you
change
the
behavior
of
dollar
rev
by
a
sibling
property
that
the
previous
version
doesn't
recognize,
then
it's
still
going
to
be
a
breaking
change.
So
it's
not
going
to
be
backwards
compatible!
That's
my
point.
D
F
D
And
you
try
to
with
the
product
buff
reference
okay,
but
you
try
to
parse
it
to
parse
this
document
with
a
3.0
parser,
not
our
parses,
but
another
parser
that
doesn't
take
into
account.
The
version
of
the
person
is
in
API:
that's
not
going
to
be
compatible
because
the
3.0
parser
is
going
to
try
to
reference
to
a
product
of
a
file,
and
it
doesn't
even
know
about
the
existence
of
a
simple
property
that
serves
as
a
flag.
D
E
B
D
D
E
D
E
A
F
A
E
A
A
A
C
B
D
A
C
F
D
Now
so
I'm
I'm
feeling
a
little
bit
of
a
I'm,
perceiving
the
feeling
of
fear
of
real
soon
for
version
four.
Okay,
so
and
I
can
understand
because
yeah
we
are
we're
still
on
version
three
trying
to
release
version
three
and
it's
a
huge
effort.
But
it's
true
that
from
two
to
three
it,
it's
been
a
huge
change,
so
the
spec
doesn't
even
look
the
same
anymore.
D
F
D
D
That's
another
discussion
right
like
instead
of
migrating
every
two
versions
or
instead
of
migrating
every
10
versions,
10
major
versions:
you
can
be
migrating
every
two
and
that's
completely
fine
right.
That
shouldn't
be
a
lot
of
a
lot
of
work
to
migrate,
fabulous
Awards,
probably
but
yeah,
especially
with
with
the
small
changes
like
the
small
change.
Probably
will
not
will
be
a
breaking
sense,
but
what's
the
probability
that
it
will
impact
someone
right.
C
C
D
So
maybe
the
other,
the
other
option
is
this:
it's
like,
let's
not
fear,
breaking
changes
and
major
versions.
Let's
do
it
more
often
if
at
the
end
of
the
year
or
beginning
of
next
year,
we're
releasing
version
4.
and
version
five
at
the
end
of
the
next
year
as
well.
Who
cares
I
mean
if
it's
I
mean
it
might
be
considered
a
breaking
change,
but
in
this
case,
for
instance,
what's
the
probability
that
it
might
impact
someone
like?
D
C
C
D
C
C
F
E
D
A
D
A
D
B
My
the
CI
did
not
have
enough
of
capacity
and
I
hung.
Basically
I
mean
yeah
looks
like
that.
Whatever
we're
doing
now
with
this
pack
servers
example,
making
changes
to
ref
seems
like
seems
like
a
not
breaking
change,
although
I'm
curious,
why
open
API
considered
it
breaking
when
they
were
changing
from
three
zero
to
one
zero,
two
three
one,
but
they
have
different.
D
But
yeah,
but
it's
because
they
it's
because
they
changed
the
whole.
This
will
schema
version.
That's
why
yeah
it
wasn't
because
of
this.
It
was
because
of
the
suggestion
scheme
operation.
They
adopted
the
latest
distance
to
my
version,
or
one
of
the
latest
from
they
were
at
draft
seven
or
draft
four
at
the
time.
I.
Don't
remember:
that's
why
that's
the
real
breaking
change.
F
F
C
C
D
D
You
want
them
to
be
using
dollar
ref,
pointing
to
their
to
their
schema
registry
or
another
reference,
some
or
some
other
mechanism,
but
not
rewriting
it,
and
if
it's
already
on
Avro
format,
then
it
will
be
possible
that
you
put
it
on
the
on
the
headers
as
well
right
actually
just
for
everyone.
This
is
schema,
nothing
else.
So
I'm!
Not
that's
why
I
was
like
I,
don't
think
we
should
support,
maybe
I've
grown,
but
I,
don't
think
we
should
support.
C
D
D
If
there's
someone
else
like
hey
I,
have
a
custom
schema
format
in
my
company
and
I
want
to
use
it
in
headers,
okay
up
in
the
eastern
and
open
the
pull
requests
and
so
on,
and
we
might
support
it
and
it's
not
going
to
be
a
breaking
chance
because
you're
only
adding
one
word
format.
So
it's
okay,
let's
not
assume
that
there
might
be
a
case.
There
might
never
be
a
case
other
than
ever
and
Justin
schema.
So
so,
let's
just
go
for
what
we
know.
That's
my
suggestion.
C
C
F
C
C
C
C
F
F
F
C
C
F
F
A
C
F
E
E
D
C
D
Exactly
no
that
doesn't
make
sense.
We
need
one
more
schema
object,
which
is
like
something
like
simple
schema
object,
which
is
an
object
that
a
schema
that
only
allows
a
few
a
few
properties
like
like
the
one
like
the
one
we
have
in
the
several
variables.
For
instance,
there
is
a
it's
real
simple:
it
doesn't
it's
not
extract
as
an
object,
but
it
will
look
the
same.
It's
just
like
I,
don't
know,
Elon
enum
default
and
description,
and
a
few
more
maybe,
and
and
that's
it
yeah.
E
C
A
Would
be
careful
about
renaming
the
async
API
schema
object,
yeah
to
something
different
or
switching
between
them,
because
then
it's
starting
to
be
real
confusing,
because
we
have
the
async
API
scheme
object,
which
is
what
we
have
now
as
the
default
payload
structure
right
and
then
we
need
another
name
for
whatever
a
schema
is
right.
Yeah.
C
F
C
D
C
C
D
D
C
D
D
D
D
Kpi
we
are
organizing
kpis;
all
of
them
are
from
basic
API.
So
what
do
you
really
mean
by
async
API
there
like
the
new
one,
is
going
to
be
from
basic
API.
The
existing
one
is
from
basic
API.
The
simple
schema
that
we
want
to
create
it's
still
from
async
API.
We
Define
it.
So
you
know
you
know
what
I
mean
when
you
say
sap
HQ.
My
object
is
which
one
of
the
three
you
know
what
I
mean
no.
D
D
There
is
the
async
API
in
the
beginning
right,
but
all
of
the
schema
objects
are
from
async
API.
So
if
I
only
see
HTTP
schema
object
object,
my
first
question
will
be
which
one
of
them,
why
is
it
is
it?
Is
it
called
async
gaming
schema
object
and
the
one
that
is
on
parameters
and
several
variables
is
not
a
a
is
that
a
basic
DPS
object
if
it's
still
from
basic
API,
we
still
missing
kpi.
So
if
that's
what's
confusing
me
with
this
name,.
C
F
D
But
is
it
really
needed
that
we
have
components
as
in
kpi
schemas,
because
I
can
reference
another
another
object
on
the
schemas
on
the
components
under
components?
Schemas
I
can
reference
another
one.
There,
just
I
will
just
have
to
add
slash
schema
at
the
end
to
point
to
the
pure
schema.
Let's
say.
C
D
D
F
D
A
C
G
G
G
So
the
last
spec
meeting
you
actually
said
that,
instead
of
doing
that,
that
we
should
have
another
point
in
this
meeting,
which
is
why
I'm
in
this
meeting
and
I
mean
I,
don't
care,
you
know,
I'll,
learn
something
new,
so
I
don't
mind
joining
the
meeting
today
for
nothing
I,
don't
think
it's
for
nothing,
but
I
want
to
make
sure
that
we're
not
forgetting
that
we
and
we
actually
make
time
to
discuss
documentation.
So
that's
not
going
to
happen
in
this
meeting,
but
I
want
to
make
sure
we
establish
where
that
is
happening.
D
D
B
G
A
G
G
E
G
C
C
C
F
C
E
C
A
C
B
A
C
D
C
D
C
D
Even
even
the
Nissan
KPS
schema
is
too
much
for
a
parameter.
That's
my
point.
So
parameter
is
usually
just
a
string
or
a
number.
Yes
right
and
it's
it's
I,
don't
I
never
saw
any
parameter.
That
is
an
array
or
an
object
or
or
rule
or
or
a
Boolean.
So
it's
too
much.
So
we
should
decrease
the
the
amount
of
things
you
can
do
with
parameters,
because
it's
it's
it's
way
too
much
so
also
or
or
if
we
live
it,
we
need
to
Define.
How
do
you
serialize
arrays
into
a
parameter?
D
D
C
C
C
B
C
B
C
It
just
it
was
just
one
to
mention
if
you
want
to
limit
the
parameters
to
the
subsection,
and
we
choose
this
approach
here.
You
would
end
up
with
saying
hey.
We
have
here
multiple
component
section,
it's
just
what
like
do
you
like
more
having
multiple
components
section
each
contains
only
what
it's
designed
for
having
this
approach,
where
you
always
have
the
schema
format
and
saying
later,
hey
for
parameters
only
schema.
B
I
mean
if,
if
there's
any
preference,
then
I
definitely
like
I
I
supported
the
the
previous
idea,
because
everything
is
coming
from
the
idea
for
mache
that
we
have
the
schema
format
and
schema.
But
yeah
I
mean
I.
Think
that
we
every
every
at
least
I,
agree
that
this
reference
will
now
look
strange
and
for
tooling
providers.
It's
going
to
be
harder
to,
for
example,
use
the
ref
to
figure
out
the
ID.
B
B
D
D
D
D
E
F
D
C
D
Thing
is
that
yeah,
so
that
so,
instead
of
API,
if
you
have
something
like
application,
every
blah
blah
blah,
then
it
becomes
it's
not
that
it
becomes
a
problem.
But
if
you
really
have
to
to
use
a
dollar
ref
to
application,
slash
vmd
blah
blah
blah,
it's
going
to
be
a
it's
going
to
be
hard
to
type,
because
it
has
a
slash
element
and
slash
element
in
dollar.
Ref
is
not
it's
not
represented
by
its
last,
it's
represented
by
a
tilde
m.
One
number
one
I
think
something
like
that.
So
it's
really
complex.
C
D
D
C
D
D
C
C
D
Only
problem
with
this
is
that
it
really
looks
ugly,
that
dollar
ref
looks
ugly
and
large
right,
but
that
solves
the
problem
of
you
know
having
to
put
the
schema
format
all
the
time
in
every
in
every
schema.
Well,
you
have
it
on
every
rep,
which
is
probably
worse
so,
and
the
problem
with
having
to
add
slash,
schema
at
the
end
of
the
dollar.
Rev.
D
C
D
Yeah
but
I
don't
know,
that's
why
I
was
saying
like.
Maybe
what
we
could
do
is
we
can
have
aliases
there
abroad
and
that
will
be
I.
Don't
know
the
latest
Avro
version
whatever
or
a
specific
after
version,
and
then,
if
you
want
to
use
a
previous
one
or
a
future
one
or
something
like
that,
then
you
need
to
put
the
whole
the
hotel
rep
the
whole.
My
title,
development.
E
D
C
D
D
No,
it's
okay.
We
forever.
We
can
just
stick
to
a
specific
version,
whatever
whatever
we
want
to
choose,
1.9
1.10,
something
like
that
and
then
if
people
want
to
use
a
different
version,
then
they
will
have
to
do
this
long
dollar
rev
with
us
with
the
so
that
Alias
will
not
work
for
them.
They
will
have
to
create
the
full.
C
D
C
D
C
D
C
D
D
A
E
B
F
B
B
A
A
A
C
Yeah
but
then
yeah,
how
should
this
work
and
it
would
make
the
schema
thingy
optional
so
making
the
schema
format
optional
and
say
default
is
a
current
as
an
API
steamer
version.
I
can
agree
with
this
one
here,
but
re
making
the
schema,
World
optional,
I,
don't
think
it's
possible
for
a
parser.
It
would
be
horrifying.
A
It's
it's
not
really
optional
per
se,
so
you
can
basically
see
it
as
as
multiple
ways
to
define
a
schema.
You
can
Define
it
with
a
schema
format
with
a
schema
property.
You
can
Define
it,
as
is.
That
means
that,
basically,
just
without
the
schema
keyword
and
then
you
default
to
async
API
scheme
object.
C
C
F
A
C
No,
you
need
to
Define
it.
So
if
you
don't
give
the
schema
format,
so
you,
if
you
want
to
use
this
phone
here,
yes,
it
might
be
possible,
but
I
guess
it's
pretty
confusing
and
I
would
say.
If
you
don't
provide
a
schema
format,
it
is
always
the
current
API
schema
version
have
to
be
assumed
so
inlining,
Avro
or
protocol
or
whatever
in
this
version
it
should
not
be
possible.
D
A
Because
in
this
way-
and
this
is
where
it
gets
complex
because,
for
example,
tooling
couldn't
be
able
to
just
like
it,
couldn't
be
able
to
display
that
schema
without
knowing
what
it's
reference
from
in
this
schema
object.
So
if,
if
it
isn't
referenced
through
that,
it
wouldn't
know
what
the
schema
is.
So
that's
the
complex
part,
but
it
it
will
remove
all
the
complex
things
about
having
to
remember
that
schema
and
to
have
schema
format
together
and
everything
else.
But
it
just.
D
D
D
D
C
C
F
A
D
G
A
I
wonder
what
someone
new
coming
into
async
API
would
think
about.
What's
the
most
easiest
to
or
haven't
heard
of,
spec
3.0,
what
would
be
the
most
East
like
being
a
description
or
what's
it
called
like
always
having
the
same
structure
like
with
schema
format
and
schema,
or
whether
it
makes
sense
to
have
a
mix
of
both
just
to
simplify
the
structure
a
little
bit.
B
B
And
all
the
cases
I
know
in
case
of
Avro,
it's
like
it's
either
a
some
schema
registry,
yeah
or
they're
just
having
references,
local
references
to
local
files,
but
then,
even
on
the
CI
level,
they
do
some
magic
with
it.
They
upload
their
them
to
some
whatever
servers
and
then
mutate
the
references
to
point
to
these
new
locations,
all
that
stuff.
B
D
Maybe
they
changed
the
API,
but
at
the
time
I
wrote
this
the
API
to
get
the
raw
schema.
The
Json
definition
that
you
download
from
the
API.
You
have
it's
a
slash,
schema
endpoint
at
the
end,
so
so
yeah.
Otherwise
you
get
you
get
like
a
kind
of
a
grabber
object
with
more
stuff
from
from
skimmer
registry,
but
not
the
pure
scheme
itself.
So
so
yeah,
that's
what
that's
where
I
remember!.