►
From YouTube: Spec 3.0 - August 17 2022
Description
A
Here
it
is,
you
know
that
this
reading
is
recorded.
A
A
C
A
C
Okay,
so
then
I'm
gonna
save
some
money
and
I'm
not
gonna
go
to
therapy
anymore.
I'm
gonna
use
this.
A
A
A
C
That
the
json
pointer
is
meant
for
json
structures
only
right,
so
it's
not
that
there's
no
way
or
it's
undefined
or
anything
it's
that
it's
explicitly
defined,
that
it's
only
for
jason.
So
so,
if
you
want
to
use
it
for
protobuf
cool,
you
can
come
up
with
some
hack
but
yeah.
It's
a
hack,
it's
not
in
unintended
usage.
So
and
this
is
a
spec,
so
we
shouldn't
be
using
hacks
in
the
spec
right.
So
if
we
ever
want
to
become
a
standard,
yes,
I
agree
if
we
want
to
become
a
something
weird.
C
Yeah,
of
course
thing
is
that,
but
with
avra
I
don't
think
there's
an
any
issue,
because
afro
is
jason,
so
so
yeah
so
average
is
okay.
This
is
another!
You
need
to
point
to
the
right
place.
Of
course,
that's
the
only
thing
I
I.
C
Yeah,
so
what
we
do
is
some
kind
of
like
a
streak
like
yamls
will
also
not
be
used,
but
since
we
specify
in
the
spec
that
we
only
allow
the
subset
of
yaml
that
is
compatible
with
json,
then
we
allow
people
to
use
all
the
refs
there.
There's
some
pointers
there,
because
yeah
I
mean
it's
just
yaml
is
just
a
presentation
mode
and
the
source
will
be
for
the
tool.
The
source
is
going
to
be
a
json
object.
C
So
in
the
end,
yeah
yaml
is
just
presentation,
so
it's
a
presentation
layer
on
top,
so
so
yeah,
so
it's
possible,
but
in
theory
it's
also
should
not
also
be
allowed
with
general.
A
Yeah
yeah,
so
I
have
the
exact
same
thoughts
that
you
have.
Luckily,
we
have
opposing
thoughts
as
well,
so
I
kind
of
hope
that
that
jeremy
would
be
here,
but
it
is
what
this
but
he's
he's
opposing
or
his
argument.
As
I
understand
it
is
that
er
that
the
json
reference
standard
that
you
shouldn't
read
the
json
part
as
being
specific
for
json
part
like
or
json
specific,
but
you
should
take
a
step
back
and
say:
okay,
you
have
this
object.
A
So
I
think
it's
a
case
of
how
like
how
specific
do
we
want
the
standard
to
be
and
how
much
can
be
abstracted
in
some
sense
and
say:
okay,
so
take
a
step
back
and
say:
even
this
is
very
specific
within
the
standard.
You
have
to
take
a
step
back
and
we
can
explain
it
from
the
reference
standpoint.
A
A
A
So
that
he
is
opposing
to
or
not
opposing
but
like
we
should
be,
and
as
a
great
point,
we
should
be
very.
What's
it
called
like
not
be
afraid,
but
we
shouldn't
lightly
create
new
standards
just
because
we
can
just
in
case
any
of
you
have
seen
it.
C
What
what
if
the
new
standard
is
exactly
what
their
json
pointer
is,
but
without
explicit
definition,
saying
that
it's
only
for
json
and
then
we
we
increase.
You
know,
like
the
definition
to
you,
know,
to
any
kind
of
data
structure
right.
In
that
case,
I
don't
think
it's
bad
to
have
a
new
standard
or
a
new
spec
right.
If
you
want,
because
people
will
have
to
do
nothing
like
software
meant
to
be
working
for
json
pointers
will
work
with
these
new
pointers.
A
C
And
the
only
thing
is
the
other
way
around
or
not,
of
course,
but
I
mean
I
know
we
have
to
at
all
costs
always
try
to
not
reinvent
the
wheel,
but
the
thing
is
that
we
have
a
very
specific
problem
here
that
it
nobody
thought
about
before.
I
think
because
yeah
the
past
was
either
xml
or
json
so
and
we
have
xml
pointers
and
we
have
jsonpointers
so
yeah,
but
now
we
don't
have
xml
and
json.
C
A
A
Everything
works
exactly
like
json
reference,
but
if
you
start
linking
to
other
non-json
files,
then
there's
various
specifics
about
what
to
do
with
that,
and
I
basically
just
took
the
easy
approach
and
say
you
can
reference
non-json
values,
and
then
you
should
place
that
into
yeah.
I
I
just
created
this
content
thing,
so
everything
is
just
loaded
into
a
string
and
that's
it
in
tooling.
A
A
A
A
So
this
is
the
proposal
for
now
there
is
still
some
some
things
that
we
have
to
resolve
all
right.
Maybe
I
should
still
take
a
step
back
okay,
so
I
had
some
requirements
for
the
stand
for
the
new
standard
things
that
it
should
support
or
should
define,
so
it
should
always
produce
a
validation
document.
A
A
And
this
is-
and
the
reason
I
did
that
is
because
async
api
is
in
json
or
yaml.
For
that
sake,
and
it
was,
it
was
a
concern
from
who
was
it.
It
was.
A
A
It
should
define
what
to
do
when
you
reference
non-json
data
in
json,
because
well
that's
the
entire
standard.
Basically,
it
should
still
define
the
behavior
of
referencing
json
data.
Basically,
the
json
reference
standard
all
over.
A
A
C
A
A
So
if
you
have
a
relative
reference,
the
application
which,
in
this
in
this
case,
would
be
json,
schema
or
open
api,
they
can
define
something
called
the
base
uri
that
should
be
resolved
from.
So
all
relative
references
should
use
that
base
uri
and
then
add
the
relative
reference
to
that
to
get
to
the
fully
qualified
uri
for
the
resource,
and
that
is
the
primary
problem
with
with
these
references,
because
none
of
the
tooling
respect
those
application,
specific
requirements.
A
If
that
makes
sense,
beautiful,
beautiful,
no
but
open
open
api
3.1
defines
its
own.
It
doesn't
even
reference
json
reference
anywhere
within
this
big,
as
I
can
see,
it
only
referenced
this
uri
format,
standard
and
json
reference,
the
same
thing
and
they
even
have
custom
bundling
behavior
in
terms
of
okay.
So
in
your
implementations,
if
you
see
a
reference,
you
need
to
check
under
definitions,
or
in
our
case
it
would
be
components
if
you
wanted
similar
logic.
So
this
means
that
there's
very
specific
things
for
each
standard,
how
it
should
behave,
and
it's.
C
It's
challenging
right
because,
yes,
if
you
isolate
the
definition,
you
don't
have
the
context
of
thinking
to
be
a
document
or
anything
you
don't
know
if
it's
coming
from
one
way,
one
place
or
another.
So
you
don't
know
by
isolating
the
definition,
you
don't
know
if
it
should
follow
one
way
of
resolving
the
references
or
another,
because
everyone
is
using
dollar
ref,
the
dollar
ref
name
right
so
yeah
and
everybody
is
using
the
same
format
for
the
dollar
ref
value.
It's
just
the
way.
C
A
Is
true
the
way
I
currently
solve
this
problem
is
by
defining
the
exact
same
thing
in
terms
of
application
space,
so
this
means
that
the
standard
defines
that
you,
as
a
user
of
the
standard,
has
to
define
something
like
a
reference
format.
That's
that's
taken
a
step
back.
Basically
that
defines
this
metadata
of
the
reference.
A
A
C
Thinking
that
yeah,
like
reference
format,
schema
format.
It
sounds
to
me
that
we're
I
don't
know
too
many
formats
right
too
many
I
mean
we
can
always
change
the
name
rather,
but
but
aren't
we
customizing
too
much,
maybe.
C
Like
we're,
making
every
piece
of
the
puzzle
to
be
movable
and
and
potentially
change
so.
A
A
And-
and
it
is
a
problem-
so
it's
it's
not
something
that
really
goes
away,
even
though
that
the
idea
is
to
not
give
tooling
but
create
the
tooling
around
the
standard.
C
Well,
that's
their
problem
like
they
should
be
updating,
of
course,
like
we
can
do
I
mean
we
can
do
nothing
about
it,
just
maybe
just
notice
them
and
tell
them
that
I
don't
know
they
have
a
problem
there
and
creating
an
issue
or
something
like
that
and
if
they
want
to
solve
it,
that's
fine,
if
not
it's
their
decision.
Of
course,.
A
I
am
working
on
it's
something
that
I
haven't.
It's
not
done
basically,
but
the
proposal
is
that
I
think
we
can
join
forces
in
solving
this
reference
issue
because
it's
all
related,
it's
a
problem
in
open
api.
It's
a
problem
in
json
schema
and
we
have
a
little
bit
of
different
use
cases
in
terms
of
what
we
expect
from
the
library
that
resolves
these
references.
A
A
Let's
just
say
all
three
standards
friction
and
gather
the
community
around
those
tools,
and
I'm
not
saying
we
should
create
the
tools,
but
we
can
also
adapt
current
tools
that
has
this
reference
and
want
to
solve
it,
and
but
I'm
putting
the
proposal
together
to
highlight
okay,
here's
all
the
standard
that
uses
references,
here's
all
the
the
differences
between
them
and
how
it
should
work,
here's
the
requirements
for
the
tools
we're
looking
for,
and
here's
the
basically
the
api
of
the
library
we're
looking
for
this
library
should
be
able
to
do
this.
For
example,.
C
A
A
A
These
all
of
these,
I'm
just
going
to
reference
three
standards
here:
open
api,
async,
api
and
json
schema
and
can
accurately
based
on
whatever
the
standard
follows
for
like
how
they
define
references,
can
accurately
resolve
the
values
that
that's
basically
it
so
async
api
can
define
their
own
behavior,
because
I
don't
think
that
this
is
not
a
use
case
for
open
api.
For
example.
It's
not
a
use
case
for
json
schema,
but
it
yeah,
but
we
all
want
to
reference
to
something.
C
C
A
A
C
A
C
A
C
So,
there's
no
way
to
tell
hey
open
api:
let's
join
forces
because
yeah
they
don't
care
about
the
tools
so
going
one
by
one
each
of
the
tools
and
hey.
C
Do
you
want
to
join
this
effort,
which
I
don't
know
if
it's
one
it's
I
don't
know
if
it's
gonna
work
like
if
it's
gonna
be
it
might
work.
But
the
thing
is
that
I
don't
know
if
it's
going
to
be
worth.
C
A
A
C
I
don't
know
if
it's
something
that
they're
worried
about
to
be
honest,
like
we
were
worried
about
it,
but
I
don't
think
I
don't.
I
don't
see
the
json
or
schema
or
open
api
community
worried
about
it.
Open
api
itself,
for
instance,
is
not
worried
about
tools.
They
don't
care,
they
have
this
schema
as
well,
and
they
might
be
worried
that
the
tools
are
not
following
are
not
compliant
but
and
then
my
my
concern
here
is
that
they
may
be
difficult
to
convince
to
join
the
effort
because
they
win.
C
B
Well,
I
agree
with
what
fran
is
saying.
I
wanted
to
say
something
so
would
it
be
possible
to
declare
a
standard?
I
wrote
in
the
chat
and
zoom
something
I'm
gonna
clarify
that.
So
I
asked,
if
you
mean
some
kind
of
meta
standard
and
soup
standards
like
one
for
async
api,
another
for
open
api,
or
rather
because
you
were
discussing
about
tooling,
but
what?
If
we
do
it
in
that
way,
where
we
define
a
schema
that
is
compatible
completely?
B
B
So
in
that
way
I
mean
I.
I
completely
agree
that
if
we
go
with
the
tooling
side,
I
I
think
we
are
going
to
be
alone
there
to
be
honest
and
I'm
not
I'm
not
blaming
it's
just
because
we
have
the
need
now.
Well,
we
have
to
create
the
need.
If
we
want
to
convert
this
to
a
standard,
we
have
to
create
that
need,
and
I'm
not
sure
if
tooling
is
the
right
way
because
again
tooling
would
be.
C
I
get
it
yeah
yeah
now
the
problem.
The
problem
is
that
we
have
to
create
tools
the
problem,
but
we
will
have
to
create
tools.
If
we
create
a
new
standard,
our
tools
will
have
to
support
this
new
standard.
Obviously,
and
if
we
create
a
java
parser
a
go
parser
we
we
will
have
to
implement
this
new
standard
regardless.
C
C
You
know
reference
resolution,
format
or
mechanism,
sorry,
so
so
yeah.
So
that's
that's
the
thing.
C
B
Did
you
see
something
like
sorry?
Okay,
so
we
are
doing
something
in
whenever
we
declare
how
our
schema
object
work.
We
say
something
yeah.
We
extend
from
json
schema
right,
but
we
add
some
extra
things
so
with
this
example,
I
think
just
to
clarify
and
to
people
that
it's
listening
to
us
or
we
listen.
B
A
I
think
it's
important
to
remember
that,
even
though
that
we
intend
or
propose
to
create
tools
for
more
than
our
own
standout
is
because
the
tooling
has
to
be
engineered
to
support
it
from
the
start.
The
architecture
of
the
tool
has
to
have
this
or
the
requirements
of
the
tool
has
to
have
this
in,
while
it's
being
developed
and
architectured.
A
A
And
while
we
do
that,
I
can
see
it
as
being
supportive
for
all
of
the
other
formats,
even
though
that
we
maybe
not
focus
on
it
from
the
beginning
yeah
right.
So
it's
more
from
taking
a
step
back
and
try
to
look
at
the
bigger
picture
and
provide
better
tooling
for
the
entire
ecosystem,
which
should
be
the
absolute
goal.
A
C
Or
the
standard
the
standard,
so
we
stick.
We
stick
to
the
existing
one,
even
though
it's
in
the
broken,
but
we
stick
to
it.
We
don't
change
it.
We
continue
using
the
same
one.
We
continue
resolving
references
the
way
we
do
it
right
now,
even
if
it's
wrong
in
some
cases,
but
we
change
nothing.
We
don't
do
anything
there
and
we
move
this
in
parallel
and
create
something
probably
even
outside
the
async
api
initiative.
I
will
say:
if
it's
it
can
become
its
own
standard.
C
We
can
even
propose
it
to
to
ietf
or
something
like
that
to
become
an
rfc
there.
That's
another,
of
course
that's
another
subject,
but
this
can
be
something
separate
and
that
will
be
like
it
will
be
like
it's
like
this.
You
know
a
new
spec
for
referencing
and
any
kind
of
objects
and
a
set
of
tools,
a
set
of
resolvers
right
in
javascript
typescript.
You
know
java
go
whatever
in
many
languages,
so
it's
like
a
separate.
I
see
it
like
a
separate
initiative.
To
be
honest,
it's
another
effort
completely.
C
I
mean
we
can
start
it
inside
this
in
kpi.
But
at
some
point
I
see
it
like
it
will
probably
have
its
own
house
yeah,
and
I
see
this
as
complex
enough
to
not
put
it
for
this
for
the
version
three
of
the
spec,
because
now
that
we're
discussing
this
I'm
seeing-
and
you
know
it's
it's
too
much-
and
this
is
the
kind
of
thing
that
you
don't
want
to
get
wrong.
A
A
A
C
Because
it's
just
well
3.1
actually
yeah
yeah.
If
we
don't
change
the
format
yeah
exactly
it's
not
a
breaking
change,
so
I
mean
it's
it's
disgusable
but
yeah.
I
don't
think
it's
a
it's
a
breaking
chain.
So
so
yeah
three
point
one
three
point:
two:
where
three
point
one
for
sure
now
that
gets
gonna
happen,
probably
after
three
or
three
two
or
three
months
after
we
release
version
three
but
yeah
3.6
might
have
this
behavior.
C
Something
like
that
and-
and
I
think
it's
gonna
take
time
for
us
to
to
grab
our
hands
around
this
problem
and
how
to
solve
it
properly
and
come
up
with
use
cases
and
with
different
formats.
Protobuf
xsd,
avroids
jason
said:
that's,
not
a
problem.
C
Flatbuffer
edi
cobble
copybook
whatever
I
don't
know
whatever
there
is
right:
oh
yeah,
kobold,
yeah
cobalt
is
I
love
it.
So.
C
Structures,
it
was
called
structure
in
fortran,
so
yeah
yeah,
but
even
more.
I
don't
know
like
typescript
types,
I
don't
know
any
other
kind
of
form
of
graphql
types
and
so
on
so
so
yeah
and
see
if
the
new
format
adapts
well
to
this
new
to
this
kind
of
documents,
mixing
all
of
them
together
and
see
how
it
works
if
it
works
well
or
not
just
to
basically
to
test
it
properly.
C
But
I
I
have
the
feeling
that
this
one
can
make
version
three
be
postponed
by
a
lot
and
yeah
and
that
will
be
postponing
the
public
subscribe.
Confusion.
The
channel
reusability
thing,
the
the
request.
Reply,
features
yeah
like
there's.
I
think
there's
enough
value
already.
If
we
don't
fix
it,
that
we
can
ship
and
move
forward,
and
so
we
decouple
it
from
version
three
right.
So
so
we
we
also
don't
feel
the
stress
that
then
we
have
to
ship
it
as
soon
as
possible.
C
A
C
C
A
C
C
C
C
B
C
And
it
just
supports
a
url
right
without
the
fragment
part,
just
a
fully
qualified
url,
but
without
the
fragment
part.
C
A
C
A
Means
that
user
like
it
would
then
require
version
four
sorry
again,
it
would
then
require
version
four.
Instead
of
version
like
a
feature
change,
if
you
want
to
standardize.
C
A
B
C
A
C
C
My
feeling
is
that
this
is
complex
enough
to
dedicate
a
probably
a
whole
version,
a
whole
effort,
like
the
one
we're
doing
with
version
three,
but
only
to
that
only
to
this
thing
this
is
huge
this
one,
but.
C
A
A
A
C
Hour,
I
have
a
one
last
comment
related
to
version
three.
So
today
I
was
thinking
about
this
new.
What's
it
called
channel,
you
know
this
new
channels
object
on
version.
3.
we
have
a
fill
called
address.
C
C
You
know
these
variables
that
you
can
put
in
in
the
middle.
If
we
have
a
field,
that's
called
address.
A
C
C
C
C
The
first
one
will
be
indicating
that
we're
we're
kind
of
like
escaping
the
dot
in
in
amqp,
so
this
dot
will
not
be
a
separator
in
in
in
amqp.
I
don't
know
if
this
is
even
possible,
but
that's
what
it
will.
It
should
mean.
I
think,
but
I
don't
think
we're
we're
not
we're
not
following
this
we're
we're
just
taking
the
value
as
it
is
and
that's
it,
but
I
see
some
people
using
slash
because
it's
a
separator
and
some
other
people
are
not
and
also
you
can
in
your
templates.
You
cannot
do
this.
C
You
can
you
this.
This
is
not
valid
you're.
I
template
right
because
the
you
know
I
I
mean
I
have
to
check
again,
but
I,
if
I
recall
correctly,
this
is
not
valid.
It
has
to
be
in
between
classes,
so
the
variable
name
needs
to
be
in
between
slashes.
It
cannot
be
in
the
middle
of
a
string
and
for
for
you
are
item
plate.
The
dot
has
no,
it
has
no
meaning
it's
just
another
character.
C
C
A
But
very
quickly,
it
became
okay.
So
now
it
needs
to
be
a
valid,
a
valid
channel
with
what
what's
the
standard?
I
can't
remember
it
you're
right
uri
template
yeah,
but
then
the
question
becomes:
when
exactly
is
it
slash
as
like,
it
shouldn't
be
converted
to
dot,
because
from
from
the
nas
point
of
view,
I
was
like
okay,
so
I
just
replaced
all
of
the
slashes
with
dots
and
like
in
the
code
generation,
and
then
the
channels
or
the
topics
would
be
compliant
with
nets.
C
A
C
B
No,
I
was
saying
that
in
in
fact,
in
in
the
documentation
we
say
that
they
are
explicitly
paths
and
are
relatives
to
the
server.
So
it's
like
there
is
no
other
way
to
declare
right
now.
Sorry,
that's
my
my
daughter.
There's
no
way
to
declare
actually,
for
example,
a
rabbitmq
topic,
like
you
say,
the
user.sagna.
A
C
I
think
this
is
coming
from
open
api,
probably
yeah.
This
is
misleading,
because
relative
here
might
mean
there
is
a
relative
url
right
or
it's
relative,
meaning
that
it's
a
channel
that
exists
in
this
server
right,
but
but
yeah.
This
is
misleading
so
because
we're
talking
about
paths
that
look
like
urls
so
but
they're,
not
urls,
so
pads
are
sorry
channels
are
not
urls.
C
Oh,
it
depends
on
the
protocol
yeah.
It
depends
on
the
protocol
of,
of
course,
but
by
definition
they're,
not
urls,
even
though
they
they
follow
the
uri
template,
because
I
thought
it
was
a
good
idea
that
we
follow
an
existing
one,
an
existing
standard
but
yeah.
It's
it's
creating
more
problems
than
solutions,
so
so
yeah.
My
other
idea
I'll.
I
have
to
work
on
the
new
channels.
Object,
so
I'll
propose
solutions
for
that.
But
my
other
idea
is
that
we
explore
regular
expressions.
B
C
C
C
So
we
we've
yeah,
we
fixed
this
problem
forever,
like
with
the
publish
and
subscribe
confusion
as
well,
and
that's
it
it's
not
a
problem
to
anyone,
because
in
the
end,
it's
not
a
problem
to
anyone
because
we're
not
respecting
we're,
not
respecting
this
picking
any
tool
so
we're
just
throwing
the
channel
name
there
with
slashes
or
whatever
you
put
there,
and
we
allow
people
to
use.
C
C
C
Yeah
or
maybe
it's
valid,
but
it
doesn't
mean
what
we
think
it
means,
but
if
it's
not,
it's
not
gonna
fail
anyway,
because
we're
not
validating
it.
A
Next
time
I
will
I
need
to
get
an
overview
of
like
where
we
are
with
all
of
the
features,
because
I
have
no
idea
at
the
moment,
also
in
terms
of
the
parser
and
what
has
been
like
what
is
ready,
like
the
changes
that
you're
doing
around
the
pops
up,
confusion,
etc.
I
have
I
have
a
tiny
bit
idea
about
the
state
you're
in,
but
it's
I
would
love
to
get
an
update
there,
if
possible
or
if
I
can
find
out,
what's
happening
but
yeah.
Let's
do
that
next
time.
A
I
think
that
would
make
sense.
Everyone
is
probably
back
from
holiday
at
that
point.
So
get
a
a
good
overview
of
what's
missing
what
needs
to
be
done
and
what's
left
or
that's
the
same
thing
but
yeah.
You
know
what
I
mean.
C
I'm
just
testing
a
uri
template
online
editor
and
it
seems
to
work
with
my
last
example.
So
maybe
I'm
wrong
and
it's
allowed
so
yeah.