►
From YouTube: CNCF Serverless Working Group 2020-12-3
Description
CNCF Serverless Working Group 2020-12-3
A
D
E
F
A
D
A
G
B
A
A
C
A
A
I
can't
remember
there
was
one
person
on
last
week's
call
who
I
did
not
get
their
company
association
just
for
fun,
simon,
who
are
you
with.
A
I
was
going
to
say
sap,
it's
okay,
I
don't
think
it
was.
You,
though
I
think
it
was
someone
else.
Mister.
A
G
A
G
A
A
G
C
A
So
for
you
guys
in
germany
last
time
we
mentioned
the
virus
stuff,
I
was
hearing
that
things
were
getting
better,
but
now
I'm
am
I
hearing
things
right
that
things
are
ramping
back
up
again
and
if
so,
are
you
guys
doing
lockdowns
or
how
are
you
guys
dealing
with
it.
E
People
are
being
stupid
and
we
have
a
partial,
I
would
say
a
partial
lockdown.
There's
no
restaurants
are
not
open,
and
you
know
the
the
the
all
the
services
close
to
the
body,
except
for
hairdressers
at
the
clothes
and
so
we're
similar
we're
a
similar
place
to
where
we
were
in
the
spring,
except
that
the
shops
are
open,
got.
A
A
All
right,
let's
get
into
this
anything
from
the
community,
people
want
to
bring
up.
A
All
right
not
hearing
any,
we
do
have
an
sdk
call
immediately
following
this
one.
As
of
right
now,
I
believe
we
do
have
one
item
on
the
agenda,
so
we
are
planning
having
the
call
assuming
lance
shows
up.
Oh
and
there's
lance
okay,
we
had
the
discovery
call
of
next
week.
I
remember
if
we
had
anything
worth
mentioning
from
last
week's
call,
although
I
don't
think
we
really
had
much
of
a
discussion
other
than
I
do
want
to
ask.
A
I
know
who's
been
joined,
the
call
so
I
know
who
to
who's
been
kind
of
working
on
stuff.
For
example,
I
know
scott
you're,
there
remy
you've
been
working
on
stuff,
but
there
were
people
in
the
past.
I
think
clemens
you
may
have
mentioned
it,
and
I
think
I
want
to
guess
it.
Klaus
sap
may
have
mentioned
you
guys
were
interested
in
it.
Has
there
been
any
progress?
E
A
C
A
A
Okay,
in
that
case
please,
well
I
went
around
hey
dog.
Yes,
it's
lou
here,
yep,
hey
sorry!
I
don't
know
why
I
did
a
copy
or
cut
and
then
it
didn't
put
on
my
clipboard
okay,
I
was
gonna,
say
oh
yeah,.
A
Okay,
all
right.
Let's
move
forward
tumor
anything
you
want
to
mention
from
the
workflow
side
of
things.
B
Hey,
hey
guys,
not
much
just
real
quick.
Just
from
the
specification
side,
we
are
currently
working
on
adding
compensation
to
the
whirlpool
language
and
yeah.
That's
about
it!
So
I
just
didn't
wanna.
Are
you
guys
going
to
participate
in
kubecon,
eu
or
any
planning?
Because
I
think
there's
a
week
left
to
submit
talks.
A
So
I
was
assuming
that
we
would,
as
a
group
would
participate,
but
that
is
a
good
reminder
for
the
normal
cfps
there's
one
more
week.
Yes,
but
I
don't,
I
don't
think
we
need
to
do
anything
from
a
working
group
perspective.
I
think
they'll
reach
out
to
us
separately,
for
that
I
assume
anyway
thanks,
but
that's
a
good
reminder,
though,
for
kubecon,
so
any
questions
about
workflow
from
the
group
all
right.
A
In
that
case,
let's
move
on
to
the
next
gen
item,
so
we
started
a
vote
at
the
end
of
last
week's
call
and
just
refresh
everybody's
memory.
We
made
the
default
branch
in
github,
be
the
current
release,
which,
as
of
right
now,
is
one
zero
zero
and
we
decided
to
rename
the
master
branch
to
something
else.
At
least
my
understanding
was.
A
We
were
doing
it
to
make
it
clear
to
people
coming
to
the
group
or
coming
to
the
repo
that
the
development
work
is
going
on
in
this
new
branch
name,
they're
going
to
come
up
with
and
master,
didn't
necessarily
convey
that
thought
process.
That's
why
I
think
we
came
up
with
dev
versus
next
as
the
two
options.
A
So
some
people
have
been
voting.
I
think
I
got
everybody.
Who's
mentioned
who's
made
a
comment
to
the
issue
itself,
but
let
me
just
go
ahead
and
quickly
run
through
the
list
here
to
see
if
anybody
wants
to
change
their
names
or
if
anybody
did
not
vote
who
wants
to
vote,
I
don't
see
kristoff
on
the
call.
I
don't
see
matt
brian.
Do
you
want
to
change
your
vote?
H
A
Dev
dev,
okay
ginger,
you
just
voted,
so
I
assume
you
don't
want
to
change
your
vote.
All
right,
correct
right
manuel!
I
don't
see
him.
A
A
A
Guy
dev,
okay,
sorry,
I
couldn't
hear
you
and
sanjay
is
not
on
the
call.
Okay,
let's
see
if
my
math
can
do
here,
one
two,
three,
four:
five,
six
correct
me:
if
I
get
this
wrong,
please
one
two,
three,
four:
four:
okay
did
anybody.
Did
I
mess
up
anywhere,
two
four
six,
eight
ten
ten
votes
total
adds
up
to
ten.
Okay.
A
Oh
remy
dev
means
it's
under
development,
remy
how's
that
okay,
so
we
have
a.
We
have
a
winner,
okay,
so
I'll
take
the
action
item
to
do
whatever
is
necessary
in
the
repo
or
the
docs
to
do
a
pr
or
whatever
to
change
it
to
dev.
I
think
it's
just
the
the
readmes
and
stuff
like
that
may
need
to
change,
I'm
not
sure
or
the
links
all
right
before
I
move
on
anything
else.
People
can
think
if
I
need
to
do
relative
to
the
vote.
A
Oh
sanjay,
okay,
it's
like
post
voting
yeah.
I
like
that.
I
feel
like
there's
something
illegal
about
that.
But,
okay,
let's
see
okay,
one
on
one
prep,
so
we
have
a
couple
of
prs
to
discuss
and
one
issue.
So
let's
go
ahead
and
jump
into
it.
I
think
on
this
one.
A
So
I
added
some
text
to
the
governance
doc
that
talks
about
how
we're
going
to
use
rc
number
meaning
release
candidate
number
four
for
when
specs
become
ready
for
review
for
the
next
revision,
and
I
think
that's
consistent
what
we
sort
of
operated
in
the
past.
A
But
then
we
also
talked
about
how
we
made
it
clear
that
the
spec
version
is
always
just
going
to
have
a
major
minor
version,
not
the
patch
version
number.
So,
for
example,
it
will
be
1.0,
not
1.01
in
the
spec
that
way
things
in
the
wire
don't
need
to
change
and
we're
always
going
to
keep
it
at
dot
zero
and
if
we
ever
do
introduce
a
breaking
change,
that's
going
to
cause
a
major
version
bump.
So
that's
why
I
can
always
stay
at
dot.
Zero.
A
Okay-
and
I
think
this-
this
is
just
text
in
the
spec
itself
that
talks
about
that.
But
I
think
those
are
the
only
changes
I've
made
just
to
clear
up
our
process.
So
let
people
understand
what
we're
going
to
be
doing
going
forward.
A
D
Yeah
and
sorry,
if
I
haven't,
you
know,
read
it
here:
it's
already
there
have
we
listed
what
are
the
breaking
changes
and
what
would
be
non-breaking
changes.
I
know
people
would
know
generally,
but
have
we
at
least
take
those
anywhere?
I.
A
Okay,
now
I
did
reach
out
to
jem
offline
to
ask
if
he
was
okay
with
moving
the
protobufs
back
back
to
one
101-rc1,
as
opposed
to
making
it
a
full-fledge
1.0,
because
it
never
had
a
chance
to
actually
go
through
a
testing
cycle,
and
I
think
we,
when
we
talked
about
this
in
the
past,
there
was
a
little
bit
of
concern
that
we
maybe
made
at
1.0
prematurely.
A
A
A
Now,
in
preparation
for
1-0,
I
did
send
out
a
note.
At
least
I
think
I
did
with
the
url
to
the
diff
between
what
we
have
today
at
head
versus
what
1.0
was,
and
I
asked
everybody
to
go
through
over
the
last
two
weeks
or
so
to
see
if
there
are
any
obvious,
typos
and
stuff
like
that,
that
we
got
wrong
now
lance
you
then
open
up
this
pr
is
there
anything
in
particular.
I'd
like
to
point
out
here
is,
I
think,
most
of
it
was
typographical
type
stuff.
I
A
A
Yeah,
I
don't
remember,
I
think
there
was
one
thing
I
did
want
to
point
out
to
people
okay,
so
here
this
isn't
normative
it's
just
in
the
proprietary
spec
readme
in
essence
right.
I
basically
made
these
things
to
must
just
to
make
it
clear
that
we
really
really
need
this
from
people
before
it
was
a
little
bit
loosey
by
saying,
needs
to
and
should
but,
as
I
said,
it's
non-normative,
but
I
think
our
intention
was
these.
Things
have
to
be
there.
So
I
think
that's
really
non
technical
kind
of
changes
you
made.
A
Okay,
this
was
just
it
made
it
easier
for
me
to
see
if
we
missed
files
in
the
ready
by
advertising
them
and
put
on
separate
lines.
It's
just
strictly
nonsense.
This
one
was
doing
a
relative
url
instead
of
an
absolute
url,
so
for
consistency
I
made
it
absolute,
just
like
all
the
others.
It
just
makes
it
easier
as
we
make
new
versions.
A
This
protobuf
was
the
only
one
that
was
doing
bookmarks,
so
I
removed
them
because
that
we
wanted
to
be
consistent,
otherwise,
we'll
mess
up.
We
were
mentioning
that
we
were
missing
the
php
in
the
sdk
dock,
even
though
the
php
repo
is
actually
empty.
I
thought
in
fairness.
We
should
at
least
point
to
it
because
we're
consistent
here,
the
governance
stock.
I
just
lowercased
things
like
may,
because
this
is
technically
non-normative
and
I
just
cleaned
up
some
references.
Oh
this.
This
comment
here
about
available
at
the
root
of
the
repository.
A
So
I
just
kind
of
tweaked
the
wording
there
slightly
to
make
it
clear
that
it's
each
sdk
may
define
in
their
own
contributing
file,
and,
let's
see
lower
case
of
may
here,
because
again,
this
is
a
governance
stock.
It's
not
normative
and
same
thing
here,
non-normative
these
more
non-normatives.
C
A
A
I
apologize,
I
didn't
realize
they're
outstanding
comments,
so
okay,
we'll
hold
off
on
that
one,
all
right,
okay,
so
in
this
issue,
okay,
klaus-
this
was
something
you
raised
a
while
ago.
A
So
since
we
didn't
hear
anything,
though
I
believe
the
next
step
is
to
check
if
people
are
okay
with
that
strategy
going
forward,
and
if
so,
we
can
then
close
713
and
assume
that
we're
okay
doing
a
zero
zero
one
release
and
not
worry
about
this
as
a
breaking
change
is
that
your
understanding
is
well
close?
Yes,
okay!
A
A
A
Anybody
have
a
preference,
okay,
I'm
not
hearing
anything.
What
I'd
like
to
propose
is
that
we
merge
the
pr's
we
just
approved
today
and
start
the
vote
on
one
zero.
One
I'll
have
to
go
back
refresh
my
memory
about
the
exact
process
we
follow.
I
was
in
terms
of
whether
I
actually
create
a
p.
I
think
I
create
a
pr
with
all
the
changes
to
bump
everything
up
to
101,
and
then
people
have
a
week
in
essence
to
vote
on
that
sound,
fair.
A
Type
approved
all
right,
excellent,
all
right,
yordis,
you
reached
out
to
me
saying
you
would
like
to
talk
to
the
group
about
this
proposal
that
you
have
for
an
extension.
F
Yes,
I'm
I'm
here
yeah,
so
basically.
F
Trying
to
you
know,
come
up
with
some
consensus
and
like
align
a
little
bit
the
ecosystem
and
how
to
like
generate
errors.
So
that
way,
you
know
it's
kind
of
like
the
same
goals
of
cloud
events.
So
you
you
get
you
gain
into
your
operability
and,
as
the
case
and
tooling
surround
it.
So
at
the
beginning
I
was
like
creating
my
own
cloud
events
and
then
I
realized
like.
Actually,
I
can
just
create
an
extension.
So
I
change
everything.
F
So
the
things
that
I
took
into
consideration
is
kind
of
like
how
you're
going
to
do
internationalization
in
clients
uniqueness
between
distributed
system
environment
for
there
how
you
could
correlate,
like
particular
tracing
of
an
error
back
to
customer
support,
so
we
could
even
expose
sometimes
metadata
to
the
clients
and
let
the
consumer,
the
users
to
help
themselves
with
customer
support
documenting,
maybe
some
structured
login.
If
you
want
to
log
there
and
for
clients
for
the
most
part
like
how
you
aggregate
validation
or
errors
that
happen
for
a
particular
key
in
a
validation
situation.
F
F
F
The
meat
I
just
introduced
a
new
type,
which
is
a
url.
I
don't
know
if
I
should
use
one
of
the
the
other
ones
that
we
have
already,
but
basically
that
would
be
where
the
documentation
is
gonna
leave.
So
everything
else
is
the
same:
only
you're
going
to
have
the
error
message,
which
is
for
the
most
part
for
developers,
so
some
people
may
use
it
in
clans
to
display
to
the
users.
I
wouldn't
recommend
it
so
that
is
introduced
and
then
there
are
links,
so
you
could
find
documentation
about
it.
A
F
I
think
above
you're
gonna
see
the
two
attributes
that
I
added.
So
I
have
a
section
there
says
extension
context
attribute,
so
those
two
are
the
only
ones
required
for
now
because
for
internationalization
you
would
normally
use
the
type
for
uniqueness.
You
already
have
the
source
plus
id,
so
you
could.
You
know,
correlate
that
for
metadata
around
like
a
like
an
error.
Let's
say
you
have
in
in
cases
where
you
need
to
have
more
context
in
order
for
international
eyes
or
add
more
information
about
particular.
You
use
the
data
for
now
so
yeah.
F
F
E
I
do
so.
This
is
something
that
I
refer
to
you
doug
as,
and
I
think
what
I
think,
the
initial
story,
or
how
this
started.
If
you
correct
me,
if
that's
wrong,
is
that
you
wanted
to
have
a
common
way
to
express
errors
as
if
error
events,
okay
and
so
and
and
effectively,
you
landed
on
cloud
events,
because
cloud
events
is
already
a
framework
that
kind
of
lets
you
express
most
of
that
error,
but
not
all
of
it.
E
The
content
of
the
the
event
per
se
so
put
that
into
the
data
section
and
what
because,
because
you're,
arguably
in
introducing
a
class
of
cloud
events
right,
you're,
not
changing
anything
that
all
cloud
events
should
be
able
to
use
that.
That
would
that's
what
makes
the
extension
would
be,
but
you're
introducing
a
class
of
cloud
events
that
are
expressing
errors.
E
So
what
I
would
so.
What
I
would
do
here
is,
I
would
define
a
scheme.
F
E
No
no
well
what
I'm!
What
I'm
saying
is
what
I'm
saying
is
that
you
should
write
a
rule
for
how
the
type
is
being
formulated,
how
the
type
field
is
being
how
how
the
type
field
ought
to
be
set
when
it
expresses
its
errors,
sure
and
how
the
source
field
ought
to
be
set
when
it
expresses
an
error
and
what
the
subject
should
say
when
it's
describing
an
error
and
then
I
would
also
make
a
json
schema.
E
That
then
makes
clear
what
should
go
into
the
data
field.
Okay,
if
it
expresses
an
error,
that's
how
I
would
approach
that,
because
you're
effectively,
what
you're
trying
to
do
here,
I
think,
is
you're,
defining
a
schema
that
sits
on
top
of
of
cloud
events
or
a
constraint
that
puts
that
sits
on
top
of
cloud
events,
because
you
want
to
make
sure
that
errors
can
be
distributed
in
the
system
you're
effectively
as
we
as
we
were
talking
about
it.
What
you're
trying
to
do?
E
Is
you
cr
you're,
trying
to
create
a
a
log
format
of
sorts?
That's
that's
carrying
cloud
events!
How
how
we
can
go
and
distribute
error
information,
error
errors
in
cloud
events,
so
I
would
not
use
that
as
using
extension,
because
that
mechanism
is
really
meant
to
be
applied
to
any
kind
of
cloud
event.
But
really
look
at
do
this
as
a
meta
scheme,
and
I
think
and
and
I
believe
what
you're
the
work
that
you're
doing.
The
idea
is
enormously
valuable.
E
Let's
let
just
just
to
make
that
clear,
yeah
and
because
having
errors
are
something
that
systems
need
to
go
and
react
to,
and
something
throws
an
error.
It's
basically
it.
What
you're
doing
is
the
you're
you're
defining
what
throws
local
looks
like
in
distributed
systems,
yep
right
right,
and
so
so
I
would
take
the.
I
would
take
a
bit
of
a
bit
a
different
approach,
but
don't
be
deterred,
you
should
go.
You
definitely
should
go
down
that
route.
Yep.
F
No,
no,
not
at
all,
I
I
this
was
something,
and
this
is
exactly
what
I
wanted
to
speak
to
you,
because
personally
I
don't
I
don't
mind,
if
is
an
extension
or
if
it's
a
convention
inside
the
data
and
then
add
the
two
keys
and
the
metadata
key,
which
it
will
behave
as
a
data
yeah.
For
me,
what
I
actually
looking
for
for
the
most
power
is
alignment
ecosystem,
so
we
just
can
move
on
to
the
next
conversation
related
to
this,
so
I'm
totally
cool
with
it.
E
E
And-
and
I
wanted
to
make
sure
that
we
have
this
discussion-
not
office,
not
offline
but
really
in
the
group,
and
because
I
think
this
contribution
is
important
and
as
you've
seen
there
were,
there
seems
to
be
interest
because
there
were
some
people
just
mentioning
engaged
in
the
chat.
But
if
say
people
say
plus
one
on
things,
then
they're
interested
in
having
these
having
this.
So
I
you
should
feel
encouraged.
D
Yep-
and
this
is
sanjay
just
like
you-
have
been
on
error
things
for
quite
some
time
more
from
the
http
api
perspective,
but
I'd
like
to
work
on
that.
I
think
it's
very
important.
The
schema
for
the
errors,
how
we
know
it
should
be
conveyed
and
if
cloud
event
can
have
you
know,
we
can
have
extensions
there
for
that.
So
definitely
very
interested
in
working
with
you.
A
Okay,
sorry,
I'm
just
taking
some
notes
here.
Okay,
so
I
think
what
I'm
hearing
is
in
general.
Well,
actually
I've
been
back
up.
Does
anybody
else
have
any
comments
or
questions?
A
Okay,
because
I
think
I'm
hearing
in
some
plus
ones
is
like
the
idea
of
looking
at
some
sort
of
standard
or
recommendation
or
guidance,
or
do
you
want
to
call
it
around
how
errors
are
manifested
themselves
in
cloud
events,
but
would
rather
see
it
by
using
the
existing
fields
as
opposed
to
creating
new
extension
fields?
Does
that
summarize,
it.
J
Because
that's
what
I
tried
to
say
in
here,
I
think
that's
that's
what
I
certainly
what
I
want
to
express.
Yep,
okay,.
F
Go
I
I
understand
where
to
go
with
changing
the
spec.
I
think
I
totally
agree
with
with
them
I'm
guessing.
I
should
create
like
a
pull
request
against
a
spec
and
that's
where
I'm
not
really.
I
I
don't
know
what
would
be
the
next
step
in
terms
of
like
start,
the
contribution
with
cloud
event
for
sure.
A
Yeah,
I
think,
actually
you're
right
on
the
money
there.
It's
create
a
pull
request
with
where
you
think
the
changes
need
to
go
and
that
will
force
people
to
review
it
and
comment.
Obviously,
if
there
are
certain
people,
for
example,
sanjay
said
he'd
like
to
work
with
you,
you
know
through
the
chat
yep.
If
there
are
certain
people,
you'd
like
to
reach
out
to
in
advance
of
creating
the
pr
just
to
see
whether
you're
headed
in
a
direction.
E
No,
no,
no!
No!
We
have
this.
We
have
this
directory.
I
I'm
just
too
lazy
to
look
it
up.
Maybe
the
where
we
had
the
these
github,
how
the
github
events
look.
E
E
A
A
A
A
All
right,
so
you
know
where
to
go
next,
then
excellent.
Thank
you,
yep
thanks.
Thank
you
for
the
proposal.
This
is
this
is
exciting
all
right,
other
pr's
and
issues
then
clements,
I'm
assuming
there's
nothing
to
do
there
for
yours
right.
Yes,
sir,
okay
and
slinky.
Is
there
anything
you
want
to
talk
about
relative
to
your
pr?
I
think
this
one's
yours
right.
K
I
was
waiting
for
clements
to
to
comment
in
there
right
excellent,
more
more
finger
pointing
at
clemens,
okay,.
E
A
Okay,
not
a
problem,
no
problems;
okay,
I'm
trying
to
think
of
anything
else.
I
think
that
technically
takes
us
to
the
end
of
the
agenda.
Are
there
any
other
topics?
People
like
to
bring.
G
A
K
Yes,
yes,
so
so
last
time
we
basically
forgot
to
discuss
about
it,
but
I
was
wondering
if
we,
if
the
community
is
interested
in
developing
a
kind
of
expression,
language
to
express
predicates
on
cloud
events.
K
K
A
E
K
K
There
are
really
really
just
a
bunch
of
languages
that
that,
as
implementations
for
like
most
of
programming
languages
out
there,
so
that's
one
of
the
reasons
why
I
came
up
with
trying
to
define
something
new,
but
nothing
new.
L
Also,
maybe
a
short
answer
is
the
german
model
is
not
the
same
right.
We're
talking
about
the
cloud
event
that
I
model
here
not
like
a
relational
and
and
francisco.
I
don't
know
if
you
said
this,
but
this
is
a
language
only
to
talk
to
to
express
predicates
on
the
on
the
ce
attributes,
not
on
the
payload.
K
Yeah,
it's
it's
very.
It's
very,
very
constrained
to
cloud
events
itself
so
like
one
of
the
first
things
that
is
explained
in
this
document
is
that
the
input
assumes
that
you
get
a
you
are
the
input
assumes
that
you
are
getting
a
call
event,
so
that's
like
the
the
biggest
assumption
on
it
and
like
the
and
like
the
language
can
do
even
type
static
tab.
Checking
on
some
on
the
code
event
attributes.
E
So
the
reason
why
I'm
saying
that
is
there's
there
is
precedent
in
in
broker
land
in
the
form
of
java
jms
message,
selectors,
which
are
using
sql,
sql
92
subset,
and
we
also
have
in
mqp
a
very
similar
sql
subset.
E
And
so,
when
you
look
at
message
brokers,
every
message
broker
that
supports
jms
already
implements
a
sql,
parser
and
mapping.
A
cloud
event
to
one
of
those
brokers
is
something
that
we
have
effectively
so
for
mpp.
We
have
already
done
the
work,
so
it
seemed
it
would
be.
E
I
I
think
if
we
want
to
go
and
implement
an
expression
in
language
like
this,
using
one
of
those
already
existing
specs
is
something
I
would
prefer
over
introducing
yet
another
thing
which
is
completely
its
own.
The
advantage
of
using
sql
1992
subset
is
that
it
is
footing
on
a
standard
so
and,
and-
and
the
message
selectors
in
gms
do
know
also
are
constrained
to
the
shape
of
the
gms
message
and
the
mdp
message.
A
B
Oh
well,
I
mean
I,
I
know
I
don't
well.
I
don't
want
to
say
anything
bad.
I
think
I'm
just
seeing
this
the
first
time
it
looks
really
nice,
but
I
just
know
from
experience
that
is
like
with
expression
languages
when
there's
so
many
out
there,
and
especially
like
I,
just
can
compare
to
workflow
stuff
that
we're
doing
we
removed
actually
ability
to
select,
like
things
like
a
specific
expression
language,
because
that's
portability
just
goes
away.
B
B
K
So
I
I
have
a
specific
answer
to
to
the
jsonpath
thing
and
in
general
to
the
json
query
languages,
because
I
honestly
tried
to
look
at
this
first
and
one
of
the
problems
of
those
languages
is
that
they
don't
handle
very
well.
K
Complex
types
like
the
timestamp
so
like
performing
performing
a
particular
developing
particular
predicates
on
timestamps
or
on
your
eyes.
So
that's
that's
one
of
the
reasons
why
I
I
think
jsonput
doesn't
really
fit
there,
also
because
in
general,
jsonpath
is
really
nice
to
to
navigate
through
nested
data
structures.
But
it's
not
really.
K
I
mean
I,
I
see
it
as
too
much
verbose
when
you
need
to
just
work
through
a
a
data
structure
which
is
flat
luck
in
this
case.
Oh
well,
I
didn't
set
something
important
in
this
expression:
language.
We
explicitly
neglect
the
the
payload
filtering,
so
we
don't
talk
about
pedal
filtering
and
we
don't
want
to
do
pedal.
A
Okay,
so
my
hands
up:
okay,
so
first
notice
clemens
pasted
a
link
to
the
amqp
stuff
that
he
was
talking
about
in
the
chat.
You
take
a
look
at
that
I'll.
Add
that
to
the
meeting
minutes.
E
The
document
that
languages
make
one
annotation
that
document
is
is
affecting
the
final
spec.
We
haven't
progressed
this
in
the
committee
yet
because
we're
slow,
but
that's
that's
effectively
the
final
one
that
we're
going
to
promote.
A
A
It's
the
aqp
thing
or
sql
or
whatever
I'm,
assuming
that
we
would
profile
it
right
to
limit
limit
it
down
to
what
cloud
events
actually
needs,
because
I
would
imagine
most
of
these
other
languages
are
far
are
fairly
robust
and
probably
much
bigger
than
what
we'd
need
for
our
basic
filtering
type
stuff.
Is
that
true,
or
or
when
you
say
no
sql,
you
actually
mean
clemens.
We
should
support
as
much
as
the
sql
thing
as
we
possibly
can.
E
No,
no!
No!
No!
No!
What
what
if
you
look
at
if
you
look
at
so
the
other
spec
is,
would
be
the
jms
2.0
specification
that
is
in
so
java
message:
service,
2.0!
That's
the
specification
you
can
find
that
at
oracle
and
that
ex
that
has
a
fairly
compact
definition,
probably
a
little
bit
more
compact
than
the
definition
I
have
in
aqp,
which
effectively
takes
a
subset
of
the
sql
standard.
E
Just
so
much
that
you
can
create
meaningful
queries
over
the
properties
of
a
message
and
and
combine
them
with
with
effectively
constants
that
you
that
you
provide.
So
it's
a
it's
a
fairly
slim
subset
and
it's
effectively
the
subset
you
would
put
into
the
where
clause
of
a
of
a
sql
expression
rather
than
you
know,
doing
the
select
and
group
by
and
like
none
of
those
things
exist
like
literally
just
the
where
clause
conditions,
those
you
can
formulate
that's
what
that
subset
is
so
the
gms2
spec
and
the
spected.
E
I
that
I
tasted
would
be
informative
for
that,
and
that's
that
is
what's
common
in
in
messaging
lands,
okay,
okay
and
so
active
mq,
cupid,
rabbit,
ibm
mq,
the
sap
brokers,
I'm
sure,
are
also
implement
the
same
thing:
our
brokers,
our
service
bus
broker,
implements
and
all
of
those
are
implementing
some
some
some
subset
of
sql.
L
Yeah
so
for
the
cloud
event
filter
language,
it
seems
to
me
that
we
need
a
even
smaller
language,
so
I'm
looking
at
the
filter
at
the
link
you
sent
like,
for
instance,
you
have
the
the
the
map
and
the
list
type
right.
That's
not
something
that
I
think
belongs
to
to
the
filter
language
here,
for
instance,
but
we
could
take
a
subset
of
it.
E
Yeah
yeah,
absolutely
it's
it's
I'm
I
mean
I
just
gave
you
the
link
for
the
mp4
for
for
what
we
need
for
mkp
and
this
that
can
be
further
cut
down,
but
the
the
the
point
is
I
from
from
from
from
my
perspective,
as
you
know,
trying
to
unify
the
world
of
messaging,
I
would
like
to
have
everybody
speak
sql
and
then
there's
obviously
some
some
variation
of
of
of
sql
that
we
speak,
but
I
don't
want
to
introduce
entirely
new
languages
for
doing
that.
Filtering.
E
Yeah
that
and
that's
that's
that's
the
choice
that
we
made
for
mkp.
That's
the
choice,
what
the
jms
the
gms
folks
did-
and
the
reason
is
that,
even
though
we
had
a
we
had
a
period
of
time
when
we
were
believing
that
no
sequel
would
be
great
so
doing
away
with
sql
everybody
who
has
been
doing
no
sql
is
now
back
to
sql.
So
apparently,
sql
is
still
winning.
K
I
need
to
read
what
what
clients
you
just
said,
because
it
seems
interesting.
I
need
to
go
through
it.
I
have
some
questions.
Maybe
they
are
in
the
stuff.
Maybe
they
are
not,
but
like
one
of
the
things
that
I
thought
about
when
writing
down
the
stock
is,
is
the
polymorphism
of
the
of
the
extension
attributes.
So
the
fact
that
the
extension
attributes
are
we
we
don't,
we
don't
have
a
strict
schema.
So
when
I
think
to
sql,
I
think
to
do
something
that
always
has
a
strict
schema.
K
The
input,
the
input,
then
every
field
of
the
input
is
styled.
Okay,
and
my
question
is
how
does
in
your
case,
how
did
you,
how
do
you
deal
with
with
situations
where
the
input
where
some
fields
of
the
input
are
not
typed
so
but
some
fields
of
the
input
on
there.
E
There
are
there's
a
whole
section
about
conversion
rules.
Okay,
all
right-
and
that's
that
is
that
was
the
the
those
are
the
hardest.
Those
were
the
hardest
pieces
to
write.
There
was
like
I
I
came.
E
I
the
amqp
tagging
committee
is
unfortunately
full
of
hawks
for
correctness,
which
means
I
came
in
with
a
proposal
that
was
kind
of
like
at
the
level
where
you
are
and
then
they
were
all
like.
No,
no,
no,
no,
no.
E
We
have
to
go
and
think
about
all
the
conversion,
rules
and
type,
mappings,
etc,
because
ultimately
you're
expressing
you're
expressing
text
here
and
that
all
needs
to
be
mapped
and
there's
some
type
inference
rules
etc.
So
just
look
at
the
look
at
the
document.
There
was
a
I.
I
have
purged
much
of
that
out
of
my
head
already,
because
it's
it
was.
It
was
not
pleasant
to
write
at
all.
E
Effectively
for
you,
the
just
as
as
hell
as
as
has
helped
for
reference,
there
is
some.
There
are
some
property
bags
that
you
can
reference
like:
the
application
properties
and
the
properties
etc,
and
that's
kind
of
you
can.
You
can
think
of
those
as
being
kind
of
the
the
areas
where
you
can
go
and
swap
the
predefined
cloud
events
and
extensions
in
that,
so
you
can
kind
of
re,
read
them
like
that.
E
A
G
I
have
one
quick
question:
yes,
please
good.
Regarding
one
zero
one
release,
is
there
a
change
log
where
we
can
quite
quickly
and
see?
What's?
What's
you
know.
A
So
I
sent
out,
I
sent
out
a
note
with
the
url
that
did
the
get
diff
between
the
latest
versus
one.
Oh,
that
go
look
for
that
email
when
we,
when
we
create
the
one
the
next
version.
I'm
sorry
when
we
create
the
next
release,
I
think
somewhere
in
the
the
documentation
talks
about
the
process.
I
think
it
does
talk
about
creating
a
change
log
that
goes
into
the
pr
itself.
I
don't
think
we
actually
create
a
formal
changelog
document,
but
I'll
have
to
go
back
and
double
check.
F
Yeah
one
thing
based
on
this
flow
today
I
was
trying
to
see
if
I
missed
it,
but
it
would
be
good
to
talk
about
like
contributing
to
extension
and
adapters
and
the
difference
between
them.
I
don't
know
if
that's
documented
or
not,
but
I
definitely
miss
it.
E
I
think
I
think
what
you're
bringing
is
is
generally
a
new
thing
yeah,
and
so
I
I
don't.
I
don't
think
any.
I
don't
think
anybody
has
brought
a
effectively
a
class
of
of
cloud
event
schemas
and
that's
that's
ultimately
what
you're
doing
so.
I
I
think
we
have
a.
I
don't
think
there
are
a
slot
for
it,
but
since
you
want
to
bring
a
pr,
the
adapters
section
would
be
the
best
slot
and
we
can
still
think
what
how
we
can
think
about
the
whether
we
want
to
have
these.
E
It's
probably
a
meta
schema
that
you're
that
you're
a
cloud
event
meta
schema
that
you're
defining
and
then
we
probably
need
to
go
and
find
the
right
home
for
it.
But
but
before
we
deal
with
informing
formalities,
let's
let's
get
the
get.
Let's
get
the
proposal
done
first
and
then
we
can
go
and
see
how
we
slot
it.
A
A
F
A
Have
to
drop
off
a
bit
early
for
a
conflict.
Oh
is
he
from
red
hat
he's
from
google
he's
google,
okay
cool!
Do
you
know
his
last
name
by
the
way
lance
or
is
that
not?
This
is
brian,
brian,
sorry,
brian?
How
how
ling,
l
ing
perfect?
Thank
you
very
much
all
right.
Anybody
else
that
I
missed
for
roll
call.
A
I
think
I
got
everybody
all
right
in
that
case.
Thank
you.
Everybody.
We
will
have
the
sdk
call
out
to
this.
As
I
said,
lance
had
released
one
topic
on
there,
so
if
you're
not
interested
in
sdk
call,
thank
you
all
for
joining
very
productive
meeting.
We'll
talk
again
next
week.
Everybody
else
hang
on
for
about
a
minute
thanks.
Everybody.
C
C
I
Yeah
I
mean
I
think
this
has
been
talked
about
before,
but
maybe
preceded
my
participation
in
this
group.
I
was
looking
at
the
distributor.
There
was
a
an
issue
opened
on
the
javascript
sdk
asking
for
us
to
support
the
distributed
tracing
extension
and
reading
through
that
that
spec
to
me
it
seems
like
if
the
sdk
supports
extensions
in
the
abstract,
then
it
automatically
supports
the
distributed
tracing
extension.
I
But
it's
not
entirely
clear
to
me
because
obviously,
the
go
sdk
is
doing
something
quite
a
bit
more
than
just
like
supporting
the
extension
by
having
it
be
possible
on
an
event,
you
see
what
I'm
saying:
yeah.
E
We
have
been,
we
have
been
discussing
this,
the
the
topic
of
the
distributed
tracing
extension
to
the
point
that
dog
at
some
point
said:
let's
throw
this
out
the
so
you're
correct.
This
retracing
extension
is
an
end-to-end
extension
which
we
have
there
to
effectively
allow
for
a
a
tracing
context
to
be
carried
from
the
application
to
the
application.
I
H
E
Then,
when
you
send
the
cloud
events,
so
when
you
kind
of
pop
down
onto
onto
the
transport
level,
then
the
transport
like
the
h,
like
http,
also
has
these
distributed.
These
trace
extensions.
So
there's
the
the
same
properties
effectively
exist
defined
in
the
in
the
w3c
stack
as
http
headers,
which
makes
the.
H
Whole
thing
a
little
bit
confusing
to
me:
why
do
you
need
both
yeah
so
because
the
cloud
event
goes
into.
E
A
broker
into
some
some
event
broker
and
then
pops
out
again
somewhere
else.
The
application,
the
application,
which
is
the
consumer
of
that
event,
maybe
wants
to
write
a
trace.
That
is,
then,
that
is,
shall
then
be
correlated
with
the
publishing
action
that
happens
on
the
other
side,
but
without
without
having
to
worry
about
any
of
the
transport
stuff
that
sits
in
the
middle.
E
E
There
is
so
there
are,
you
think
you
can
think
of
those
as
two
separate
paths:
there's
a
path
that
goes
from
the
publisher
to
the
consumer,
application
to
application,
really
not
interested
in
how
that
communication
path
happens,
and
maybe
even
without
both
either
consumer
or
publisher
having
to
be
or
shall
it
should
be
in
the
know
of
how
that
happens
because
think
of
it
as
like,
if
you're
so
I
run
after
event
grid,
so
you
publish
into
azure
event
grid
and
then
the
message
comes
out
of
azure
event
grid.
E
But
you
don't
get
to
see
any
of
that,
and
you
don't
have
to
worry
about
any
of
that.
But
I
should
I
should
please
preserve
the
original
trace
context
from
the
publisher,
so
you
on
your
side
and
you're
up
on
the
application,
can
go
and
knit
those
two
things
together,
irrespective
of
all
the
stuff
that
I
have
done
to
get
that
event
to
you,
so
those
are
two
completely
different
worlds
and
and
for
the
application
applications
application
route.
That
is
what
the
extension
is
for.
I
Okay,
that
makes
sense
and-
and
it
makes
my
life
easy
to
say
that
okay,
we
support
extension.
So
we
support.
E
Wrote
that
suggestion
the
right
answer
is
use
the
same
values
for
the
cloud
event
and
for
http.
E
So
they
have
the
the
the
trace
parent
trace
context.
They
have
those
two
values
and
they
they
should.
They
should
use
those
and
they
they
start
with
them
right
they
set
them,
and
so
they
can
set
the
same
values
on
the
on
the
event
and
on
http,
but
they
basically
those
those
those
two
contacts,
basically
then
split
and
go
into
different
directions.
One
is
end
to
end,
and
one
is
really
just
from
the
client
to
the
http
server
and
stops
there
right.
K
K
Yeah,
I
mean-
and
the
second
thing
is
that
fyi
lens
I'm
working
on
removing
what
we
have
in
sdk,
because
I
think
it's
just
plain
wrong
and
too
much
opinionated
so
like
we
have
this,
this
integration
with
open
chances
which
which,
by
the
way
it's
a
deprecated
library
and
this
integration,
is
doing
some
funky
stuff,
it's
basically
taking
creating
a
new
span,
which
then
is
it's
sent
when
you
send
a
message
and
it's
taking
some
attributes
of
the
cloud
event
and
put
in
the
span
and
then
what
it
does
is
that
it
sets
the
the
value
of
the
distributed
tracing
extension,
okay,
but
then,
when
it
receives
the
event,
it
reads
those
values
and
that's
wrong
because
of
what
clarence
just
said
that
he
me
setting
this.
K
A
I
No,
I
I
I
think
I
understand
that
okay
and
we
have
that
I
was
just
trying
to
like
it
seems
to
me
in
reading
the
spec
that
well
we
support
extensions
in
the
abstract.
So
we
support
this
already,
but
it
wasn't
really
clear
from
reading
the
spec,
whether
that
was
the
case.
Okay
got
it.