►
From YouTube: 2022-05-25 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
We
had
a
discussion
yesterday
and
I
moved
all
the
topics
we
didn't
discuss
yesterday
to
today's
agenda,
but
before
we
get
into
that,
I
wanted
to
just
go
through
a
quick
status
update.
I
would
like
to
do
this
on
wednesdays,
the
wednesday
meetings
just
kind
of
know.
What's
so
everybody
knows
what's
going
on
so
I
I
listed
the
status
update
kind
of
more
detailed
last
week
and
kind
of
just
looking
at
the
high
level
categories.
A
There
are
a
few
different
work
streams
going
on
in
parallel,
so
one
is
we're
working
on
a
proposal
for
events.
Api
santosh
is
leading
that
effort.
A
C
No,
I
think
there
are
you
know
a
couple
of
things
you
know
still
remaining
to
be
worked
out,
hopefully
in
the
next
one
or
two
weeks,
we'll
address
them.
I
think
there
are.
There
are
some
there's
some
recommendation
on
the
event
domain
to
be,
you
know
specified
for
every
event
created
and
the
event
domain
is
something
that
is,
you
know,
recommended
to
be.
You
know,
library
specific,
as
in
there
are
events
that
are
cross-cutting.
C
So
for
a
given
library,
the
event
domain
is
fixed
and
the
same
library
could
be
used
across.
You
know
both
in
the
front
end
and
back
end
and
in
different
areas,
so
that
event
domain
will
reduce
the
scope
for
the
event
names.
So,
even
if
there
are
event
names
that
have
same
names,
you
know
used
by
different
domains.
You
know
that
the
domain
will
will
make
sure
that
you
know
globally.
You
know
our
domain
plus
the
event
name
is
unique.
C
Initially,
we
were
thinking
that
the
browser
could
be
a
domain.
A
mobile
could
be
a
domain,
but
I
think
from
the
logs.
What
is
coming
out
is
the
domain
is,
is
not
a
vertical.
It's
more
horizontal.
C
So
I'm
trying
to
gather
more
information
around
around
that
maybe
I'll
update
next
week.
D
Was
that
the
discussion
where
effectively
the
domain
is
the
instrumentation
name?
I
I
I
yeah.
A
C
Yeah
I
mean
I
I
don't
have
much
to
say
there
so,
given
that
the
log
data
model
is
it's
decided
that
you
know
that's
the
one
used
both
for
events
and
logs,
and
you
know
in
this
sig.
You
know
we
are
not
so
much
concerned
about
locks,
so
I'm
not
putting
so
much
thinking
into
the
lock
side
of
things,
the
application
lock
side
of
things,
but
I
think
the
the
larger
log
sig.
I
think
they
are
concerned
about
whether
the
log
api
should
include
end
user
callable.
C
You
know
log
api,
should
it
at
least
have
the
apis
for
the
purpose
of
use
by
the
log
appenders,
so
so
yeah.
There
are
some
opinions
that
you
know.
What
should
the
log
api
consist
of
the
scope
of
the
log
api
and
then
that
will
determine
the
naming.
A
C
C
Should
the
events
have
the
span
context
added
by
default
or
should
the
api
have
should
the
api
you
know
enable
you
know
explicitly
requesting
for
the
span
context
to
be
added
to
the
events?
Are
there
any
thoughts
on
that
from
from
this
team.
C
C
I
think
the
the
the
current
behavior
is
that
it
adds
the
span
context
by
default,
so
the
log
api
that
we
will
use
that
will
we
are
building
for
creating
events
it.
It
will
be
backed
by
an
sdk
that
already
exists
for
logs
and
that
sdk
currently
is
is
designed
such
that
it
adds
the
span
context
into
the
you
know
log
records
by
default.
C
Now
the
question
is:
is
that
a
good
thing?
There
are
scenarios
where
you
know.
I
feel
that
the
span
context
is
misleading.
In
the
logs
like,
for
example,
you
made
a
network
request
and
you
clicked
a
button
right.
While
you
are
waiting
for
a
response
so
now
that
button
click
has
nothing
to
do
with
the
network
request,
so
that
button
click
event.
Having
the
network
request
context
in
in
the
log
record
is
it
may
not
hurt,
but
it
can
cause
unnecessary
confusion.
D
D
For
that
reason,
so
I
I
would
prefer
an
option
where
it
didn't,
but
I
can
also
see
the
case
of
where
having
an
auto
attach
is
a
good
thing
too
so,
like
for
languages
which
have
thread
bound
variables,
it
makes
a
lot
of
sense
for
things
like
browsers,
which
are
single
threaded.
It
doesn't
make
sense
and
it
it.
The
fundamental
issue
is
the
global
scope
of
the
global
context,
and
I
don't
know
how
we
break
that
down
without
causing
issues.
C
Okay,
so
so
are
you
suggesting
then
that
for
the
for
the
events
api
we
that
the
default
behavior
we
keep,
as
you
know,
not
associating
the
span
context.
D
C
A
Okay
sessions,
there
is
no
progress.
I
think
ted
is
planning
to
propose
the.
A
Mutating
mutating
resources:
when
he's
back
classification,
we
discussed
using
introducing
device
kind
attribute
yesterday,
but
it
is
not
clear
whether
that
could
be
determined
by
you
know
in
the
client.
A
So
I
think
there's
no
resolution
at
this
point
yet
or
no
decision
and
then
for
semantic
conventions.
Just
one
update
the
browser
attributes
pr
was
emerged
last
weekend
as
part
of
spec.
Now.
A
E
A
A
One
is,
I
think,
event
name
being
like
the
the
type
more
of
like
the
type
or
schema
name
or
the
attribute
the
other.
The
other
idea
is
to
have
event
name
be
more
in
line
with,
with
what
would
like
span
name
is,
which
is
it's
more
freeform
field,
and
it
doesn't
classify.
Does
it
you?
It's
not
used
to
classify
the
the
type
of
type
of
the
event.
A
I
talked
to,
I
talked
to
ted
said
about
it
yesterday
and
he
is
he's
the
one
actually
who
who
brought
up
that
the
event
name
should
be
should
be
a
akin
to
spam,
name
or
spent
event
name.
A
So-
and
he
was
ted-
was
explaining
to
me
that
the
hotel,
the
hotel
way
of
identifying
things
right
now
is
by
yeah,
is
by
presence
of
presence
of
attributes,
and
then
the
reason
is
that
you
know
the
intent
was
to
have
different
name
spaces
of
attributes
being
composable,
so
that,
like
when
a
span
has
http
attributes
and
has
also
db
attributes.
It
can
represent
two
things
at
once.
It
can
represent
a
an
call.
It
can
also
represent
the
database
call,
and
then
he
was
saying
so
I'm
just
paraphrasing
what
ted
said.
A
So
I
did,
I
did
bring
up
the
you
know
that
we
talked
about
validation
of
events
that
we
feel
like
it's
it's
something
that
should
be
done
in
client
side
because
of
the
untrusted
data.
That's
coming
in.
A
But
I
wasn't
so
yeah,
so
that's
kind
of
where
we
are.
A
I
think
the
the
options,
the
three
options
that
I
can
think
of
is
is
either
we
follow.
What
what
the
the
the
pattern
with
spans,
which,
where
us
event
name,
would
be
kind
of
the
same
role
as
span
name,
and
then
we
use
presence
of
other
attributes
for
classification.
A
And
then
the
third
option
would
be
a
combination
would
be
maybe
two
fields,
one
event
name
and
one
event,
type.
D
Yeah
I
I
m
my
viewers.
An
event
is
fundamentally
different
from
a
span
and
that
event
defines
a
complete
thing.
I
don't
think
we
want
to
say
an
event
could
be
multiple
events.
The
event
may
have
different
attributes
from
that's
inherited
from
other
places,
but
an
event
is
an
event.
It's
not
well.
This
event
is
actually
multiple
things
and
then
the
back
end
has
to
try
and
infer
what
the
event
is
based
on
the
presence
or
absence
of
certain
fields.
That's
just
going
to
get
way
too
problematic.
D
Yeah,
I
I
just
jumped
ahead
a
little
bit
looking
at
the
elastic
schema,
trying
to
see
what
they
do
and
effectively
quickly.
Looking
at
that,
it
looks
like
the
same
thing.
An
event
is
event:
it's
not
an
event
is
not
a
collection
of
events.
They've
got
like
an
action.
A
category
looks
like
a
code,
maybe
which
identifies
the
event
so
which
gets
back
to
the
human
readable
question
that
you've
got
there,
because
their
code
is
a
number.
D
Yeah,
so
it's
like
the
fourth
field
down
yeah,
so
there's
an
event
direction
which
describes
the
event
then
they've
got
event.category
is
a
categorization.
Then
they
have
event
up
code
which
they're
saying
identifies
the
code.
For
this
event,.
A
D
D
A
Yeah,
I
don't,
I
don't
know
what
the
code
is
used
for.
I
just
looked
at.
I
did
look
at
the
categorization
fields,
which
is
which
I
have
here.
So
there
are
four
and
they
look
very
different
to
me.
A
A
Is
is
kind
of
like
the
bucket
sort
of
like
the
domain?
Is
it
related
to
the
process
or
network
or
database.
A
C
I
I
know
that
for
for
could
be
for
wrong
reasons,
but
I
think
we
have
to
use
the
name
field
for
sure,
like
even
dot
name
has
to
be
there
more
because
I
think
the
you
know
that's
the
name
of
the
field
in
events
in
a
span
and
also
now,
maybe
that
that's
the
main
reason
I
think
to
keep
parity
with
those
events.
It's
good
to
have
event.name,
which
is
missing
in
your
elastic
schema
list.
C
Yeah,
I
think,
domain
or
category
if,
if
we
consider
them
as
the
same
then
domain
along
with
the
event
name,
you
know,
could
be
a
unique
combination
and
that
might
be
sufficient
yeah.
D
A
D
C
Think
kind
can
be
there,
but
again
it's
an
optional
field
and
I
think
the
minimum
attributes
is
still
that
the
name
and
the
domain.
A
Although
the
interest,
the
interesting
thing
like
what
I
that
I
also
noticed
about
this-
is
that
it's
it's
like
obviously,
ecs
is
very
much
like
for
logging
purposes,
and
they
you
know,
as
we
we
think
we
think
event
as
being
a
like
a
subclass
of
vlog
like
a
special
special
kind
of
log,
they
think
of
it.
E
So
to
quickly
jump
in
when
I
was
proposing
the
ecs,
I
didn't
have
in
mind
to
follow
exactly
the
allowed
values
from
them,
but
rather
take
the
idea
of
categorization
and
reuse.
Their
attribute
names.
D
D
You
know
consider
as
something
a
compatible
path,
rather
than
blocking
them
completely.
A
So,
just
to
get
a
little
more
specific,
like
an
example,
would
we
want
that
to
be
something
like
interaction
or
exception,
and
then
every
type
of
interaction
would
have
this.
If
it's
a
click
or
tap
or
scroll
like
it
would
always
be
interaction,
and
then
you
would
look
up
the
fields
from
that.
A
Predefined
of
grouping
of
interesting
events
like
just
like
with
span
right,
like
so
like
if
you
on
the
back
end,
if
you
wanted
to
do
analysis
on
on
or
visualization
on,
you
know
user.
Did
this
specific
thing,
and
you
just
want
to
like
look
that
up
then
or
analyze
or
based
on
that
value.
That
would
be
useful.
E
I
had
a
discussion
today
with
our
one
of
our
product
managers
and
he
also
was
suggesting
to
stick
to
the
name
like
for
spence,
and
I've
posted
one
proposal
to
the
chat.
So
if
you
click
on
a
button
in
a
web
ui,
that's
where
the
button
text
contains
continue.
C
For
name
yeah,
actually
that
would
be
so.
The
log
record
has
a
has
a
body
field
that
is
used
for
capturing
the
application.
Log
message
string
and
you
know
we
could
use
that.
You
know
to
as
a
as
a
friendly
description
of
the
event
right
and
but
that
is
not
going
to
be.
You
know
it
could
like
for
the
same
button
click.
You
know
that
the
text
will
vary
right
for
each
event.
So
that's
an
additional.
C
You
know
field,
but
you
know
it
cannot
be
the
field
to
you
know
uniquely
identify
the
event.
C
C
So
the
checkout
button
click
anything
that
is
specific
to
the
application.
You
know
that
customers
want
to.
Let
that
you
know
your
instrumentation.
Would
you
know,
based
on
the
context,
you
know,
give
some
construct
some
friendly
text
to
be
displayed
in
the
ui
purpose
in
the
ui.
You
know
that
that
cannot
be.
C
A
A
A
D
Yeah,
I'm
just
gonna
drop
into
chat,
a
link,
so
this
comes
back
to
where
you
were
talking
about.
You
know:
checkout
button
click,
so
in
app
insights,
we've
got
like
this
effective
e
number,
but
this
is
for
our
click
analytics
plugin,
which
is
open
source
which
defines
effectively
the
intent
of
the
click,
so
this
is
just
like
they
get
sent
as
numbers
mostly.
A
Yeah,
I
guess
I
guess
you
can
you
could
always
generate
that
description
on
the
back
end
from
other
fields.
D
You
don't
like
having
it
that
the
name
being
a
collection
of
things.
I
I
it's
going
to
make
it
hard
for
the
back
end
to
qualify
and
route.
The
event
is
what
I'm
thinking,
because
really
you
know
if
you're
getting
a
bunch
of
browser
events
you're
getting
potentially
you
know
millions
of
requests
from
a
second
that
you
just
want
to
like
qualify,
throw
in
a
database
or
you
know,
send
to
the
right
backend
system
as
quickly
as
possible.
You
want
very
little
processing.
A
A
A
D
We
have
both
we
for
our
internal
version.
We
have
a
plug-in
that
developers
can
can
add,
which
just
you
know,
validates
the
event,
but
for
production
we
say:
don't
have
that
so
in
a
production
environment
it
just
sends
it
to
the
end.
The
back
end.
Validation
is
really
just
based
on
size
and
type,
not
on
whether
the
fields
exist
or
don't
exist.
D
F
Yeah
yeah,
we
have
a
similar
story,
I
mean
we,
we
do
fairly
heavy.
I
guess
validation
right
now,
so
we
do
check
field
names.
Field
type
exists
on
on
the
built-in
data
that
we
expect
to
be
there
for
our
own
dashboards
going
forward.
You
know
we'll
probably
do
both
where
there's
some
data
will
just
pass
through
and
some
data
that
you
know.
If
someone
wants
to
validate
it,
they
they
can,
depending
on
their
use
case.
D
Yeah,
I
probably
should
qualify
the,
but
we
also
have
validation.
That
says
these
are
the
fields
we
expect
and
if
you
pass
a
field
that
we
don't
expect,
except
into
the
like
the
property
bag,
which
can
be
anything,
the
event
will
be
dropped
on
the
floor,
but
we
don't
validate
based
on
like
if
this.
This
event
is
this,
so
therefore
these
fields
must
exist.
If
that
makes
sense,
so
I
think
there's
a
general
shape
of
schema
of
these
are
the
things
that
we'll
accept
and
we'll
drop
on
the
floor.
Otherwise,.
C
C
I
think
that
is
eventually
needed
right.
I
think
you
know
at
the
end
of
the
pipeline
when
you
want
to
provide
some
like
how
do
you
analyze?
You
know
each
different
event
that
logic
in
the
back
end
will.
C
C
So
you
could
look
at
the
combination
of
attributes,
but
I
I
don't
think
it
can
scale
so
to
keep
it
simple.
I
think
we
it'll
be.
You
know
really
good.
If,
if
we
define
you
know
minimum
set
of
fields
to
uniquely
identify
the
event,
one
would
be
great,
but
we're
not
sure
you
know,
since
we
don't
know
the
entire
scope
of
how
these
events
would
be
used
by
you
know
other
folks,
you
know
we
added
the
domain.
At
least
there
is
some
protection
for
avoiding
conflict.
C
So
so
the
domain
plus
you
know
name,
you
know
those
two
you
know
should
be
sufficient.
C
Yeah
yeah
so
that
I'll
I'll
find
out.
I
think
that
needs
to
be
worked
out,
but,
assuming
that
you
know
the
domain
identify
where
let's
say
client-side
events
is
is
a
domain
right.
I
think
tigran.
Currently,
his
suggestion
is
the
three
types
of
events
he's
suggesting
is
profiling,
client-side
events
and.
C
Forgot
he
had
one
more
in
his.
I
I.
B
C
So
so,
if
if
it
is
a
client
side
events
and
in
the
client
side,
you
know
these
are
the
even
types
you
know
those
two
might
be.
You
know
enough
to
uniquely
identify
each
event.
A
C
So
from
the
client
side
itself,
you
know
there
could
be
profiling
events
as
well.
Let's
say
from
for
a
desktop
application.
You
know
you
have
a
library
that
emits
profiling
events,
so
so
that
that
needs
to
evolve.
You
know
the
definition
of
domain
and
what
are
some,
I
think,
in
open
telemetry.
The
domain
will
need
to
be
like
a
first
class
entity
in
the
semantic
conventions
we
have
to
define
categories
or
our
values
for
the
domain,
so
that
there
is
no
confusion.
C
So
so
the
you
know
the
definition
of
domain,
and
you
know
what
are
its
values
that
needs
to.
You
know
be
clarified,
but
assuming
they
know
that
exists,
you
know
I
I
feel
like
they
know
that
will
solve
the
problem.
We're
talking.
A
A
D
D
I
I
think,
eventually
we're
probably
going
to
get
to
a
point
where
we'll
ask
each
vendor.
Okay,
what
what
are
the
events
and
what's
what's
the
shape
of
those
events
and
in
the
case
of
ecs,
we
had
this
in
this
spec
to
see
if
we
can
come
up
with
a
no-till
common
set,
and
this
may
be
where
the
domain
comes
into
place
yeah.
It
may
be
a
case
that
the
vendors
have
their
own
specific
sort
of
domains.
D
A
I
was,
I
did
kind
of
scan
through
the
the
fields.
A
And
it
seems
to
me
like
for
client
side
at
least
there
are
only
a
few
field
sets
that
would
apply
like
the
autonomous
system
would
be
one.
A
Geo
would
be
another
one,
maybe
user
user.
D
User-
I
I
do
like
internally
in
microsoft,
I
do
have
a
pm
and
effectively
one
of
the
one
of
the
team
members
from
the
java
guys
who
are
looking
at
potentially,
they
saw
santosh's
event
api
effectively
using
this
for
server-side
events
as
well,
either
as
this
is
just
a
straight
server-side
event
or
it's
a
it's
a
proxy
and
they're
going
to
have
it
sent
back
to
a
server
and
that
will
simulate
the
client
side
events.
D
So
we
should
just
keep
that
in
mind,
as
as
part
of
defining
the
main
name
type
as
part
of
the
api.
C
Okay,
can
can
you
clarify
that
a
little
bit
nev?
What
when
you
say,
the
the
rum
events
are
created,
or
you
know,
from
the
server
yeah.
D
They
get
around
ad
blockers
so
effectively
send
it
back
to
the
same
domain
of
the
the
hosting
page,
so
that
ad
blocker
doesn't
kick
in
and
block
the
request.
D
E
So
basically
you're
forwarding
the
event
or
remaining
yeah
okay,
so
the
same
technique
could
also
be
applied.
If
you
have,
if
you
think
about
statically
hosted
site
where
you
generate
the
event
on
the
server
yep
perfect.
C
D
It's
it's
both
so
so
I
I
talked
about
what
the
pm
wants
to
be
able
to
have
events
generated
which
are
server
events
using
the
event
api.
That's
that's
part,
one
and
part
two
is
just
being
a
proxy.
C
Yeah
but
the
part
one
is
not
they're,
not
rum.
Events.
D
Correct
that
they're
not
wrong
events
but
they're
being
reported
via
the
event
api,
but
I'm
just
saying
that
we
should
just
make
sure
that
the
event
api
supports
that,
because
you
know
they
don't
want
to
include
the
event
in
in
the
span.
They
just
want
to
record
the
event
which
in
ecs
there's
a
couple
there
that
I
can
see.
That
would
be
that
sort
of
thing
again.
This
is
a
crossover
between
what
is
a
log
and
what
is
event
so
we
could
just
turn
around
and
say.
D
D
Yeah
really,
realistically,
I
think,
with
what
we're
defining
so
far.
I
think
it's
possible,
I'm
just
just
calling
it
out
so,
okay.
A
Okay,
the
next
topic
that
I
I
put
it
put
down
there,
because
this
is
also
a
discussion
that
we've
had
about
optimization
in
the
client
when
we
define
these
semantic
conventions.
I
was
wondering
if
we
propose.
A
Define
them
in
the
same
way
as
all
the
other
attributes
are
currently
defined,
which
is
a
table
that
has
you
know
this
is
the
namespace
and
it's
a
table
of
the
different
named
attributes,
and
we
don't
worry
about
how
they're
actually
sent
or
do
we
want
to
actually
define
yes
like
this.
This
these
attributes
in
this
namespace
should
be,
should
not
be
sent
as
individual
attributes.
They
should
be
sent
either
as
nested.
A
You
know
like
a
sync
so
that
the
namespace
is
not
repeated
or
serialized,
in
maybe
the
body
or
other
field,
or
a
single
single
attribute.
D
Page
action
lines
31
to
62.,
it
might
help.
So
this
effectively
is
the
events
so
in
here
we
have
both.
So
we
have
like
the
event.data
ones,
are
effectively
well
sort
of
flat.
It
is
actually
nested.
So
the
the
data
you
know,
data.basetypedata.uri
sent
us
json,
but
the
properties
one
is
completely
nested.
That's
the
completely
open
element.
So
I
think
that
there
is
going
to
be
a
case
of
where
we
might
want
both
or
I
don't
know.
A
D
But
the
other
ones,
all
the
stuff
in
dot
data-
that's
all
effectively
part
of
you
know
defining
what
what
this
event
is,
which
is
a
click
event.
So
yes,
but
these
we
could
say
we
could
define
those
in
a
table,
but
I
would
prefer
to
see
them
like
everything
gets
serialized
as
json
in
this
case,
like
the
fact
that
it's
an
event.data
is
nested.
C
Now
I
think
it
it
conflicts
with
the
events
api.
We
are
designing
right.
I
think
I
think,
martin,
if
I
understand
your
concern
correctly,
I
think
your
an
example
would
be
like.
C
There
are
three
attributes,
let's
say:
event.name
even.kind
even.domain,
and
instead
of
repeating
these
three
as
three
different
attributes,
you
want
to
have
one
attribute
called
event
and,
and
then
the
value
of
that
would
be
a
a
dictionary,
an
object
which
further.
F
C
And
so
so
I
I
think
the
answer
to
me
is
easy
because
it
doesn't
fit.
You
know
the
the
you
know
the
api
convention
we
are
designing.
I
think
we,
the
api,
requires
a
set
of
attributes.
Now
those
attributes
can
have
common
prefix.
C
You
know
that
you
know
cannot
be
easily
handled
at
the
api
level.
It
has
to
be
handled
at
a
at
a
lower
level
like
behind
the
scenes.
When
you
encode
the
data
further
before
sending
on
the
wire,
you
will
have
to
define
some
protocol
to
to.
You
know,
squeeze
things,
but
not
at
a
top
level.
C
D
I
I
would
probably
extend
that
a
little
bit
and
say
name,
type
and
kind
could
be
first
class
attributes,
but
in
the
case
where
I
had,
their
data
could
be
a
single
attribute,
which
effect
is
and
a
nested
attribute
with
those
names
so
effectively
you'd
say
emit
the
event
you
give
it
the
name.
It
has
an
attribute
of
kind
and
type
and
domain.
Maybe,
and
then
data.
A
That
still
sounds
to
me,
like
implementation
of
the
exporter,
right,
like
it
wouldn't
be
defined,
would
be
one.
It
wouldn't
be
defined
like
in
the
semantic
conventions
like
that.
D
Well,
we
were
defined
in
the
semantic
convention,
saying
an
event
has
name
kind
type
and
a
data
attribute
and
then,
as
part
of
the
defining,
what
does?
What's
the
shape
of
the
event
we
just
define
somewhere?
Is
it
in
a
table
or
whatever
that's
documentation
in
terms
of
what
the
fields
are
expected
in
that
data
object
or
the
data
attribute
to
use
the
term
that
santosh
was
talking
about.
A
C
So,
are
you
reserving
data
as
an
attribute
that.
D
D
Well,
it
will
have
a
type
of
any,
but
then
we'll
define
what
yeah
the
the
any
value,
I
think
is
the
the
protobuf
definition,
but
we'll
then
say
these
are
the
the
expected
fields,
depending
on
the
event,
the
main
name
type.
Whatever
we
come
up
with
there.
C
D
Yes,
if
we
have
all
the
attributes
listed,
so
if
we
had
like,
for
example,
in
the
one
that
I
had,
if
we
said
we
have
the
attribute
of
uri,
page
type
properties,
action
type,
behavior,
click
cord.
If
we
define
each
one
of
those
as
a
separate
attribute,
then
in
fact
the
exporter
is
going
to
serialize
that
separately
and
that
creating
that
object
is
just
going
to
be
painful.
C
The
the
solution
is
to
have
a
prefix
for
for
each
of
those
attributes,
and
you
know
you
know
and
ignore
the
duplication.
I
think
ignore
the
additional
size.
D
I
I
don't
think
we
want
to
ignore
the
not
for
not
for
clients.
We
definitely
do
not
want
to
ignore
the
size.
So
I
I
do
not
want
to
pass
it
as
data
dot
uri,
they
end
up
page
type
data
dot
whatever
at
all,
because
that's
just
with,
and
in
the
case
of
the
browser
we,
you
know.
In
a
page
unload
case,
we
have
a
maximum
of
64k
to
send
off
every
event
during
a
page
unload
and
by
having
all
these
data.
C
So
I
I
I
know
we
don't
have
much
time.
We
could
talk
next
time,
but
I
have
one
more.
You
know
thing
going
on
in
my
head
about
the
size
of
the
payload.
You
know,
given
that
the
you
know,
typically
in
all
browser
applications
from
like.
I
have
never
done
it
myself
in
any
of
the
products
that
I
worked
on,
but
I
quite
often
I
see
you
know
most
popular
applications.
They
use
url
parameters.
C
You
know
using
obfuscated
names
right
like
single
digits,
so
it
not
only
provides
you
know.
Security
like
you
know
the
the
people
trying
to
hack
things.
You
know
they
don't
know
what
that
field
represent,
but
it
also
provides
you
know,
sizing
size
benefit
right.
It
reduces
the
size,
that's
transmitted,
so
in
terms
of
semantic
conventions,
you
know
we
could
define
a
short
name
for
every.
C
Attribute
right,
one
proposal
is
that
you,
you
keep
the
original
names
long,
but
then
have
an
encoding
layer
which
translates
before
transmission.
You
know
before
exporting,
you
know
it
could
convert
all
long
names
to
you
know
like
obfuscated
short
names
and
those
could
be
even
generated
on
the
fly
right
like
you
have
enough
frustration
tool
that
would
you
know.
D
So
identity
does
this.
So
if
you
look
at
an
event
going
out,
you'll
you'll
see
that
it
has
numbers
for
the
common
names
so
that
the
back
end
can
can
pull
it
apart
to
try
and
keep
the
perl
load
smaller
as
part
of
our
open
source
stuff.
We
don't
do
that
purely
because
of
the
cpu
performance
in
creating
that
extra
translation
layer.
It
is
extremely
problematic
to
have
to
effectively
go
through
every
single
field
and
convert
it.
D
For
example,
we
had
with
our
in
internal
version.
We
had
the
ability
that
a
field
name
can
have
a
document,
so
someone
can
pass
an
event
and
say:
I'm
going
to
have
you
know,
fred.joe
is
is
bill
and
as
part
of
the
serialization
process,
we
have
to
go
through
every
field
and
say:
is
there
a
dot
here?
It
has
a
dot
here,
we're
going
to
separate
it
out
into
separate
objects
before
we
stringify
it
with
json.
C
D
C
Yeah
you
could
avoid
that
additional
layer
of
you
know
computation
by
using
the
short
names
in
the
first
place,
so
so
the
semantic
conventions
library
is
already
used
to
refer
to
the
attribute
names.
So
between.
C
C
You
know
that
attribute
name
right
and
at
you
know
that
will
replace
with
with
the
original
string
now,
if,
if
a
flag
is
set
that
you
know
that,
should
you
know
point
to
a
short
name,
so
you
are
creating
your
objects
with
the
short
name.
You
know
violation.
D
C
No,
I
mean
you
could
generate
the
the
library,
you
know
you
could
have
two
versions
of
the
library
and
you
could
include
only
the
ones
with
short
names.
C
I
think
the
whole
payload
size
we
should
look
at
it
as
a
whole
and
see
what
can
be
done.
This
would
be
one
aspect
of
it.
D
Yeah,
like
working
with
office,
they
actually
do
this
the
proxy
approach,
because
our
payload
is
too
large
because
we
have
a
bunch
of
stuff
so
effectively.
They
cut
it
down
and
hydrate
values
on
their
back
end
because
of
what
we're
going.
If
we
do
this
in
hotel
there's
no
way,
I
can
get
them
to
use
otel
simplistically
as
it
is,
it's
already
a
push
trying
to
convert.
D
A
D
F
A
A
C
I
I
don't
think
there
is
any
need
to.
I
mean
it
doesn't
conflict.
I
think
we
can
go
ahead.
The
the
event
takes
a
bunch
of
attribution,
one
of
the
attributes
is,
is
data
which
is
any
type
so
so
there
is
no
conflict
anywhere.
So.
A
Yeah,
all
I'm
wondering
is
like:
if
we're
when
we're
defining
semantic
convention
conventions
for
individual
event
types,
then
we
would.
We
would
say
like
these.
These
are
the
attributes,
for
example,
for
a
click
event,
but
you
would
not
add
them
to
as
individual
attributes
you
would.
You
would
serialize
them
and
put
them
in
event.
Data.
A
I
regret
time
there
was
one
more
topic
for
improving
project
board,
which
was
tests.
That's
topics
where
we're
just
moving
over
to
the
next
week.