►
From YouTube: 2022-09-21 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
C
We
were
going
to
continue
discussing
the
schema
stuff
today.
I
did
put
some
of
the
questions
on
our
agenda
doc,
but
looks
like
Santosh
is
not
going
to
turn
until
8
30.
A
Okay,
so
I
do
not
have
anything
else
that
I
that
I
want
to
that.
I
have
on
my
agenda
aside
from
just
just
asking
for
I'm
looking
for
help
with
the
logs
implementing
the
logs
SDK
in
the
JavaScript
repo
there's,
a
the
API
has
been,
has
been
merged,
I
think
a
couple
weeks
ago.
So
now
the
next
step
would
be
to
build
to
work
on
the
SDK
and
an
exporter.
I
I
started
that
work.
I
have
a
branch.
A
C
Yeah
I
guess:
if
there
are
no
other
topics,
then
we
could
switch
to
schema.
There's
some
general
questions
and
you
know
asking
for
help
and
you
know
and
participation
I
could
get
started
with
that.
You
can
try
and
differ
actual
attributes,
discussion
or
field
discussion
until
Santos
joints.
C
It,
okay
cool.
So
let
me
just
share
my
screen
real
quick,
so
we
all
look
at
the
together
and
stuff.
A
C
I,
don't
see
you
guys
anymore
on
the
screen,
but
yeah
if
you're
reacting
or
whatever
Zoom
did
something
funny
just
skipped
anything
thanks.
Everybody,
that's
you
know,
has
been
contributing
to
our
you
know
the
main
document
we've
been
collecting
all
of
the
events
and
stuff
we've
been
actively
working
on
this
for
the
past
few
weeks,
I
think
over
on
the
Tuesday
meetings
and
I
realized.
C
This
is
a
this
is
another
meeting
where
a
lot
of
people
come
to
and
I've
been
asked
to
join
this
and
continue
discussions
here.
So
I'll
be
joining
this
also
and
we'll
be
discussing.
C
You
know
at
least
part-time
schema,
I,
don't
think
I've
met
I
and
you
know
Stefan
Quinn
and
Martin
I.
Think
from
from
this
point
of
view.
So
if
you
guys
are
able
to
join
the
Tuesday
meetings,
that'll
be
great.
Is
that
something
that
you're
able
to
do.
B
Is
it
on
the
is
it
on
the
main
calendar?
Yes,.
C
Okay,
so
on
the
meeting
you
know,
this
meeting
agenda
generally
has
the
two
dates
back
and
forth.
So
this
is
the
meeting,
so
we
have
been
a
smaller
set
of
folks
have
been
meeting,
and
that's
where
this
main
schema
discussions
started.
C
It'll
be
great.
If
you
did,
that
I
seems
like
that's
a
dedicated
time
to
talk
about
schema.
A
lot
seems
like
it.
I
might
be
wrong.
C
Okay,
so
that's
great
and
so
far
just
to
catch
up.
Folks
on
you
know
where
we
are
at
and
things
like
that,
just
real
quick.
We
used
this
document
to
basically
dump
everybody's
schema
in
here
and
then
contact
information
and
things
like
that
and
then,
as
a
working
document
we
created
an
Excel
spreadsheet
linked,
is
also
in
the
in
the
dark.
C
What
we,
what
we're
doing
is
one
tab
per
event
that
we
want
to
Define
ultimately
for
open,
Telemetry,
ROM
events
in
a
browser,
and
you
know
potentially
mobile.
Also,
at
you
know,
toward
the
end
page
view,
it's
obvious,
and
you
know
we
do
have
some
comments
and
things
and
we
also
try
to
capture
what
we're
gonna
call
hang
on
a
second
get
out
of
there.
C
Okay,
so
we
also
capture,
try
and
capture
what
each
event
is
for
and
stuff
in
the
stocks
also,
so
it
should
be
self-explanatory,
but
if
it's
not
comments
and
stuff
should
be
there
going
back
here,
we
went
through
you
know.
First,
you
know
a
high
level
and
then
defined
some
of
these
things.
We
recognized
these
are
the
events
that
we
needed
to
track.
C
It
should
be
in
one
of
the
discussions.
The
last
couple
of
weeks,
page
view,
page
load,
span,
navigation,
timing,
resource
stunning,
so
on
and
so
forth,
and
we
started
with
going
through
page
view,
with
sort
of
a
fine
to
come.
The
way
we've
been
doing,
that
is,
you
can,
as
you
can
see,
all
the
vendors
fields
are
here.
It
looks
like
a
lot
of
Madness
and
stuff,
but
what
we
did
is
anything
that's
comparable.
C
C
It
looks
like
only
nearly
catches
that
as
part
of
page
view,
nobody
else
does
potentially
could
be
dropped
or
if
modern
has
a
great
case
for
that,
we
could
all
discuss,
and
you
know
promote
that
as
a
field
that
we
want
to
capture
as
part
of
open
Telemetry
from
events.
C
I'll,
take
it
as
this
okay,
perfect
and
then
the
way
it's
organized
here,
it's
open,
Telemetry
and
rum.
These
two
are
the
columns
that
we
are
hoping
to
fill
out
as
we
go,
you
guys
will
figure
out.
You
know
what
are
the
tools
that
we
use.
You
know
to
kind
of
Drive
the
descriptions
and
things
anywhere.
You
see
these
descriptions.
That
means
it's
already
been
discussed,
most
likely
that's
a
final
field,
name
or
whatever.
C
It
is,
and
then
today
this
morning
before
in
preparation
of
this
meeting,
I
kind
of
selected,
the
things
that
we
could
talk
about,
my
goal
is
to
go
through.
Just
you
know,
look
at
this
talk
and
go
wherever
it's
it's
common.
Let's
discuss
them.
First,
get
them
out
of
the
way
and
then
start
talking
about
individual
vendors
can
try
their
fields.
Discussion,
for
example,
I
have
a
name
here
for
Microsoft
and
I
can
talk
about
why
it's
important
if
I
need
otherwise
I
could
just
drop
it.
C
That's
where
you
want
to
go
so
today,
we'll
start
with
these
guys
and
then
cut
into
the
discussion
down
these
highlighted
items.
That's
probably
where
we
will
have
time.
It
seems
like
it's
a
slow
process,
but
I
think
it
will.
As
we
go
we'll
pick
up,
speed.
C
Okay,
yeah
go
ahead.
C
Okay-
and
this
is
super-
annoying
I-
don't
see
you
guys,
as
you
know,
video
and
stuff,
so
I
don't
know
if
you're
talking
whatever
so
you
may
have
to
you
know.
Stop
me
talk
out
loud.
If
I'm
you.
B
I
think
one
thing
from
the
honeycomb
side
is
like
we're
very
flexible
in
terms
of
what
things
are
named
because,
like
we
are
promoting
like
open
Telemetry
is
the
primary
way
to
get
data
into
honeycomb,
so
I
think
I
think
we're
quite
flexible
in
terms
of
like
naming
things.
This
is
just
kind
of
like
what
we've
done
for
now.
While
it
doesn't
exist,
so
that's
that's.
That's
kind
of
one
thing
I
wanted
to
mention
is
that
kind
of
want
to
do
whatever
is
best
for
for
otel
itself.
C
Okay,
yeah
I
think
that's
great
thanks
for
sharing
that
the
the
idea
also
should
be
to
kind
of
figure
out.
You
know
short
of
names
and
stuff.
Meaningful
short
names
is
probably
the
idea.
I,
don't
believe.
Any
of
us
are
really
fixated
on
names.
C
I
can
talk
talk
for
Microsoft,
you
know
Nev
jump
in
and
correct
me
if
I'm
wrong,
yeah
we're
not
fixing
our
names
either
they
gotta
be
meaningful
and
they
are
shorter
because
it's
coming
from
browser,
we
don't
want
like
really
super
long,
descriptive
names,
that's
basically
it
because
most
of
us
are
going
to
do
a
mapping
when
we
export
to
our
field
names,
so
yeah
I,
don't
really
care.
Yeah
I,
don't
really
care.
C
If
we
end
up
calling
ours
F1
F
to
F3,
you
know,
as
long
as
I
have
a
mapping
I'm
good
for
for
our
side.
It's
not
ideal,
but
yeah
I.
Think
that's!
Okay!
C
Okay,
if
somebody
can
tell
me
how
to
get
rid
of
this
zoom
bar
at
the
top
I'm
going
to
get
to
this,
you.
B
C
Yeah
I'm
in
apologize:
yes,
now
I'm
a
heavy
teams
user,
so
I'm
really
familiar
with
all
the
teams
and
stuff
resume
anyway.
C
Going
back
to
here,
we
could
probably
start
the
discussions
here,
the
this
one
here,
I
S,
you
know
I've
seen
this
across
New
Relic
and
honeycomb
and
Microsoft.
We
don't
have
representatives
from
AWS
and
Santosh
didn't
think
it
was
there.
But
you
know
you
would
have
pointed
out:
it's
not
there,
but
I
believe
this
is
required
for
generally.
Any
thoughts
on
this
should
be
just
promoted
here
as
a
top
level
field
or
open
Telemetry
field.
B
C
The
one
point
I
would
like
to
talk
about
is
we
used
to
have
browser
width
and
height
as
a
separate
two
separate
Fields
several
years
ago
and
part
of
schema
discussions.
We
converted
to
screen
dress
it's
a
W
by
h,
w
x,
h
string,
so
to
speak.
That's
that's
the
only
difference.
That's
why
I
put
screen
rest
in
both
places.
C
Okay,
yeah
I
I.
Think
that's
a
that's!
That's
if,
if
you
have
use
cases
or
in
a
scenarios
where
you
want
to
you
know
without
having
to
kind
of
parse
it
and
stuff
in
the
back,
end
makes
sense
any
other
thoughts
on.
It
are
folks,
generally,
okay,
with
just
promoting
them,
as
width
and
height.
D
C
Okay,
any
suggestions
for
stuff
or
I'm
just
going
to
type
something
names
because
of
it
seems
like
an
okay
thing
to
do.
B
Are
we
planning
on
kind
of
like
I,
guess
dividing
these
attributes
into
like
subsections
like
this?
Is
like
all
the
device
info,
or
this
is
all
of
the
like
page
info
I,
think
maybe
I'm
a
little
biased
from
like
how
we
do
it
at
honeycomb,
but
because
it's
like
yeah,
like
it's
the
Divide
but
I,
guess
keeping
it
as
short
as
possible.
C
That's
that's
a
great
question
in
in
Microsoft
we
have
similar
stuff.
Also
in
our
events,
we
have
something
called
extensions,
so
it'll
if
we
were
capturing
and
the
screen.
This
is
part
of
the
the
field
event
itself,
but
I
can
give
you
another
example
here
this
one
user
ID.
C
If
you
were
to
look
at
our
event
over
the
wire
it'll,
look
like
this
EXT
dot
user
dot
ID,
so
we
do
put
them
in
buckets
and
stuff.
So
it's
easier
for
people
to
go.
Look
at
how
user
attributes
device,
attributes
and
and
so
on
and
so
forth.
C
B
D
And
I
guess
just
a
slight
clarification
on
The
Wire
would
actually
be
an
embedded
object,
so
EXT
would
be
an
object.
User
would
be
an
object
and
then
ID
would
be
a
field
like
we
don't
have
like
EXT
dot,
user
ID,
EXT
dot
user,
whatever
it
is
just
and
that's
a
as
part
of
trying
to
keep
it
small
got.
C
It
if
it's
nested,
yes,
that
that's
a
separate
discussion
with
necessary
attributes,
availability
in
open
delivery,
also
right,
yeah,
correct
okay,
should
we,
you
know,
put
a
comment
here.
You
know.
Potentially
we
could
namespace,
then,
is.
C
B
Could
even
just
for
now
like
whether
we
make
the
decision
to
name
space
them
or
not,
maybe
have
some
sort
of
just
grouping
even
for
our
own
okay.
B
C
C
C
Thanks
I
just
kept
it
from
here.
E
B
Sorry
one
clarification,
question
I
believe
in
the
attribute
naming
conventions,
I'm,
not
100
sure
of
camel
cases
is
the
preferred
way.
B
C
Maybe
convention
point
of
view:
okay,
I
think.
A
Yeah
I
think
I
just
checked
out.
I
think
the
like
the
namespaces
are
are
delineated
by
by
a
doubt
and
like
if
it's
instead
of
a
camel
case
for
like
a
single
single
word
like
it's,
it's
it's
underscore,
it's
using
underscores,
oh
I,
see
so
excuse.
E
E
D
I
I
think
it
comes
back
to
the
early
discussions
about
if
we
end
up
dumping
all
this
into
the
event.data
as
a
as
a
nest
attribute
blob,
because
that's
why
we're
using
logs
then,
rather
than
having
the
name
of
screen
underscore
with
screen
underscore
height,
potentially
we
could
have
that
as
a
nested
attribute
as
well.
I
I
think
what
we
should
be
concentrating
on
more
than
just
the
name.
Right
now
is
the
fields.
D
D
C
D
Yeah,
how
do
you
call
my
convention
now?
That's
fine,
but
I
I
think
we
need
to
keep
that
in
mind
as
well.
C
Okay,
so
that's
good
moving
on
to
our
browser,
the
actual
user
agent
name,
I
believe,
is
what
is
browser,
so
why
don't
we
just
quickly
go
through
across
the
board
and
make
sure
that
that's
the
right
thing
for
for
Microsoft?
This
would
be
Edge.
Chrome
Safari,
like
that,
it's
not
the
whole
user
agent
seems
like
Splunk,
which
is
using
open.
Telemetry
might
be
capturing
the
whole
user
agent
string.
Is
that
correct
detail.
C
Sorry,
can
you
see
again
what
is
the
actual
string?
What
does
it
look
like.
C
Header
gotcha,
okay,
is
that
how
useful
is
that,
like,
if
you
want
to
in
the
back
end,
go
look
at
show
me
all
the
Safari
traffic
or
something
like
that?
You.
E
C
B
B
A
Foreign,
so
just
a
reminder
that
there
is,
there
are
now
already
existing
browser
semantic
relations
as
well,
which
includes
the
yeah.
It
includes
fields
for
just
the
name
and
version,
and
also
well
actually
for
Brands,
because
it's
coming
from
the
browser
API,
but
there's
also
an
attribute
for
the
Legacy
user
agent
string.
D
Yeah
and
part
part
of
that
is
being
driven
from
the
fact
that
the
user
agent
is
going
to
freeze,
so
you
won't
be
able
to
pass
it
for
the
OS.
In
fact,
you
can't
pass
the
OS
version
like
Windows
Windows
11..
If
you
look
at
the
UA
is
actually
Windows
10,
so
you
can't
figure
out
that
it's
Windows
11,
based
on
just
the
user
agent
anymore.
A
And-
and
these
are
these
symmetrical
mentions
are
defined
as
as
resource
attributes,
so
they
they
would
be,
they
would
be
attached
to
to
the
resource
not
to
the
events.
I
think
yeah.
C
D
Yeah,
so
Martin
just
dropped
in
the
chat,
some
links,
so
Santosh
I
think
drove
a
whole
bunch
of
additional
fields
which
is
capturing
so
effectively.
This
new
set
of
semantic
conventions
for
browser,
name,
user,
agent,
Brands
and
they're,
going
to
be
living
in
the
resource,
I
think,
is
what
Martin
said,
which
I
didn't
pick
up
from
from
the
original
one.
But
so
these
other
names-
and
these
are
the
skills
that
we've
broken
down.
I.
C
D
D
C
Okay,
I'm
a
little
bit
confused
about
you
know:
do
we
still
need
to
Define
this
as
part
of
the
event
or
you
know?
Is
it
assumed
that
it'll
all
be
there
because
of
that.
D
Yeah
so
I
I
think
it's
worth
noting,
but
then
in
the
description
you
can
say
maybe
link
to
this
and
say
it'll
be
there
as
part
of
the
resource.
So
we
don't
have
to
go
and
Define
it.
But
we
know
it's
going
to
be
present
when
the
event
when
the
event
is
received.
D
C
So
I
guess
this
is
the
first
thing
that
I
was
talking
about
the
browser
brand
yeah
and
then
the
user
agent,
okay.
Well,
that
makes
sense.
Yeah.
D
The
brands
is
a
little
different
to
our
name.
If
you
passed
the
name
on
the
quiet
this.
This
is
just
the
the
API.
It
gives
you
the
full
list
of
Brands,
so
you've
always
got
not
a
brand.
You've
always
got
a
dummy
one
in
there
like
that
one's
Chrome
for
Edge,
you
still
have
Chrome
and
then
the
version
number
and
then
they'd
say
Edge,
and
then
the
version
number
and
likewise
Safari
I,
think
is
the
only
other
one
that
implements
brands
at
this
point.
D
I
see
personally
I
still
think
it
should
be
passed.
But
if
it's
sent
to
the
back
end,
the
back
end
can
pass
it
as
well.
C
Okay,
so
what
would
this
feel
be?
I
think
this
field
has
to
map
to
what's
in
resource
right,
basically
browser
Brands,
that's
what
I'm
a
little
bit
you.
D
Know
there
is
no
equivalent
for
name
here.
C
Do
we
want
one
or
do
we
leave
it
at
the
back
into
person,
because
I
guess,
that's
the
you
know
question
so
it
seems
like
New,
Relic
and
Microsoft
process
that
Martin.
What
do
you
guys
have
over
there?
Is
it
like
Edge
and
chrome
and.
A
Sorry
I
just
want
I
just
want
to
clarify
that,
like
we
don't
we
don't
get
the
age
user
agent
name
and
version
on
the
client
in
the
instrumentation.
We
get
it
on
the
back
end
so
right
now
we
just
basically
what
we
do.
We
just
parsed
the
user
agent
string
header
header
on
in
in
our
backend.
C
We
we
do
it
both
places.
You
know
it's
up
to
the
users
if
they
want
this
I
believe
Injection
Service
also
tests
for
parsing.
It
does
high
resolution
processing.
If
you
will,
but
that's
Laser's
Choice,
the
implementers
can
choose
whether
they
want
to
capture
the
clients
out
of
the
banking.
D
Correct
yeah,
it's
part
of
the
freezing
there.
There
is
some
stuff
you
can
only
get
on
the
client
unless
you,
unless
the
back
end
requests
the
extra
headers.
B
D
So
yeah
so
I
think
we
have
a
mismatch
here
and
that,
where
you've
got
all
four
of
us
on
the
one
line,
I
think
it's
actually
two
separate
things,
because
we
also
capture
the
user
agent.
But
we
do
that
via
the
header
as
part
of
the.
C
B
C
That
makes
sense,
okay
and
I.
Don't
know
how
to
say
the
resources
already
have
it
and
stuff
I'm
still
gonna,
digesting
business
stuff.
So
Lev
you
had
the
thoughts
on
how
they
can
capture
this.
Do
you
want
to
tell
me
what
we
should
do
here.
D
C
D
Yeah,
that's
that's
passed
from
the
UI,
so
I
think
there
was
in
the
old
ones.
It
was
like
process
run.
Time
was
trying
to
capture
the
version,
doesn't
even
remember.
A
There's
I
mean
there
is,
there
is
yeah,
there
is
process,
runtime
version,
I
think
that's
that's
currently
taking
the
whole
user
agent
string.
A
D
Well,
it
is
but
isn't
this
is
from
our
perspective
and
likewise
with
the
the
name.
There
is
no
problem
here
in
these
attributes.
D
Well,
the
the
name
of
the
browser
so
effectively
the
brands.
You
know
all
the
passing
on
the
client,
so
we
we
have
the
additional
version.
So
we
we
pull
apart
the
brands
and
or
the
user
agent
to
identify
the
browser
name
and
version.
D
So
yeah
it
can
be
done
because
the
brands
is
just
the
the
new
browser
API.
It's
not
not
present
on
every
browser.
So
it's
only
chromium,
Safari
I.
C
Don't
yeah
we're
gonna
have
a
look
so
so
what
is
the
plan
for
the
you
know,
older
browser
supported
older
browser
where
the
plans
is
not
available.
C
C
C
D
Yeah
Oprah
is
it
so
it's
Edge,
Chrome
and
Oprah
are
the
only
three
browsers
that
can't
Implement
brands.
C
Okay,
I'm,
gonna
and
I
I.
Think
it's
better
to
you
know
strike
out,
but
you
know
put
a
comment
like
Martin
Luther
King,
you
don't
have
a
doctor
entry
decline,
resources
are
already
going
to
have
it
and
vendors
can
do
whatever
they
need
to
do.
You
know
pick
up
the
right
item
from
the
resource
and
send
it
if
you
want.
C
Okay,
if
somebody
could
drop
a
link,
yeah.
C
A
C
C
Okay,
this
is
something
that
I
believe
everybody
needs
if
we're
all
negative,
and
we
can
just
Define
that-
and
you
know,
move
on.
C
That's
a
so
I
can
talk
about
our
logic.
You
know
it
seems
still
there's
more
things
here,
using
local
ID,
app
ID
and
look
how
these
are
the
fields
that
you
could
I
mean
not
look
at
these
three
IDs
local
ID
is
what
is
available
in
the
browser.
It
could
be
a
random
good
or
sort
of
cookie
or
something
like
that.
But
you
know
we
have
some
special
cookie
names
that
we
look
for
and
everything
that'll
go
to.
Local
ID
and
auth.
C
Id
is
if
that
user
is
authenticated
by
the
ingesting
service
like
aad
auth,
or
something
we'll
pick
up
that
ID
that
will
go
to
app
and
the
backend
will
ultimately
promote
one
of
these
ideas
to
use
the
dot
ID.
The
end
is
it's
either
Anonymous
or
signed
in
user.
Id
goes
in
there.
F
But
what
what
about
pii
concerns.
D
Yeah,
let
me
jump
in
that,
so
the
user
ID
is
a
random
good
that
we
drop
into
a
cookie
and
last
but
for
a
year.
So
that's
that's
how
we
identify
whether
the
same
person
came
back
across
multiple
sessions
that
doesn't
identify
the
person
at
all,
so
local
and
the
auth
ID
are
up
for
the
user.
We
don't
grab
those
by
default.
D
So
if,
like
the
application
provider
wants
to
drop
in
the
email
and
whatever
else
that's
entirely
up
to
them,
we
don't
restrict
what
they
can
put
into
those
fields.
Okay,.
F
So
and
yesterday
T2
suggested
using
the
service.instance.id,
you
know
I
think
I
feel
it's
it's
a
duplicate
of
that,
so
we
could
use
either
of
these
two.
E
A
A
So
do
you
think
that's
more
equivalent
to
like
a
session
ID.
C
I
know
I
was
going
to
say
it's
not
efficient,
ready,
yeah,
it
could
live
for
longer.
It
could
live
longer
than
a
question,
but
usually
these
come
from
quickly.
We
drop
a
cookie
when
we
see
the
user
for
the
first
time
we
drop
a
cookie
and
then
the
cookie
has
a
TTL
whatever
for
us
it's
one
year.
A
lot
of
people
will
have
them
for
six
months,
a
month
a
week
whatever,
but.
E
C
Correct
I
agree,
but
I'm
saying
there
will
always
be
a
session
also.
So
there
is
a
session
and
then
on
top
of
that
overlapping
that
continues
Anonymous
users,
and
then
they
could
do
persistent
applications.
Two
separate
Concepts.
They
sound
similar.
E
E
C
B
I
guess
the
question:
yes,
oh
sorry,
go
ahead!
Movie,
no
I
was
going
to
say
yeah
I
think
we
probably
want
to
call
it
something
different
than
user
ID,
because
I
think
folks
will
want
to
actually
potentially
send
a
user
ID.
That
means
something
in
their
system
as
the
user
ID
so
yeah
this.
This
feels
different
to
me.
C
Right
we
talked
about
agent
diary
yesterday.
That's
the
service
idea
or
something
like
that
right,
right,
I,
don't
know
where
it
went.
A
Just
for
reference,
I
I
pasted
a
link
to
in
the
chat
there's
there
are
some
existing
semantic
conventions
for
ident
user
user
identity.
B
D
D
Yeah
you
keep
getting
muffled
around
again.
Where
am
I
can
get
on.
C
C
Feel
free
to
directly
drop
it
into
the
Excel
spreadsheet
yeah.
C
I
guess
that's
the
thing
that
I
highlighted
we
can,
you
know,
go
through,
you
know
other
things.
What
we
did
before
was:
let's
what
if
we
can
scan
this
spreadsheet
and
then
you
know
people
can
pick
items
to
discuss
or
what
we
had
done.
You
know
what
we
could
do
is
pick
a
vendor,
remove
the
blanks
and
start
going
through
things
that
have
not
been
mapped.
F
I
I
want
to
ask
one
question,
so
this
is
related
to
you
know
one
of
the
earlier
topics.
You
know
you
probably
discussed
before
I
joined,
which
is
you
know,
representing
the
Fetch
and
the
xhr
spans
in
the
same
event,
type.
F
Oh,
is
it
okay,
so
for
events
we
have
an
event
name
that
identifies
you
know
what
event
you
know
that
that
object
represents
yeah,
I.
Think.
F
Yeah
yeah,
okay
yeah,
so
for
spans
it
is
a
little
confusing.
What
we
should
use
there
is
a
name,
but
there
is
name
is
not
part
of
the
semantic
conventions.
So
so,
if
we
it's
it's
a
good
idea
to
use
the
same.
F
F
C
F
Just
that
not
just
that
I
think
we
are
I
thought
you
want
to
combine
the
line
12
and
line
14
into
one.
That's.
C
How
I
understood
that's
that's
true,
so
I
examined
the
fetch
and
Etc
timing,
things
as
they
were
documented
here
they
looked
awfully
similar,
hence
yeah
yeah
yeah.
F
No,
that
is
valid,
I
think
I
also
feel,
and
it
can
even
be
combined
with
the
line
file.
The
the
document
load
span
that
exists
today.
The
document
fetch
here,
it's
called
as
page
fetch,
so
so
there
is
definitely
some
commonality
there.
F
The
rest
API
calls,
but
you
know
the
browser
has
different
apis
for
each
of
them,
so
there
they
have
different
names,
so
we
could
have
three
different
event
types,
but
given
that
they
are
the
same
are
similar,
you
know
only
difference
is,
is
the
type
we
could
introduce
a
type
attribute
that
tells
us.
You
know
what
it
is
about.
C
I
think
I
I
think
that
makes
sense.
Would
you
then
expect
to
have
type
for
these
well-defined,
unique
events
also
like
say
impression
or
page
view.
F
So
I'm
speaking
purely
from
a
hotel
perspective,
where
we
will
have
both
event
and
spans
separately.
B
F
For
events,
there
is
a
mandatory
type.
You
know
it's
called
as
name,
whereas
for
spans
there
is
no
such
mandatory
field.
There
is,
there
is
a
name,
but
the
name
is
not
part
of
semantic
convention.
So
if
we
decide
to
use
name,
maybe
you
know
we
can
just
say
you
know
what
type
of
span
it
is.
You
know
it
is
determined
by
the
name
of
the
span.
E
There
is
specifications
over
the
span
name
and
if
you
look,
if
you
open
up
the
HTTP
client
semantico
mentions
it
argument,
is
that
in
most
cases
the
span
name
should
be
hcp
method.
Name
what
for
distinguishing
like
what?
What
cost?
It's
recall,
I
think
it's
better
to
use
the
different
instrumentation
Scopes
feature.
F
Yeah
instrumentation
scope,
also
I
I,
have
a
same
concern.
I
think
it
is
not
like
what
guarantees
that
you
know
the
value
doesn't
change
in
future,
so
so
both
the
name
span
name
and
the
instrumentation
scope
name
we
are
talking
about
the
values
of
you
know
that
that
parameter
and
the
values
today
is,
is
not
very
well
represented
in
semantic
conventions,
or
maybe
we
could
add
it
now.
You
know
I
think.
F
D
So,
probably
for
context
I'm
guessing
Ram,
it
sounds
like
Santosh
uses
event
type.
The
same
way
we
use
event
name,
we
use
the
name
peel
so,
which
is
where
we
Define
exactly
the
base
type
so
we'd
say
we're
like
remote
dependency,
page
view
data
page
performance
data,
so
maybe
they
should
be
lined
up
with
something
similar.
F
Yeah
so
Tito
I
think
I'm,
looking
at
the
name,
HTTP
name
but
I
think
this
guideline
to
me.
It
feels
like
it
represents
something
Dynamic,
whereas
what
I'm
talking
about
is
is
going
to
be
static.
E
Static
value
from
just
the
instrumentation
type
or
you
could
also
use
stage,
reputation,
scope,
scope
or
spec
URL,
where
you
can
Define
that
this
instrumentation
follows
this
semantic
convention.
F
Okay,
yeah
I
think
if,
if
we
are
able
to
get
the
values
of
the
scope
on
scope,
name
added
to
the
semantic
conventions,
then
then
that
that
is
good
too
I'm
only
worried
that
in
in
future,
what
if
these
things
change.
D
Coming
back
to
my
comment,
so
I
thought
the
reason
that
the
event
has
a
domain
and
a
name
was
so
that
it
would
uniquely
identify,
and
that
would
replace
both
our
name
field
as
well
as
your
event,
exactly
yeah.
So
in
this
particular
case,
it's
like
the
domain
potentially
is
browser
and
then-
and
the
name
is
page
view
in
the
case
of
the
the
fetch
of
the
xhr
and
the
resource
timing.
For
the
page
view,
the
fetch
in
the
xhr
would
definitely
be.
D
You
know
something
like
you
know,
Ajax
call
or
remote
dependency,
or
you
know
something
that
represents
that
name
in
terms
of
the
resource.
Timing.
For
the
page
view,
I
I,
think
that
is
separate,
but
it
is
related
to
the
resource
timings
that
you
would
that
you
would
want
to
capture
from
you
know
your
CSS,
your
images,
as
well
as
the
the
Ajax
models,
so
I
I
think.
F
Yeah
I
think
for
events
for
events.
I
signal,
I
I,
see
it's
simpler.
It
there
is
Clarity
I'm
I'm
talking
about
spans
or
spans.
How
do
you
represent
the
type
and
tattoo
is
suggesting
to
just
use
span,
name
or
the
scope
name
and
and
that
scope
name.
C
Seems
like
I
I
know
again,
you
know
I'm
not
really
familiar
with
those
just
yet
scope
name
seems
like
the
right
thing
to
do.
Is
pan
name
sounds
like
an
occurred
me
if
I'm
wrong,
it's
the
actual
URL
right.
You
know
that
you're
making
a
call
to
or
whatever
that
doesn't
sound
like
the
thing
that
we
want
to
use.
C
If
you
want
to
say
I'm
fighting
two
two
spans
one
for
fetch
another
one
for
you
know
whatever
you
know
actually
chart
two
separate
things.
Actually,
let
me
just
go
back
here:
yeah
I'm,
fighting
two
spans
one
for
page
page
another
one
for
page
navigation,
santosh's,
request
in
a
requirement
is
that
it's
both
of
them
are
going
to
look
like
spans
and
how
do
I
know
one
is
a
page
navigation.
Another
one
is
a
page
fetch
fan
span.
C
I
would
expect
page
navigation
span
to
be
the
exact
same
shape,
or
you
know
the
little
the
same
way,
irrespective
of
which
browser
they
fired
from
which
application
they
are
fired
from
right.
Santosh
yeah,
if
you
use
span
name
it'd,
be
different.
If
I
fire
up
my
browser
and
I
do
something.
My
spam
could
be
I
could
be
requesting
page1.htm.
That
could
be
the
URL.
That's
occurs
in
the
span
name
and
somebody
else
will
be
different,
but
we
want
them
to
be
the
same.
C
It
could,
but
do
we
want
to
do
that?
It
doesn't
sound
like
the
right
correct
place
to
do
it.
I
think
it
should
be
this
other
sorry,
I'm
I'm
still
not
really
familiar
with
those
names,
the
other
one
whatever.
That
thing
was
not
not
the
stand
name,
the.
D
C
C
D
There
there's
a
sub
question
there
of
in
terms
of
the
resource
timing
for
said
Fetch
and
xhr.
Do
we
want
to
have
that
included
in
the
event,
or
do
we
want
to
have
that
as
a
separate
event
like
the
resource
timing,
one
today
we
have
that
as
an
optional
inclusion
of
the
existing
single
event,
but
we
have
to
wait
before
we
can
capture
that,
because
it's
not
available
immediately
after
the
Fetch
and
xhr
call
returns
good.
C
Question
everybody
is:
is
that
is
that
going
to
fit
for
when
we
get
to
this
this
tab
and
start
discussing
that
event.
C
All
right,
I
I,
would
suggest
we
table
it
until
then
sounds
like
we
have
an
answer
for
this.
What
what
I've
heard
you
know
again
my
opinion,
including
that
also
a
single
event
for
representing
both
unless
they're
vastly
different
Santosh.
You
seem
to
think
they
are
two
separate
against.
F
I
like
it,
but
the
question
is:
how
do
you
like
you,
you
need
to
introduce
an
attribute
telling
you
know
which,
which
type
it
is
so.
C
You
really
want
to
know
what
mechanism
technology
was
used
to
make
the
remote
call.
That's
basically
it
that's
the
requirement
yeah
yeah,
that
that
yeah,
that
could
be
a
fee
yeah.
F
Keeping
it
in
one
event
simplifies
from
a
maintenance
perspective.
C
D
C
Okay,
okay,
it's
done
I
hope
Ruby
is
still
here
again.
You
know
the
participants
and
stuff.
C
I
may
have
a
little
bit
more
clarity.
What
I
wrote
as
I'm
going
to
go
through
the
schema
and
then
I
did
this?
Can
you
confirm
if
this
is
right.
C
C
Would
you
you
know
if
you
don't
mind,
can
you
add
these
things
as
small
descriptions
under
these
events?
That's
good,
okay,
but
thanks
for
clarifying
it
now,
that's
what
I
did
when
I
when
I
transferred
over
this
information
to
the
Excel
spreadsheet,
so
that
validates
it
foreign.
C
One
more
question
was
so
that's
good.
A
C
I
think
I
think
we're
at
a
point
where
we
can
stop
anyway:
yeah
yeah,
okay,
I,
just
wanna.
A
Okay,
I
just
wanted
to
clarify
in
case
you're
wondering
like
you
know
you
didn't
know,
there
were
two
meetings
happening
and
you're
wondering
which
one
to
go
to
the
this.
This
Wednesday
meeting
continues
continue,
continues
to
be
the
primary
Sig
meeting.
So
here's
if
you
wanna,
just
if
you
just
want
to
get
and
and
high-level
update
on,
what's
going
on
which
things
are
being
worked
on.
This
is
the
meeting
to
go
to.
A
Also,
if
you
have
any
any
other
topics,
bring
the
discussion.
This
is
the
meeting
to
go
to
and
there's
also
a
Tuesday
meeting
at
9
00
a.m.
Pacific,
and
when
we,
when
we
work
on
a
project
that
has
this
kind
of
level
of
discussion,
then
we'll
produce
both
meetings
too,
to
make
it
faster.
C
Yeah,
thanks
for
clarifying
appreciate
it
cool
thanks
everybody
for
joining
on
the
greatest
questions,
we'll
hope
to
see
you
guys
next
week
to
continue
this
and,
in
the
meantime,
feel
free
to
add
details
to
the
doc.
As
you
discover.