►
From YouTube: Spec 3.0 meeting (March 16th, 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).
A
Fifth,
I
think
it's
the
fifth
meeting
right
where
we
are
gonna,
discuss
a
little
bit
about
the
spec
point
three
version
and
see
what
people
have
anything
to
discuss.
We
have
a
few
things
on
the
agenda
today,
but
I
think
we
have
plenty
of
room
for
questions
and
if
anybody
have
anything
to
add
friend,
do
you
mind
making
me
screen
share.
A
B
A
A
C
B
C
Okay!
So,
as
I
was
saying,
this
is
a
five
five
status
update,
but
I
decided
to
do
it
first
yeah
we
are
doing
like
this
today.
Everything
is
special
today.
What
I
wanted
to
say
is
that
we
started
implementing
the
parser
api
on
the
partial
gs.
C
C
Which
is
not
yet
done
by
the
way.
Obviously,
so
there
is
an
issue
tracking
the
effort
as
well
here
sorry
for
the
link
intrusion
there,
but
there
is
no
way
I
cannot
share
the
screen
either.
C
Some
of
us
started
to
write
the
password
yes
into
typescript.
For
now
we
are
three
people
involved.
It's
magic
me.
C
We
are
like
very
motivated,
I
would
say,
and
we
are
good
doing
pretty
well,
you
can
join
the
efforts.
I
invite
you
to
join
the
efforts,
because
it's
a
nice
excuse
to
learn
typescript
as
I'm
doing
so.
It's
my
first
project
and
I'm
starting
to
like
it,
which
is
good,
wait.
A
C
C
C
So
it's
everything
all
the
things
at
the
same
time,
which
is
pretty
funny
as
a
side
note
for
this
and
I'm
gonna
end
with
this.
We
are
not
completely
following
the
parser
api
that
we
find
in
the
parser
api
repository
because,
as
we
are
implementing
that
api,
we
are
finding
like
issues,
because
we
didn't
design
the
api
based
on
implementation,
but
rather
like
as
a
whole
concept
right.
C
C
A
Thank
you
next
up,
so
at
the
moment
we
have,
we
have
added
all
of
the
next
major
branches
for
the
majority
of
the
repositories.
A
For
the
3.0
schemas
or,
for
example,
the
3.0
schemas
is
that
targeting
targeting
the
next
major
branch
or
is
it
targeted?
Should
the
top
be
targeting
another
branch
that
is
based
off
the
next
major
like?
How
should
we
separate
that
it's
a
major
break
or
breaking
change
in
the
specific
repository
versus
a
new
feature,
for
example,
because
adding
the
3.0
schemas
is,
I
mean
technically,
it's
just
a
feature:
it's
not
a
breaking
change
per
se
so
directly,
including
it
might
not
make
that
much
sense.
C
Yeah
the
question
the
question
is:
is
pretty
clear
right,
like
does
a
new
or
does
a
new
feature
can
be
considered
like
a
breaking
change.
Well,
it's
not
that
question.
So
a
breaking
change
in
a
repository
doesn't
mean
that
it
should
become
a
breaking
change
in
a
dependent
repository
like
in
this
case,
the
breaking
changes
in
the
repository
per
se
and
in
the
package
in
the
library,
but
that
doesn't
mean
that
it's
breaking
the
spec
or
even
the
parser,
which
is
breaking
it
in
this
case,
but
it
could
not
right.
C
C
That's
my
concern.
If
we
go
with
a
let's
say,
official,
tooling
yeah,
it's
simple
and
I
will
advocate
for
moving
forward.
C
C
A
F
A
A
Because
if
we
merge
that,
if
we
merge
it
in
the
power,
so,
for
example,
so
the
parser
now
uses
the
next
major
version,
it
means
that,
as
soon
as
you
merge,
the
2.4
spec
json
schema
it
documents
into
the
master
branch.
A
We
need
to
keep
the
next
major
updated
at
the
same
time
right
and
that
actually
goes
to
the
next
agenda
items
as
well,
which
is
how
do
we
sync
between
these
two,
because
there's
probably
gonna
be
a
two
point
like
we
know,
there's
gonna
be
a
2.4.
Now,
there's
probably
going
to
be
a
2.5
as
well
before
3.0
is
released.
How
do
we
want
to
keep
those
next
major
version
branches
up
to
date
with
what
is
happening.
D
That's
why
that's
why
I
wasn't
like
that's.
Why
I'm
I'm
I'm
like
surprised
right,
like
I
think,
next,
major
branch
on
expectation,
schemas
and
parser
js
are
to
match
with
spec
next
major
branch.
D
A
C
The
point
is
that
so
it
might
happen
like
in
this
case
that
there
is
a
breaking
change
in
the
schemas,
but
it's
not
producing
any
breaking
change
in
any
other.
So
why
would
why
would
I
wait
for
a
new
major
person
on
spec
yeah
on
spec?
I
would
say
you
don't
you
continue.
D
You
release
a
new
merger
version
of
spec
json
schemas,
but
you
don't
work.
You
don't
work
on
the
next
major
branch
because
that's
like
kinda
reserved
for
for
the
other
for
syncing
with
sensing
with
with
the
spec
look.
Can
it
be
that
maybe
say
so?
To
avoid
this
confusion?
Is
that
so
we
leave
next
major
as
the
branch
to
work
on
the
next
major
version
of
a
specific
package
or
repository,
and
then
we
create
another
one
which
is
especially
on
parser
and
inspection
schemas.
D
We
create
another
one
which
is
next
spec
major
and
that
we
use
it
for
sensing
with
the
spec.
Just
I
don't
know
just
raising
the
the
user,
so
we
so
we
don't
have
this
problem
anymore.
Right
like
like
whatever
is
for
the
next
major
version
of
speculation
schemas.
It
goes
to
next
major,
but
whatever
goes
in
whatever
effort
goes
into
the
into
the
other
one
into
the
in
syncing
with
the
spec
goes
into
next
major
next
spec
major,
something
like
that
right.
So.
A
D
Review
but
that's
what
I
mean
like
you,
you,
you
point
it
to
the
next
major
branch
now
on
speculation,
schemas
right!
Yes,
it's
gonna
be
a
major
I
mean
unless,
unless
unless
the
the
work
is
done,
if
the
work
is
done
on
speculation
schemas,
you
don't
even
have
to
point
to
next
major
you.
You
create
a
a
pull
request
with
feed
and
exclamation
mark
and
so
on,
and
it
will
just
create
a
new
major
release.
You
don't
even
have
to
have
a
special
branch
for
this.
I
think
so.
D
That's
that
will
be
one
one
thing,
but
let's,
let's
stick
to
next
major.
So
next
me
you
create
you
use
next
major
as
your
next
major
version
branch
for
the
release
of
spec
json
schemas
right
once
it's
released
master
will
be,
will
be
updated
right
yep.
D
Then
you
merge
master
into
the
next
spec
major
branch.
So
you
get
the
changes
there
as
well
right
to
to
be
able
to
better
work
with
or
towards
version
three
or
that's
one
way
or
the
other,
the
other
one.
Is
you
merge?
D
You
create
a
pull
request
to
merge
it
to
master
like
next
major
to
measure
to
merge
it
to
master,
so
you
want
to
actually
release
and
before
even
its
merge
you,
you
merge
the
next
major
branch
into
the
next
spec
major
branch.
D
You
know
what
I
mean
you
don't
have
to
wait
for
mastery
even
right,
so
you
can
already
start
working
there
up
to
you,
I
mean
I
think
it's
safe
to
release
any
a
major
version
of
the
spec
json
schema
package
by
itself.
It
has
no
consequences
right,
like
other
than
updating,
parser
and
so
on,
but
but
that's
fine,
and
so
it
could
be
like
quickly
quickly
released.
D
We
don't
have
to
wait
for
anything
right
thing
is
the
in
my
opinion
and
as
per
my
understanding,
the
next
major
branch
was
to
sync
with
with
next
with
that
with
the
next,
with
the
3.0
right,
3.0
version.
If
that's
not
the
case,
then
let's
create
another
one.
So
we
can
sync
the
work
there
right.
That's
what
I'm
saying
so
so
we
can.
D
You
know,
so
we
get
both
yeah.
Well,
let's
make
it
clear
I
like
it,
you
know,
let's
make
it
clear.
What's
the
purpose,
because
for
me
that
next
major
branch
was
was
meant
for
that
and
if
I'm
not
mistaken,
I
think
how
many
pull
requests
are.
Gonna
are
gonna
make
this,
so
is
that?
Is
there
just
one
pull
request?
That's
gonna
create
this.
D
This
major,
this
new
major
version,
inspect
json
schemas.
You
don't
need
net.
You
don't
need
a
branch
for
that,
especially
brands
for
that
this
pull
request
can
have
the
feed
exclamation
and
it
will
trigger
you
directly.
A
D
A
D
D
I
will
I
will
discourage
that
because
then
it
means
that
I
mean,
if
it's
clear
like
when.
Is
it
gonna
finish,
as
in
yeah,
we
do
only
these
two
or
three
issues
and
that's
it,
and
then
we
release
this.
Otherwise
we
can
live
forever
in
this
branch
and
that's
gonna
be
a
problem.
D
C
C
B
C
D
C
A
A
If
we
want
to
make
the
changes
as
a
ripple
effect
to
all
versions,
and
I'm
not
sure
we
want
to
do
that
and
it's
more
a
consistency
problem
like
we
can
do
it
for
just
3.0,
and
that
would
be
it
right
so
going
forward.
We
would
have
all
of
these
consistencies
fixed,
but
of
course
the
previous
versions
would
not
have
those
things.
A
D
D
I
guess
right
like
it's
something
that,
like
let's
not
over,
complicate
our
lives.
That's
right,
yeah,
like
bum
cli,
I'm
sure
it
will
be
an
easy
fix
for
them
as
well.
Parser
is
a
fix.
Studio,
is
to
fix
and
stop
light
spectral
rule
sets,
I
think,
they're
not
they're
like
on
hold,
so
nobody
is
using
it
yet
like
we're
gonna,
probably
start
developing.
These
rule
sets
ourselves
maybe,
but
I.
E
Spectral
exactly
use
our
package
tool
from
fetching
it
will
it
be
like
a
huge
change
if
we
create
it's
only
the
import,
the
json
schemas,
but
by
the
absolute
path
to
the
json
schema,
not
by
the
index.js
but
to
the
json
yeah.
So
I
don't
think
so.
It
will
be
the
problem.
D
Just
I
mean
just
saying,
because
sometimes
we
we
start
thinking
like
what,
if
what,
if
someone,
what
have
in
in
majority
of
cases,
what
happens
is
that
you're
living
in
a
in
a
utopian
european
world
where
what?
If
this?
What
if
that?
But
none
of
these
things
are
happening
so
and
also
we
can
do
it.
I
mean
as
as
much
as
for
as
much
as
we
know.
I
think
there
are
four
or
five
packages
depending
on
on
on
this.
D
C
This
is
a
major
version,
so
using
segmented.
D
Exactly
we're
not
going
to
break
anyone,
I
mean
if
they
break
it's,
because
they
changed
the
dependency
on
their
side
and
to
a
new
major.
So
they
should.
They
should
be
the
first
ones
to
take
care
of
changing
whatever
is
needed.
So
so
I
don't
think
we're
gonna
be
breaking
anyone
unless
not
by
mistake,
but
true.
D
If,
if
it
will
be
like
a
lot
of
work,
producing
a
lot
of
work
on
their
side,
then
it's
like
okay,
we're
not
breaking
them,
but
if
they
want
to
upgrade
it
will
be
a
lot
of
work
from
on
the
inside,
but
it
will
be
anyway
at
some
point
right
pretty
soon
right
there.
D
So
I
don't
know
like,
but
the
evidence
is
that
we
have
so
far.
Is
that
nobody,
nobody
is
almost
nobody's
using
this
package.
So
that's
not
overcomplicate.
That's
my
opinion.
D
I
mean
don't
work
on
the
next
major
french.
Don't
accumulate
changes
just
release
them,
as
as
you
have
it,
if
you
have
a
breaking
change,
if
you
have
a
pull
request
with
a
breaking
change,
name,
it
fit
exclamation
mark
and
it
will
produce
a
new
major
version.
If
you
have
another
one
tomorrow,
that
is
another
breaking
change,
another
another
major
version
more
and
if,
in
a
week
we
bump
three
major
versions.
D
You
know
what
I
mean
that's,
and
we
can
do
that
for
sure.
Yeah,
like
that's
totally
fine,
I
mean
unless,
unless
we
and
and
especially
because
you
know
this
is
all
gonna
be
for
like
targeted
at
the
new
version
right
for
a
new
version,
so
whoever
is
targeting
or
older
versions
should
be
fine,
which
I'm
guessing,
for
instance,
spectral
rule
sets
and
bub
cli
they're
targeting
to
up
to
2.3
or
something
like
that,
which
should
be
fine
for
them,
like
they
shouldn't
be
caring.
E
D
Yes,
no,
no,
that's
true,
but
the
thing
is
that
I
will
first
clarify
if
next
major
is
for
this
or
if
or
if
it's
to
sync
with
spec,
which
that's
that
was
my
thought
at
least
so,
let's
clarify
this
and
let's
ask
whoever
was
involved
like
what
they
were
thinking
about,
because
I
have
the
feeling
that
they
were
also
thinking.
D
D
I
know
you
know,
I
know
you
were
the
ones
suggesting
it,
but
I
was
understanding
it
as
a
way
to
sync
with
the
spec
not
to,
and
that's
why
it
was
created
at
the
same
time
on
the
three
repos
right
and
otherwise
we
will
create
the
same
thing
on
every
reaper
right.
We
will
have
a
next
major
branch
on
every
reaper.
So
to
me
I
I
saw
it
like
this
like
it
was
just
for
sensing
with
the
spec.
D
C
Have
it
which
repository
where
so
you
can.
C
F
D
Which,
by
the
way
I
agree
like
we
shall
keep
it
to
next,
not
next
minor
yeah,
like
next
versions,
don't
have
to
be
might
always
there
might
be
a
yeah.
That's.
C
A
that's
another
point:
maybe
we
don't
need
next
next
major
next
release
measure.
Maybe
we
can
just
use
one
or
two,
and
it's
just
about
thinking
about
it.
We
kind
of
think
now
here
in
the
meeting
you
know
it's
like,
I
think
it's
simpler
than
what
we
are
presenting
here
right
and
we
don't
have
to
reinvent
the
wheel
at
the
end.
D
Know,
but
for
for
the
case,
I
think
for
the
case
of
I
don't
know
in
the
spec,
for
instance,
for
the
case
of
of
the
spec.
I
think
it
makes
sense
to
have
next
major
right,
because
there
will
be
a
lot
of
iterations
until
we
get
to
into
something
that
is,
let's
say,
doable
right,
but
yeah
on
the
rest.
I
don't
think
it's
needed
so
unless
it's
to
sync
with
this
one
with
the
next
one.
C
D
C
Now,
because
we
are
gonna,
merge
this
splitting
out
all
the
definition,
it
might
happen
that
the
only
the
only
one
that
it's
not
a
major
change
is
going
to
be
the
schemas
right,
because
we
are
just
going
to
be
adding
a
new
schema.
Yes,
it's
not
breaking
anything.
F
C
If
you
represent
what
the
I
presented
this
from
the
point
of
view
of
the
spec,
but
then
I
think
I
realized
it
doesn't
quite
make
sense,
because
the
only
problem
we
are
facing
here
is
coordinating
which
branches
are
being
involved
into.
One
spec
release
yeah,
and
we
already
do
that
in
the
issue
that
we
create
automatically
like
work
on
release,
blah
blah.
C
D
So
here
here's
one
once
again
the
discussion
about
having
specific
single
repository
life
cycle
versus
sensing
with
the
spec.
We
need
to
make
it
clear
and
I
will
add
something
to
the
branch
name
like
this
is
to
sync
with
the
spec,
and
this
is
not
about
this
specific
repository
right,
so
so
this
one
is
related
to
the
same
thing
with
the
spec,
like
I
don't
know
like
next,
for
instance
right
so
so,
next
to
me,
it's
it's
something
related
to
the
spec
actually
like
max
pack
will
will
trigger
this.
F
C
I
think
it's
that
yeah
exactly
that
makes
sense.
F
A
A
A
F
F
D
I
mean
it
usually
happens
in
the
beginning,
but
I
I've
been
thinking
about
it
and,
and
was
thinking
more
and
more
that
maybe
we
should
create
a
new
spec
for
that,
actually
like
it
to
be
a
new
spec
like
little
spec
right
like
a
different
type
of
file
or
a
spec
that
allows
you
not
only
to
to
group
other
as
reference
other
smtp
files,
something
like
that,
but
maybe
also
reference
graphql
schemas,
jrpc,
protobuf,
blah
blah
blah
other
type,
not
just
async
api,
so
open
api,
that's
a
good
point
which
reminds
me
a
lot
to
apis.json
from
kill
name,
which
is
exactly
not
exactly
that,
but
very
similar.
F
D
D
Yeah,
it's
basically
this
same
concept.
It's
a
it's
like
a
spec,
above
all
the
other
specs
which
is
compatible
with
all
the
other
specs
right
and
and
therefore
it
lets
you
group
other
the
specs.
We
don't
have
to
go
in
this
direction,
though,
like
we
can
start
simple
and
just
accept
this
in
kpi
right,
that's,
fine
and
and
and
that's
it
and
then
through
the
reuse
of
through
bindings
on
async,
api,
spec
and
all
the
work
that
will
happen
on
this
kpi.
D
Then
people
will
be
able
to
have
rest
apis,
define
graphql
and
so
on.
While
the
top
spec
only
accept
accepts
async
api
right
could
be
an
option
to
say-
or
maybe
not.
Maybe
we
move
this
responsibility
to
this
new
spec.
D
Of
the
use
cases
is
having
an
event
catalog.
He
actually
had
to
add
support
for
for
open
api
lately,
so
on
event,
catalog,
and
that's
precisely
what
I
mean
like
I
was
expecting
that
like
people
are
using
events,
yes,
but
there
is
also
using
rest
they're
using
graphql
they're
using
grpc.
So
eventually,
if
you're
letting
people
define
a
set
of
services
or
apis,
they
will
ask
you
for
more
like
what
about
those
rest
or
open
api.
What
about
graphql?
D
What
about
so
yeah
instead
of
over
complicating
using
kpi
one
option
could
be
we
move
all
of
this
to
the
new
spec
right
and
we
stick
with.
We
only
stick
to
events,
let's
say
or
messaging
on
dates
and
gps
pack
mic
facilitate
things.
C
D
Yeah
exactly
we
can
always
merge
them,
or
we
can
just
redefine
the
new
one
as
async
api
and
and
an
existing
one.
Right
now
is
a
subset
of
the
of
this
new
one.
C
D
I
think
the
issue
makes
sense,
I
think
it
it
probably
doesn't
have
to
be
addressed
inside
this.
It
can
be
a
specification
we
create
another.
Let's
say
specification,
I
don't
know
what
what
do
you
want
to
call
it?
Ap
api,
async?
Okay,
so
we
create
now
api.
D
D
And
and
we
work
there,
but
it
doesn't
make
sense
and
if
there's
a
new
repo
for
that
work,
which
I
think
it
will
make
sense-
probably
I
don't
know-
maybe
not.
We
moved
the
issue
to
over
this
reaper
and
that's
it,
but
that's
a
that's
how
I
imagine
it
if
the
spec
is.
If
we
work
on
the
spec
on
this
on
this
new
spec
on
the
same
reaper,
which
could
also
happen,
that's
a
different
file,
then
the
asus
stays
there
and
that's
it.
A
It's
probably
not
it's
not
okay,
no,
mind
them.
No,
but
yeah.
D
A
And
I
mean
we
are
we
actually
already?
We
haven't
really
decided
on
it,
but
yeah
sergio
you
had
an
issue
that
is
make
channels
feel
optional
within
the
async
api
file.
That
is
basically
making
that,
along
with
operations,
if
operations
are
optional,
I
think
that's
also
right.
The
thing
is.
D
D
D
C
D
Yeah,
it
makes
sense
but
yeah
it's
not
easy
to
to
see
it
yep
so
or
maybe
you
want
to
define
all
the
channels
of
a
specific
application
and
your
document
is
still
incomplete,
like
you
haven't
finished
your
async
document
yet,
but
you
you
already
want
to,
I
don't
know
during
the
documentation
or
something
like,
and
then
you
are
in
this
weird
state
that
no,
I
mean
a
specific
application,
but
I
don't
have
operations
yet
because
I
haven't
had
time
yet
to
define
them,
but
I
still
mean
a
specific
application
and
you
know
it
might
be
a
problem.