►
From YouTube: 2023-02-15 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
B
B
Technically
this
can
be
matched
right
already.
There
was
another
proposal
to
call
it
logs
producer,
API,
I,
I'm,
not
sure
about
that
name.
B
C
I
loved
my
opinion
on
the
on
the
pr
in
case
folks
haven't
seen
it
I,
do
not
think
it's
a
better
name.
I
think
it's
more
likely
to
be
confused
as
something
that
should
be
used
by
end
users
than
a
bridged.
Api
would
be
so
I
prefer
Bridge
API.
D
Yeah
I'm
pretty
much
at
the
same
camp
as
that,
while
I'm
not
completely
100
fond
of
bridge
I,
think
it's
better
than
service
and
better
than
producing
so.
B
D
Yeah
so
Santosh
added
this
to
the
being
back
on
February
1st.
He
had
a
typo
in
it.
I
picked
the
typo
this
morning,
I
think
it's
actually
related
to
yours
as
well,
tiggering,
so
2994,
where
you're
talking
about
collapsing
event,
domain
and
name
so
because
that
would
then
change
the
shape.
So,
instead
of
an
event
being
named
domain
and
data,
it
would
just
be
named
so
I
I
guess
we.
These
are
linked
and
we
just
need
to
come
up
with
a
solution.
B
D
Yeah
I
think
I
talk
about
yeah
I
talk
about
the
combination
of
name
domain
and
data,
so
would
represent
it.
So
if
we,
if
we're
going
to
collapse
or
concatenate
domain
and
name,
then
there's
a
minor
object,
I
need
to
do.
B
I
see
I,
see
yeah
I
get
okay,
got
it:
okay,
okay,.
B
Yeah
I've
been
personally
focused
on
making
the
logs
API
stable,
so
I
haven't
had
time
to
look
into
this
more
closely.
If
others
have
any
thoughts
on
this.
A
C
Really
quickly
on
this
this
event,
data
so
I,
know
there's
some
conversation
about
using
the
log
body
instead
of
event.
Data
and
now
that
looks
like
you,
updated
the
pr
to
include
an
explanation
for
why
a
dedicated
attribute
field
is
more
appropriate
than
body,
and
that
explanation
is
based
on
the
idea
that
span
events
are
like
another
type
of
events
that
these
semantic
inventions
would
apply
to
yep
and
so
I.
C
Guess,
if
that's
the
case,
then,
if,
if
we
really
do
intend
this
event,
data
to
apply
not
just
to
you
know
the
the
log
record,
events
that
are
going
to
be
emitted
by
the
event
API,
but
also
to
span
events
from
the
trace.
Api,
then
I
think
that
this
is
blocked
on
the
the
pr
that
allows
or
adds
support
for
complex
attribute
types.
D
Not
necessarily
so
so.
This
is
specifically
around
logs.
While
we
would
like
span
events
to
have
it,
we
could
Define
a
mapping
in
terms
of
how
does
a
log
event
get
represented
in
a
span
event.
Our
initial
thoughts
were,
we
was
we'd
just
say
that
the
event
data
in
a
span
event
would
be
a
serialized
Json
wob.
D
If
tigrans
proposal
gets
through,
then
we
have
a
one-to-one
mapping
and
that
would
be
perfect,
but
we
haven't
gone
and
defined
what
that,
how
that
mapping
would
look
yet
or
even
if
it's
needed,
we
believe
it
will
be
needed,
but
as
the
romsig
we're
not
focusing
on
that
at
this
point,
but
we
wanted
a
path
forward
to
say
if
we
Define
an
event
and
for
some
reason
a
an
environment
only
wanted
to
have
the
trace
API,
but
they
still
want
to
do
with
events.
B
I
think
I
think
he
I'm
with
Jack
on
this
one.
Your
argument
would
be
much
stronger
right
if
we
actually
had
a
way
to
record
event
updating
the
span
event.
You
could
then
use
that
argument
in
favor
of
saying.
Okay,
that's
why
we
need
the
laptop
data
right,
so
it
would
help
right
to
convince
that
it's
a
good
idea.
Yeah.
B
Yeah,
if
it's,
if
it's
it's,
not
happening,
if
it's
never
going
to
happen,
the
ability
to
have
nested
attributes
and
all
that
stuff
so
that
they
then
it
can
be
also
recorded
in
events
of
a
span.
Then
I.
Guess
then,
if
it's
that
that
means
it's
ever,
it's
only
ever
going
to
be
recorded
in
log
records.
Then
then,
why
not
body
right
so
that
that
objection,
I
guess,
becomes
kind
of
more
more
more
reasonable.
In
that
case,
yeah.
D
B
D
B
D
B
Let's
consider
we're
discussing
this,
the
alternate
approach
would
be
to
our
body
to
spun
event
and
at
some
point
we
discussed
this
as
well.
There
is
even
an
open
issue,
I,
but
I.
Don't
think
that's
a
very
good
idea
to
be
honest
because
on
the
span
event,
we
still
have
the
name
and
it
will
be
difficult
to
explain
what
goes
into
the
name
and
what
goes
into
the
body.
I
am
not
so
sure
about
this.
D
Yeah,
if
we,
if
you
put
it
in
the
body,
then
we
probably
also
want
to
introduce
the
schema
so
that
third
parties
could
have
their
own
definition
so,
which
I
think
there
was.
Someone
left
a
comment
related
to
that.
Where
is
it.
D
D
B
B
C
And
now
I
have
another
question
about
this
PR
that
I
think
you
know
I've
been
struggling
to
articulate
I
guess
my
reservations
about
this,
but
I'll
take
a
stab
at
it.
So
if
I'm,
a
user
following
the
event
API-
and
you
know,
we
can
look
forward
to
the
event
API
having
some
surface
area
for
event
data.
So
maybe
you
can
include.
D
C
Payload
via
event
data
and
there's
a
dedicated
argument
or
before
that,
all
right.
So
that's
what
we
anticipate.
D
So
it
would
depend
on
so
I
think
you
call
the
event
you're
creating
so
the
page
of
your
event.
So
as
part
of
the
page
build
that
we
say
well
browser
page
view,
we
expected
the
data
to
contain
these
fields.
You
know
whether
they're
required
or
optional.
So
that
would
be
what
you
would
put
in
the
data
field.
D
Anything
else
would
go
in
perfectly
the
third
argument,
which
is
other
attributes
so
effectively
what
I
mean
by
that
is
we're
revisiting
an
emit
function
which
would
take
the
name,
the
data
and
then
additional
attributes.
So
if
you've
got
you
know,
custom
attributes
that
you
want
for
your
own
application,
which
I
have
for
application
insights
and
our
internal
1DS.
D
We
let
the
application
pass
in
additional
attributes
against
the
events
we
haven't
defined
from
the
shape
of
the
event,
whether
we're
going
to
call
that
a
specific
attribute
which
says
user
events.
We've
talked
about
it
several
times,
but
we've
never
come
to
a
conclusion.
But
at
this
point
it
is
just
the
case.
It
would
say
you
can
go
put
your
attributes
following
the
semantic
conventions
into
it.
If
you
want
to
pass
them
along.
C
So
then,
you
know
looking
forward.
We'd
have
semantic
conventions
where
we
Define
the
bodies
for
various
types
of
events
and
what
Fields
need
to
be
included
in
those
bodies,
and
then
users
can
include
event,
data
that
matches
those
conventions
and
attributes
that
are,
you
know,
other
things
that
that
are
related.
C
I
guess
like
so
what
what
about,
if
you're,
what
about,
if
you're
a
user
that
isn't,
is
emitting
custom
events
that
don't
have
anything
to
do
with
the
semantic
inventions
so
like
when
do
I
make
a
decision?
The
decision
to
put
something.
So
all
the
data
is
custom.
It's
not
just
custom
attributes
when
do
I
make
the
decision
to
put
that.
In
the
the
event
data
versus
just
attributes.
D
If
you're
meeting
your
own
custom
events,
are
you
saying
you
met
my
custom
event
depending
on
how
your
back
end
deals
with
that?
I
would
say:
you'd
put
it
all
in
data
and
you
wouldn't
put
any
in
attributes.
D
Okay,
it
depends
on
the
back
end
you're
talking
to
and
what
you
want
to
go.
You
may
have
situations
where
there
are
some
general
semantic
conventions
that
you
want
to
always
pass
and
it
would
make
sense
to
put
those
in
to
normal
attributes
rather
than
the
data,
because
the
the
data
represents
affecting
the
payload
of
the
event
detail.
C
So
I
yeah,
so
one
other
thing
that's
coming
to
mind
as
we're
talking
is
like
what
happens.
If
the
what
happens,
if
the
event
data
references,
attributes
that
are
defined
in
other
semantic
conventions,
so
what
happens
if
they
reference
attributes
that,
are,
you
know,
part
of
the
the
net
semantic
conventions
with
the
HTTP
semantic
conventions
or
whatever
that
ends
up
being?
C
D
We've
actually
got
to
call
that
so
the
ATP
URL
is
a
is
a
good
example
of
this.
Where
we
have
the
page
view
where,
inside
of
the
the
event
data,
we
originally
call
that
HTTP
URL,
because
we
were
following
the
semantic
conventions.
We've
now
knocked
that
back
to
just
URL,
so
it'll
be
event
data
and
then
in
there
would
be
URL
where
we
would
say
this
effectively
is
following
the
HTTP
URL
semantic
conventions,
but
it's
just
called
URL
inside
event,
data
so
yeah.
D
B
Another
problem
with
this
is
that
whatever
is
inside
event,
data
is
not
going
to
be
governed
by
schema
files.
By
definition,
the
schema
files
operate
from
the
top
level
attributes
yeah.
We
will
have
to
redefine
either
extent
the
area
of
governance
of
schema
files,
somehow
so
that
we
can
manage
evolution
of
payload
of
event,
data
a
versioning
of
the
data.
Yes,
yes
of
the
value
of
event.data
right
or
you
just
give
up,
or
you
say
that
they
can't
like
schema
files-
is
not
a
way
to
deal
with
changes
of
what
the
payload
looks
like
yeah,.
D
So
one
of
the
things
which
is
in
Cloud
events
that
I
didn't
include
in
this
one
because
it
was
going
to
complicate
the
discussion,
would
be
to
have
an
event.
Data
schema
URL
to
try
and
get
around
that
to
enable
back
ends
to
validate
the
data,
which
is
one
of
satoshi's.
One
of
santosh's
requirements
was
he
wanted
to
be
able
to
validate
the
the
event
as
it
was
coming
in.
B
It
was
also
a
requirement
from
AWS
when
they
were
participating,
yeah
well,
I
I.
Also,
don't
quite
like
that
right.
It
sounds
like
yet
another
way
to
describe
a
schema
of
something
which
is
different
from
what
we
have
already
Unless.
Somehow
we
can
expand
what
we
have
to
include
that
capability
as
well.
D
Yep
because
I
know
when
Santosh
was
well,
you
know
the
the
PR
he
was
showing
this
morning
in
the
in
the
romsig.
One
of
the
reasons
we
had
to
go
with
just
defining
it
in
markdown.
There
is
because
having
the
data
defined
the
tools
that
we
have
to
generate
from
yaml
to
mark
down
boat
support,
nested
Maps,
yet
so
yeah
yeah.
B
A
B
They
talk
about
the
attributes
at
the
top
level,
right
of
the
log
record
that
you
can
change
the
name
of
an
attribute.
We
have
no,
the
the
there's,
no
way
to
express
the
idea
of
renaming
of
a
nested
attribute,
which
you
would
need
if
you
want
to
change
something
inside
the
event.
Data
yeah,
because.
D
D
If
they
want
to
do
validation,
you
know
if
you
get
a
something
that
has
event
domain
name
and
data,
then
you
know
it's
an
event,
so
you
can
effectively
get
everything
out
of
data,
so
you
realize
it
as
you
need
to
and
store
it,
but
if
you
want
to
provide
any
validation
of
that,
then
okay,
we'll
have
okay.
These
are
the
hotel
domain
name
combinations
and
therefore
these
are
the
fields
but
yeah.
We
have
nowhere
to
know
where
to
currently
Express
that
and
enforce
that
telling
you.
D
But
yeah
going
down
the
full
semantic
convention
path
for
every
single
field
with
every
within
event.
Data
is
would
be
extremely
problematic
because
quite
a
few
of
the
fields
are
based
on
w3c
browser
standards,
so
they're
already
defined
so
for
a
page
view
performance,
for
example,
the
event
data
effectively
is
a
copy
of
what
the
w3c
standard
defines
as
the
page
view
performance
data
of
which
not
every
browser
implements
every
field.
So
therefore,
you've
got
a
combination
of
pretty
much.
Every
field
is
optional,
almost.
D
I,
don't
know
if
I
put
that
on
the
top
of
this
one,
but
we
have
talked
about
that
in
the
romsig
might
have
been
an
earlier
version.
No,
it
said
I
have
to
go,
find
a.
D
There
was
another
PR
where
I
talked
about
that.
Actually
I
think
it
was
one
of
yours
too,
where
we
talked
about
combining
the
logging
API
in
the
event
API
originally
I
think
it
eventually
got
closed.
It
was
six
months
ago
or
so.
B
D
B
D
Yeah,
it's
really
to
call
out
sorry
if
a
back
end
comes
across
something
it
has
event
name
and
domain,
then
it
can
just
grab
data
and
it
doesn't
need
to
know
anything
else
about
the
event
they
can
just
go
and
serialize
it
and
put
it
into
a
table.
D
B
Yeah,
no
I'm
not
suggesting
you
that
that
you
need
to
flatten
that
it's
a
it's
a
payload
defined
elsewhere.
You
give
it
a
name.
You
come
up
with
the
name
of
that
attribute.
Maybe
the
name
of
that
thing
is
w3c
dot,
performance
data
or
something
like
that
and
you
you,
you
retain
the
structure,
The
Source
structure
as
it
is
right.
There
is
no
need
to
do
any
flattening,
mapping
or
prefixing,
or
anything
like
that.
D
B
A
complicated
value
of
an
attribute
for
that
particular
event
type.
That's
fine,
and
maybe
you
even
give
it
an
event
or
data
name
as
an
option.
I
don't
know
right,
but
maybe
you
can
be
more
specific.
The
event
name
would
be
w3c
performance
data
and
then
you
would
have
another
attribute
to
record
that
payload.
For
that.
That's
that's
fine.
I,
see
no
problem
with
that.
B
D
That
which
gets
us
back
to
the
prefixing
all
those
fields
which
we
do
not
want
to
do
because
of
the
you
know,
we
have
strict
64k
limit
of
total
payload
that
we
can
get
up
off
a
browser
during
unload.
There
is
no
current
way
around
that
the
modern
browser,
so
we
want
to
try
and
keep
the
the
payload
as
small
as
possible,
because
you
know,
depending
on
the
page,
it
can
be
generating
thousands
of
events
which.
B
D
C
Yeah
this
this
has
been
a
useful
discussion
for
me,
I'm,
going
to
comment
on
this
PR
and
request
some
additional
clarification
around
when
to
use
event,
pay
event,
data
versus
attributes,
one
of
the
main
criticisms
we
got
of
count
we're
getting
of
complex,
attribute
types
in
the
javasig
is
that
it's
not
clear
when
you
should
use
a
flat
attribute
structure
versus
using
a
complex
alternative,
and
we
don't
want
to
add
more
surface
area
to
our
API.
C
B
And
the
size
argument
is
good,
I
think
right,
it's
reasonable.
If
you
can
show
that
there
is
a
limitation.
There
is
a
technical,
hard
limitation
that
there
is
no
way
that
we,
we
don't
control
that
and
by
doing
this
by
representing
the
payload.
This
way
we
reduce
the
size
of
the
payload,
and
then
it
fits
within
the
requirements,
external
requirements.
That's
that's
a
strong
argument.