►
From YouTube: Spec 3.0 meeting (September 14, 2022)
Description
A
A
A
A
B
A
They
all
do
I
have
anything
to
share.
What
do
you
think?
Can
we
it's
probably
just
me
being
thick,
but
what
do
we
mean
by
a
freeze
on
the
release?
Do
we
mean
we
nail
down
what
we
think
the
next
spec
is
going
to
be
and
we
won't
make
any
more
changes
and
that
and
then
we
allow
ourselves
three
months
to
make
get
all
the
tooling
up
to
date.
Is
that
the
idea
that's
a
general
idea
behind
it?
Yeah,
okay?
A
When
do
we
think
of
as
the
release
being
as
the
new
version
being
out
and
instead
of
when
the
spec
is
ready,
we
describe
it
as
when
the
tooling
is
ready
and
we
align
the
times.
Okay,
that
makes
more
sense,
and
maybe
also
just
to
emphasize,
because
while
this
is
while
this
is
happening
like
I'm,
not
saying
that
the
spec
can
be
used,
but
it's
not
entirely
impossible
to
use
it
in
the
meantime
and
should
show
us
just
that
it
it
still
a
release
candidate
if
that
makes
sense.
A
B
You
know,
for
example,
when
you
are
when
you're
working
for
a
company-
and
you
have
a
free
spirit,
it's
more
like
we
don't
release
feature,
we
don't
release
anything
right,
and
here
is
not
that
it's
yes,
as
you
mentioned,
it's
putting
the
release
candidate
on
hold
right,
like
they're
available
for
three
months.
Isn't
it.
A
Yeah,
but
it
means
that
there
won't
be
any
changes
to
the
release
candidate
from
that
point
onwards.
Right,
yes,
yeah
I
mean
that
doesn't
stop
us
making
changes
in
another
Branch
for
the
next
release,
but
so
it's
not
like
the
spec
work
has
to
stop,
but
just
that
we
draw
a
line
under
that
particular
version.
A
Yes,
exactly
yeah
I
think
I
think
we
might
end
up
with
a
little
bit
of
so.
Let's
say
that
we
we
spend
three
months.
Let's
say
we
we're
gonna
end
up
with
three
months
for
each
period,
so
a
major
version
change
the
version
after
the
major
version,
which
is
probably
just
a
minor
release.
Would
that
mean
that
the
release
of
the
main
version
and
the
version
after
that
will
be
kind
of
on
top
of
each
other,
maybe
a
month
apart,
because
you
don't
have
that
much
of
a
freeze
period
with
the
next
version.
A
A
B
A
A
B
Okay,
so
I
wanted
to
it's
been
a
few
few,
a
couple
of
minutes
explaining
where
we
are
on
the
development
of
the
parts
of
GS
version
2,
which
is
a
breaking
change,
I'm
gonna
share
first
here
and
over
YouTube
as
well
I
hope
it
shared
the
last
updates
on
on
the
on
the
progress.
So
we
are
very,
very
close
to
finish
the
development
of
this
person,
at
least
to
have
like
a
alpha
or
beta
or
whatever.
B
B
B
B
B
Why
is
that?
Okay,
here,
I'm
gonna,
take
this
to
share
as
well,
but
there
is
a
discussion
open
by
Magic
about
how
we
want
to
release
this
new
version
and
it's
not
about
the
process
itself
of
releasing
but
more
how
we
want
to
sync
up
with
tooling
like
the
generator
and
templates,
because
at
the
at
their
very
moment
we
released
a
new
version.
The
templates
will
be
using
an
API
that
it's
not
anymore
there,
just
for
remembering
in
the
new
parsert
V2.
B
We
are
completely
writing
the
the
API
of
the
parser.
So
all
of
this
has
to
be
taken
in
account
just
to
move
all
the
templates
to
use
the
new,
the
new
API
right.
So
how
we
want
to
handle
that
the
discussion
in
the
discussion
is
open,
so
I
encourage
you
to
join.
There
are
already
some
comments
in
there
and
some
proposals
made
by
Magic
that
make
a
lot
of
sense.
So
that's
the
next
step
or
the
next
big
step
and
yeah.
That's
it
any
question.
B
Still
discussion,
I,
guess
yeah,
so
what
magic
suggested
is
to
by
default,
because
okay,
much
a
good,
what
suggested
is
to
add
the
old
API
on
the
parser,
so
we
released
person
two
with
a
new
API
but
also
have
a
way
to
convert
a
patch
document
to
the
old
API.
So
whenever
you
you
import
a
new
parser,
you
can
still
use
the
odd
API
by
just
calling
a
helper
function.
B
The
idea
has
to
release
that
for
some
time
until
we
deprecated
right
and
we
only
have
the
the
new
API
so
templates
could
use
that,
so
the
generator
sorry
we
could
use
that
for
still
for
for
calling
the
the
parser
methods
and
what
Matrix
suggested
is
to
add
a
property
I.
Don't
know
where
is
that
yeah
called
API
version
to
determine
which
version
of
the
of
the
parser
a
template
should
use
by
default
would
be
the
I
think
the
the
old
one
yeah.
B
B
B
A
I
think
that
makes
sense,
I
think
we
will
want
some
way
to
encourage
people
to
to
move
forward,
but
I
think
we
can
always
do
that
like
later
on,
when
when
the
new
version
is
out
deprecating
the
default
Behavior
to
nudge
people
to
start
moving
across
and
enabling
the
new
Behavior
so
I
think
yeah.
What
you
described
makes
total
sense
to
me.
A
A
All
right
I
does
anyone
have
any
anything
they
want
to
discuss
or
I
have
one
more
thing:
I
would
like
to
introduce
I
introduce
it
before
I
went
on
holiday,
but
that's
quite
a
while
ago.
So
I'll
probably
do
it
again
just
to
get
some
more
visibility
to
it,
but
does
any
of
you
have
anything
you
would
want
to
add
before.
A
A
A
But
there
is
a
problem
with
it
for
our
use
case,
which
is
in
async
API.
You
can
Define
message
payload
with
different
schema
formats.
This
means
that
we're
not
tied
with
Json
schema.
Specifically,
we
also
have
Avro.
We
could
also,
in
theory,
have
protocol
for
maybe
even
graphql
schemas
xsd
schemas.
Whatever
other
schema
format
you
might
want
to
use,
you
could
actually
do
it
with
async
API.
A
This
use
case
is
quite
unique
to
to
to
the
standards,
because
from
an
open,
API
perspective,
it's
always
paired
with
Json
schema.
You
can
change
it
it.
That
is
the
one
schema
format
that
you
have
to
use.
Then
they
upgrade
the
version
that
the
the
standard
uses,
but
it's
still
Json
schema
protobuf
have
its
own
format
for
defining
message.
Payload
graphql
has
graphql
schemas,
like
all
of
these
standards,
always
have
just
one
way
of
defining
schemas.
A
A
And
at
the
moment,
I
wrote
it
as
a
RFC,
which
is
basically
that
this
could
be
used
by
other
standards
as
well.
So
it's
not.
It's
not
specifically
focused
on
async
API
that
that
much
okay,
so
what
it
does
is.
It
takes
all
of
the
things
that
we
have
in
Json
reference
and
then
apply
a
certain
behaviors
for
non-json,
like
when
we've
linked
to
non-json
files.
A
So
this
means
that
this
standard
is
what
we
usually
refer
to
as
the
superset
of
Json
reference.
So
what
worked
before
with
Json
reference
still
works
with
this
this
new
standard,
and
we
don't
have
to
change
anything.
It
just
enables
us
to
do
something
called
linking,
for
example,
linking
to
an
protocol
file
or
an
xsd
file.
A
A
A
A
A
How
you
would
then
interact
with
this
protobar
file,
for
example
a
protobuf
Content
that
is
still
up
for
debate
or
it's
up
to
each
implementation
to
figure
out,
because
there
can
be
multiple
ways.
You
want
to
interact
with
it
and
there's
not
really
a
standard
that
we
can
apply
here,
which
makes
it
kind
of
even
harder
to
do.
A
A
B
Maybe
you
can
add
some
context
of
why
this
you
know,
because,
depending
on
well,
I
can
say
depending
on
so
it's
not
the
same
for
async
API,
the
data
that
it
wanted
to.
It
wants
to
retrieve
right.
So
that
could
happen
that
there
are
some
technical
limitations
on
what
part
of
the
document
you
can
grab
and
because
of
that,
maybe
you
you
from
the
point
of
view
of
async
API.
You
are
maybe
only
interested
in
some
part,
for
example
in
protobuf.
B
You
are
interested
in
the
message
or
something
like
this
right,
but
maybe
other
specs
or
other
consumers.
As
this
word
that's
good
price
here,
maybe
they
are
interested
in
other
parts,
but
because
of
those
technical
limitations.
If
you
set
a
standard
that
pretends
or
tries
to
work
for
everyone
yeah,
it
may
happen
that
some
some
some
consumers
will
be
penalized
and
won't
be
able
to
access
the
data
they
want
right.
A
We
do
yeah
yeah
me
and
Sega
spend
four
hours
today
discussing
Andrews
Henry's
comment
about
clarifying
different
parts
of
of
these
standards,
because
we
have
in
order
to
understand
this
issue
in
this.
It
means
that
you
have
to
understand
somewhat
of
eight
standards
and
how
they
interact
with
each
other,
which
is
it
gets
hairy,
real,
real,
quick
and
especially
when
we
start
talking
about
it.
C
And
you
know,
let's
get
a
quick
sort
of
procedural
question,
of
course,
so
this
lays
outside
instant
kpi
and
I.
Think
that's
that's
appropriate,
because
I
do
think
it's
a
sort
of
a
widespread
problem
to
get
this
approved.
What
what
body
would
you
appeal
to
for
for
this,
like
the
Json
schema
or
who's
who's,
the
one
that
signs
off
on
those
kind
of
thing.
A
A
That's
a
good
question
because
the
I
haven't
really
thought
it
through.
Yet
because
all
I
see
this
is
as
it's
basically
just
an
IFC.
It's
just.
This
is
a
standard
that
that
we
want
to
follow
every
others
can.
If
they
have
this
same
use
case,
they
can
apply
the
same
standard
and
the
I
won't
say
the
problem,
but.
C
Yeah
so
I
mean
the
the
I
guess.
The
challenge
is
in
the
meantime,
you're
sort
of
redefining
a
known
entity
from
I
think
correct
wrong,
but
Json
schema
to
do
something
other
than
what
it's
intended
to
do,
which
is
always
sort
of
a
dangerous
scenario.
Right,
like
dollar
sign
ref
is
meant
to
point
to
Json
and
I
totally
am
empathetic
to
like
you
know
it
should
be
easy
to
do
something
else
other
than
that,
but
it's
just
it's.
It's
interesting.
A
C
It
would
be
real
nice
to
have
that
in
XML,
I
mean
you
look
at
events
coming
up,
sap
I
mean
that's
a
huge
thing
and
those
are
XML
data,
so
yeah
I
would
encourage
us
to
look
at
it
for
V3,
and
you
know
I
think
your
your
solution
is
in
the
right
vein.
It
just
you
know,
is
overriding.
What's
pretty
well
defined
dollar
sign
ref,
you
know
is
that
is.
A
A
C
I
guess
I
just
don't
between
those
two
like
I,
like
your
your
PR
it
just
you
know,
do
we
need
to
use
dollar
sign,
ref,
I,
guess
I,
don't
have
full
visibility
in
what
that
is,
I'd
actually
be
interested
in
what
what
Dale
thinks,
because
I'm
sure
Dale
has
I
I.
Guess
I
won't
speak
for
Dell,
but
you
know.
Ibm
has
such
interesting
interactions
with
the
Legacy
world
through
mq
I
would
be
interesting
to
see
what
you
think
about
sort
of
implications
for
cobal
copy
books.
That
type
of
thing.
A
A
A
C
C
Guess
the
challenge
and
yeah
I'm
pretty
far
removed
from
the
code,
but
I
assume
that
there's
a
lot
of
standard
libraries
for
parsing
out
Json
and
that
would
include
native
handling
for
dollar
sign
refs.
And
so,
if
you
throw
non-json
at
these
standard
standard,
Libs
I
assume
that
you
run
the
issues
pretty
pretty
quickly
because
those
standard
Libs
don't
understand
what
we're.
C
Yeah
in
some
you
know,
Michael
Davis
from
Solace
did
some
experimentation
with
this
and
I
I
do
seem
to
remember
at
least
with
some
libs
that
it
came
in
it's
just
a
string
which
is
a
behavior
I.
Think
that
you
want,
but
I
wouldn't
say:
I
wouldn't
I,
wouldn't
bet
the
house
that
every
lib
would
do
that.
So
so.
C
C
A
And
the
and
the
weird
part
is
that
the
standard
doesn't
Define
this
Behavior,
as
as
far
as
I
can
remember.
So,
if
you
please
correct
me
if
I'm
wrong,
but
I
can't
remember
anywhere
within
Json
reference,
for
example
that
states
anything
like
how
to
handle
or
fall
fail
if
it
encounters
and
non-json
file
or
I'm,
sorry
I
think
I
have
to
look
into
that.
A
C
Yeah
I
mean
I
would
encourage
you.
You
know
to
keep
on
it
because,
regardless,
if
we
use
dollar
sign,
ref
or
some
sort
of
custom
tag,
I
think
that
your
solution
is
very
similar
to
ones
that
we
had
discussed
internally
at
Solace
and
I.
Think
it's
really
really
needed,
as
people
use
things
that
are
different
than
Json.
So
right
yeah,
that's
not
it's
not
particularly
helpful,
but
I
do
think
it's
a
worthy
worthy
goal
for
B3.
A
Yeah
I
kind
of
agree,
yeah
and
it
I
mean
it
wouldn't
I
I,
guess
it
just
comes
down
to
the
prayer
like
how
we
prioritize.
Do
we
prioritize
the
user,
or
do
we
prioritize
the
developers
that
creates
tooling
for
it
and
also
I,
guess
those
that
use
this
tooling
in
terms
of
these
failing
behaviors,
like
fallback
behaviors,
how
it
will
be
able
to
handle
them
right.