►
From YouTube: 2022-05-17 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
Well,
so,
should
we
talk
about
the
the
semantic
conventions
for
events
or
do
you
have
any
other
any
other
agenda
items.
A
A
You
know
available
as
a
signal
overall
to
the
to
all
the
domains.
So
anything
that
we
do.
You
know
it
has
to
be
anything
that
we
propose
has
to
be
generic
enough,
so
we
might
have
to
get
feedback
from
others
as
well
and
unfortunately,
in
the
log
sig,
I
don't
see
any
representation
from
anyone
else
looks
like
you
know.
A
We
are
the
only
ones
asking
for
it
at
the
moment
and
therefore,
a
tigran
is
leaning
towards
restricting
the
logs
api
to
support
just
our
use
cases
right,
but
I
see
there
are
other
at
least
one
or
two
examples
I
know
for
sure
where
they
are
generating
events
using
log
records
and
they
are
not
following
any
conventions.
A
So
my
concern
is
that
tomorrow,
when
any
type
of
events
you
know
when
they
are
processed
by
a
telemetry
back
end,
it
is
not
always
possible
to
have
or
not,
everyone
is
going
to
have
separate
backend
systems
to
process
ram
events
separately
from
you
know,
other
type
of
events,
so,
in
my
opinion,
I
think
we
should
strive
to.
A
You
know:
keep
this
uniform
across
all
domains,
at
least
in
the
spec,
so
that
you
know
there
is
consistency.
B
B
If
no,
I
think
my
kind
of
feeling
is
that
you
probably
need
guidance
from
tigran
or
like
the
someone
from
tc
or
dtc.
A
I
I
think
more
than
them,
I
think
we
need
to
also
talk
to
our
backend
teams
to
see
how
they
process
events.
What
are
the
you
know,
plans?
You
know
roadmap,
and
you
know
their
architecture,
how
you
know
these
things
will
fit
there
in
the
long
term.
B
Yeah,
I
can
I
can.
I
can
imagine
like
if
you
know
if
it
was
really
difficult
to
to
define
like
a
generic
events,
api
or
events
mechanism
like
we
could,
we
could
potentially
just
build
like
a
browser
or
client
client
events
api.
A
We
can
do
that
even
now.
Is
that
a
you
know
a
good
thing
in
the
long
term?
I
think
the
the
problem
really
is
that
you
know
it.
It
certainly
isn't
an
area
of
focus
for
a
lot
of
these
guys,
but
you
know
at
some
point
it
you
know.
A
I
think
it
I
I
I
may
not
be
using
the
right
words,
but
there
is
certainly
you
know
more
focus
on
the
back
end
telemetry
than
the
you
know
the
client-side
telemetry
right.
I
think
it
can
be.
It's
obvious
that
no
one
has
this
project
has
been
going
on
for
two
to
three
years
now,
and
the
client
side
telemetry
has
you
know
is-
is
more
serious
now
I
I
know
that
the
traces
has
been
there.
A
A
C
Microsoft
doesn't
know
we
effectively
looked
at
it.
It's
the
current
implementation
is
way
too
big.
Yeah
yeah
we've
tried
several
times.
We
had
an
intern,
try
causing
the
intern
to
bail,
because
it
was
just
so
bad,
and
then
I
tried
at
the
end
of
last
year
and
it's
still
nowhere
near
ready.
I
think
dinosaurs
have
done
something
in
terms
of
wrapping
and
I
think
it
is
amazon
yeah
and
the
splunk
yeah.
I
think
they
they've
done
some
stuff.
C
Like
I
know,
bart
from
the
javascript
group
was
the
only
other
person
doing
something
with
browser,
and
there
is
some
stuff
in
there
that
he
added
like
the
document
load,
which
effect
is
one
of
our
events,
where
he
just
effectively
created
a
zero
length
span
and
stuffed
an
event
in
there.
So
but
yeah
circling
back
to
what
santosh
is
saying,
I
think
what
we're
looking
at
is
really
just
a
generic
api,
which
is
like
create
an
event,
and
the
semantic
conventions
are,
I
think,
should
be
really
saying.
C
Well,
these
are
the
set
of
known
events,
and
this
is
what
those
events
look
like,
so
that
in
the
future
we
can
add
more,
which
are
you
know,
client
that
you're
not
necessarily
client-side
events
but
server-side
events
if
they
want
to
do
it.
That
way-
and
I
know
I
mentioned
a
couple
of
them-
we
have
our
semantic
conventions,
which
we
call
common
schema
internally
in
microsoft
and
that's
for
both
front
and
back
end.
C
I
didn't
get
to
the
document
before
I
went
on
holidays
and
then
I
was
driving,
so
I'm
really
only
just
catching
up
on
emails
now,
so
hopefully
I'll
get
to
that
this
week,
and
I
can
start
to
you
know,
bring
some
of
that
commonality,
and
I
did
briefly
look
at
the
doc,
but
it
was
like
you
know,
10
minutes,
and
that
was
I've
been
I've
done,
like
you
know,
600
miles
of
driving
since
then,
so
my
head's
a
little
bit
not
there.
A
Okay,
actually
in
the
api
spec
for
logs
api,
to
create
events-
I
I
don't
know
if
you
got
a
chance
to
review
the
document
so
far
I
I
was
thinking
of
only
you
know
these
few
methods.
C
When
you
think
we
talked
about
the
meaning
so
yeah,
so
so
what
I'm
saying
is
the
stuff
martin's
working
on
from
the
semantic
convention
for
events
is
saying.
Well,
when
we
say
the
event
name
is
this:
this
is
what
we
expect
the
attributes
to
be.
A
Yeah
but
then
you
know
there
was
one
other
concern.
Someone
else
raised
was
that
you
know
the
semantic
conventions.
You
know
you
are
relying
on
people
to
use
them
correctly
right.
There
is
one
other
approach.
An
alternate
approach
would
be
to
actually
break
it
in
the
api.
So
if
any
of
those,
let's
say
you
know,
every
event
is
categorized-
is
identified
by,
let's
say
two
parameters,
event
name
and,
let's
say
event
category
just
for
the
sake
of
discussion.
A
C
Yeah,
I
don't
think
that's
necessary
and
for
a
browser
you
want
to
limit
the
api
size.
You
can
build
stuff
on
top
of
this
and
say:
okay,
I
want
to
have
a
categorized
event
and
therefore
the
categorized
event
picks
the
category
and
then
but
internally,
talks
down
to
this,
like,
for
example,
in
app
insights,
everything
boils
down
to
a
single
event
called
track,
so
everything
calls
track
and
it
just
takes
an
object,
which
is
an
interface
definition
that
says
it
should
look
like
this,
and
then
we
have
helper
methods
on
top
of
that.
C
D
D
So,
for
instance,
you
call
it
log
exception
here
I
would
call
it
repot
error
and
pass
in
a
throwable
so
and
what
you
basically
do
is
fill
all
the
attributes
that
you
can
fill
to
report
an
error
and
you
would
just
hand
it
off
to
log
event.
Then.
A
So
just
so
you
know
I
have
this
event
builder,
which
is
the
one
that
gives
you
low
level
access
to
set
every
individual
field
in
the
in
the
log
record,
and
and
these
are
the
convenience
methods
right.
So
if
these
are
not
sufficient,
you
know
you
will
have
to
you
know
we
can
add
more,
but
building
one
more
layer.
On
top
of
this,
I
think
is
probably
you
know.
C
C
So
I
would
see
the
event
builder
is
actually
a
layer
on
top
of
log
event.
Yeah.
A
So
this
is,
this
is
not
required
in
the
spec.
It
just
says
you
know
have
a
way
to
you
know,
create
events
and,
and
then
I
think
these
are
sufficient
for
that,
so
that.
A
Even
in
java,
I
think
the
the
only
reason
I
put
this
is
again
to
support
or
to
align
with
you
know
a
few
other
apps
that
have
seen
that
build
events
using
lock
records,
and
they,
you
know,
use
the
body
field
and
severity
field,
and
you
know,
and
and
they
are
not
using
any
apis
right-
they
are,
they
are
directly
building
it
from
the
protobuf
generated
code
yeah,
because.
A
A
So
yeah,
so
my
my
main
point
is
really:
you
know
to
ensure
that
there
is
a
unified
representation
of
events
when
the
backends
receive
it.
So
so,
if
we
feel
that
the
category
is
something
that
is
critical,
then
let's
make
it
critical.
You
know
everywhere.
C
Yeah,
I'm
I
I
don't
for
for
an
event.
I
don't
see
it
as
critical
like
in
the
only
thing
that
we
have
in
app
insights.
That
requires
a
category.
It's
a
specific
one,
where
we
have
a
diagnostic
log
where
we
say
throw
this
event,
and
then
we
have
a
category
on
that.
Everything
else
doesn't
have
a
category.
A
Is
is,
are
those
four
fields
mandatory
like?
Is
there
anything
that
what
does
like?
I,
I
wasn't
able
to
you,
know
understand
you
know
what's
being
proposed
here
like
I
know
there
are
these
four
fields
like
what
would
be
the
equivalent
in
in
this
elastic
schema
for
the
name
of
the
event.
D
Exactly
so,
those
four
fields
are
used
for
categorization
and
they're
building
up
a
hierarchical
categorization
of
events.
I
am
not
proposing
to
use
everything
of
this,
but
I
would
suggest
okay,
the
the
problem
that
we
had
is
to
distinguish
from
where
that
the
or
what
kind
of
event
is
coming
in.
So
I'm
not
sure
if
somebody
would
be
willing
to
say.
Okay,
if
we
use
event.kind
say
it's
a
ram
event
or
it's
a
log
event
and
by
default
say
it's
not
set
it's
a
log
event
we
could
distinguish.
D
A
Okay,
actually
on
the
motivation,
for
you
know
exploring
this
topic,
like
you
know,
how
do
you
distinguish
different?
You
know
event
types.
The
other
reason
is
really.
You
know,
validation
of
the
input
right,
the
concern
that
quinn
brought
up
where
in
the
client
set
limited,
the
data
is
coming
from
untrusted
sources.
So
you
don't
want
to.
You
know,
trust.
You
know
the
data
is
in
a
good
condition,
although
it's
not
going
to
entirely.
A
You
know
solve
that
that
security
problem,
but
at
least
we
can
ensure
that
the
data
is
in.
You
know
in
the
same
form.
A
So
if
we
know
that
for
each
event
type
you
know
these
are
the
attributes
to
accept
expect,
and
those
are
the
only
ones
to
you
know
expect.
Then
we
can
build
some
validation
in
the
back
end
at
the
receiver
right,
not
not
just
on
the
sending
side.
A
So
that
also
is
a
motivation,
for
you
know,
exploring
this
conventions.
E
E
Devs
are
going
to
want
to
record
very
specific
and
very
custom
types
of
events
like
if
they
have
a
specific
user
action
like
a
checkout,
for
example,
they're
going
to
want
to
create
a
special
event,
type
that
captures
that
and
that'll
have
its
own
own
structure
and
schema.
Would
so
would
this
be
able
to
handle
like
application
customization
as
well.
D
I
so
that
would
be
one
of
the
points
that
I
think
we
should
discuss,
because
if
customers
want
to
add
attributes
that
make
only
sense
to
them
and
not
to
any
of
our
backends,
we
should
be
able
to
let
the
customers
add
those
values.
I
mean
just
the
the
case
that
queen
well
is
mentioning.
D
We
call
them
business
events,
so
basically
the
customers
should
be
capable
of
creating
an
event
that
does
contain
certain
categorization,
but
all
the
other
attributes
are
freely
to
the
customer
and
we
actually
don't
inspect
the
content,
because
we
don't
know
what
to
do
with
with
all
the
attributes
we
just
understand,
which
kind
and
which
category
it's
belonging
to.
A
D
Maybe
you
would
want
to
report
the
customer
id
so
just
an
assumption,
for
let's
say
for
some
legacy
system.
It
would
be
a
long
value
as
a
numeric
value
for
a
modern
system.
It
could
be
a
uuid
which
you
transport,
a
string,
so
there
we
cannot
make
any
assumption
what
the
exact
type
is,
because
we
let
the
customer
choose
the
attribute
freely
the
value
freely
and
it's
really
difficult.
A
Okay
and
what
about
the
size?
Let's
say
you
know,
people
can
send
custom
data,
but
at
the
most
it
can
be,
let's
say
something
sufficiently
large.
Let's
say
one
kilobyte
or
two
kilobytes.
D
We
have
certain
size
limitations
in
various
places,
so
they
on
the
api.
We
say:
okay,
the
maximum
size.
If
you
stringify
it,
it
cannot
exceed
a
certain
amount
and
of
course
we
also
have
in
our
servlets.
We
also
have
max
post
body
size
requirements,
so
we
also
say:
okay,
no
agent
is
allowed
to
send
more
than
I
don't
know
the
exact
value
now,
but
let's
say
more
than
100
kilobytes
in
total,
in
one
beacon.
B
E
Having
it
specified,
our
appsec
likes
everything
to
be
validated
and
clean
as
an
extra
layer.
D
A
D
A
A
E
A
A
Yeah,
I
think
we
still
need
I.
I
still
believe
that
you
know
the
the
open
telemetry
schemas
that
I
pointed
to
in
this
thread.
I
think
that
can
be
extended.
A
Where
you
know
you
know
the
schema
can
list
down.
You
know
in
detail,
you
know
for
different
event
types.
These
are
the
attributes
expected.
These
are
the
expected.
You
know,
you
know
you
know,
data
type
size
restriction,
you
know
we
could,
you
know
not
have
there,
because
size
is
depends
on
the
back
end.
You
know
some
back
ends
might
be
okay,
accepting
larger
size.
A
The
size
you
know
could
be
an
extension
that
the
back
ends
can
choose
to
have,
but
at
least
you
know
what
parameters
to
expect-
and
you
know
something
like
that.
If
we
do,
then
that
will
help
in
that
will
even
include
even
these
custom
fields,
so
any
custom
fields
that
we
let
customers
you
know
add
those
can
also
be.
You
know.
A
Those
can
also
have
standard
names.
Standard
attribute
names
that
way
all
the
back
ends
know
you
know
what
to
expect
and
they
can
do
some
validation.
D
One
stupid
question:
what
would
happen
if
I
don't
specify
a
custom
field?
Would
the
whole
event
be
rejected
or
not.
A
Yeah,
I
think
I
I
don't
know,
I
think
it
depends
on
how
flexible
the
the
schema
definitions
would
be.
I
I
know.
C
I
I
think
we
need
to
be
flexible,
like
we
have
internal
events,
which
we
just
call
custom
events
where
we
have
one
team
on
teams
that,
during
a
phone
call,
a
single
event
will
be
greater
than
64k
and
they
have
their
own
properties
that
they
that
they
flow
through
the
system.
So
we
definitely
don't
want
to
reject
the
event,
but
it's
the
case
that
we
have
a
specific
place
for
them
to
put
these
generic
properties.
C
So
I
think
we
just
want
the
same
thing.
We
say
this
is
the
set
of
fields
and
the
set
of
properties
that
we
effectively
expect
and
control,
but
if
they
want
to
add
their
own
properties
that
flow
through
the
back
end
and
therefore,
depending
on
the
back
end,
whether
the
event
is
dropped
or
not.
So
so,
if
it
goes
to
like
our
generic
system-
and
we
happen
to
have
generic
properties,
then
it
just
flows
through
and
goes
to
whatever
their
back-end
store
is
that
they
can
then
query
but
yeah.
C
I
think
we
want
to
define
okay.
This
is
the
particular
event,
and
this
is
the
particular
set
of
fields
that
may
must
should
be
there
and
if
they
don't
match,
then
then
we
can
drop
the
event.
But
I
I
still
think
we
need
that
flexibility,
and
I
guess
I
I
talk
about
a
couple
of
times,
but
in
terms
of
like
the
kind
category
type
for
all
our
stuff,
both
internal
and
external.
C
We
just
base
that
on
the
name,
so
that
the
name
defines
whether
it's
a
fixed,
unknown
event
versus
when
the
when
the
app
wants
to
create
their
own
custom
event,
and
they
eventually
call
track,
but
the
name
they
give.
It
is
just
their
own
and
it
just
flows
through
the
system
and
we
effectively
don't
validate
that
and
it
just
ends
up
in
a
cosmos
data
entry
that
they
query.
B
I
also
would
say
about
that,
like
it
seems
to
me
like,
like
these.
These
categorization
fields
are
more
like
hints
to
the
elastic
ui
like
so
you
can.
B
You
can
group
or
visualize
things
based
on
these
buckets,
so
it's
like
an
easy
way
to
to
give
hints
to
the
to
the
back
end,
whereas
I
think
open
telemetry
has
taken
kind
of
the
approach,
at
least
so
far
with
the
semantic
conventions
that
you
know
you
can
you
know
the
the
different
different
namespaces
of
attributes
are
composable,
so
you
can
you
know
if,
if
the
event
is,
you
know,
I
don't
know
like
http,
but
it's
also
has
an
error
so
like
it
can
have
both
sets
of
attributes
right.
B
So
you
can
so
you
can
based
on
just
like
the
presence
again
like
you
can
kind
of
infer
like
what
kind
or
what
category
it
is.
A
A
Initially,
you
know
one
for
routing
to
the
you
know
from
specific
back
ends
and
then
maybe
third,
one
is
to
really
you
know,
do
something
specific
to
that
event.
Type.
A
So
maybe
the
first
and
the
third
are
equivalent,
where
you
know,
depending
on
the
specific
event
type,
you
know
you
would
do
the
validation,
so
the
first
and
the
third
are
same
so
so
you
need
one.
A
You
know
mechanism
to
say
this
is
a
rum
event,
so
that,
hopefully
you
know
we'll
have
it
at
the
resource
level.
Then
it
essentially
boils
down
to
you
know.
Just
one
is
enough
right.
One
attribute:
do
we
really
need.
B
Yes,
I
was,
I
was
wondering
about
that.
Actually,
so
if
for
like
for
routing
of
these
events
like,
if
you
want
to
say
like
okay,
I
wanna-
I
don't,
I
wanna
I'm
processing
events
on
the
back
end
and
I
I'm
going
event
by
event,
and
you
know
I
wanna
see
like
if
it's
a
browser
event.
Is
it
possible
that,
like
you,
would
get
a
batch
of
events,
that's
from
multiple
different
domains.
A
No,
we
we
need
that
right.
We
need
that
and
so
far
you
know
these.
The
answer
we
have
been
told
is,
you
know
I
use
either
the
scope
or
something
at
the
resource
level.
There
will
be
a
resource
attribute
that
will
define
that
hey.
This
is
coming
from
browsers,
so
that
that
itself,
you
know,
should
be
sufficient.
A
Yeah,
when,
when
generated
at
the
source,
when
you
know
coming
on
the
wire,
but
eventually
in
the
back
end,
I
think
the
resource
attributes
will
flow
down
to
the
you
know.
The
events.
C
C
You
know
that
that's
one
potential
definition
for
effectively
just
say:
open,
telemetry
sports
thing
and
you
can
have
a
custom
event
specifically
for
ecs,
and
then
that
would
depend
on
the
vendors
whether
they
effectively
support
consuming
that
particular
event
and
therefore
they'd
translate
it.
C
But
I
think
from
hotel's
perspective,
we
just
wanted
to
find
a
standard
set
of
events
that
are
generally
shared
across
the
board,
with
all
these
different
environments,
rather
than
define
every
single
event
like.
I
don't
want
to
go
into
the
the
process
of
saying
this
is
a
web
page
viewer.
This
is
a
mobile
page
viewer
there.
This
is
a
c-sharp
client
page
view
event
like
that's
just
silly.
C
We
just
have
a
page
view
event,
and
then
we
have
the
optional
fields,
but
you
still
want
the
flexibility
of
you
know
being
able
to
have
custom
events
which
are
both
defined
by
vendors
as
well
as
applications.
So
you
could
say
we
define
anything
app,
that
dot
could
be
an
application
event
and
therefore
we
don't
think
back
end
should
not
apply
rigorous
validation
to
it.
D
A
A
So
so
that
namespace
is
completely
like
there
are
no
conventions,
you
know
people
can.
I
mean
there
are
no
guarantees,
anybody
can
use
it
in
any
form.
A
So,
by
the
way
in
my
original,
you
know
this
api
spec.
I
also
had
this.
You
know
third
approach
of
you
know
having
a
separate
event.domain
in
addition
to
event
name
because
in
the
in
the
event
name,
we
would
typically
need
to
prefix
with,
let's
say,
browser
or
mobile
or
something
right,
but
now
I'm
thinking
you
know
the
resource
identifies
the
domain
anyway.
So
we
really
don't
need
to
to
do
anything
separate.
You
know
whether
the
event
name
has
the
domain
as
a
prefix
or
not.
A
A
Okay
and
the
resource
level
domain,
plus
the
event
name,
this
combination,
you
know,
is
supposed
to
be
unique
and
any
validations
that
we
define
will
be
against
these.
B
So
then,
so,
like
you
have
you'll,
be
able
to
detect
like
this,
the
type
of
source
based
on
the
resource
and
then
then
the
event
name
itself
could
be.
A
Whether
it
has
a
prefix
or
not,
you
know
we
don't
care.
B
Yeah
no
prefix,
so
it
could
be,
it
could
be.
It
could
be
a
generic
kind
of
type
of
event,
like
exception
exception,
that
has
semantic
conventions
that
apply
to
all
to
all
platforms
and
or
it
could
be
like
if
I
don't
know
like
this
is
like
where
we
get
into
details
like
where
maybe
like
a
certain
type
of
event
only
applies
to
browser.
B
A
B
So
like,
if
let
me
let
me
actually
share
my
shared
doc,
really
quick
that
I
put
together
yesterday,
based
on
the
discussion,
we
had.
A
Actually,
it's
the
other
way.
I'm
saying
that
the
domain
is
to
be
identified
from
an
attribute
in
the
resource
and
with
that
you
again
don't
need
any
additional
qualification
in
the
event
name
to
determine
the
domain.
A
A
A
We
wanted
to
use
the
device
namespace,
but
the
device
is
so
generic
that
it
there
can
be.
You
know
backend
systems
too,
that
would
use
the
term
device,
so
we
could
use
mobile,
but
I
don't
remember
now:
maybe
we
could
use
mobile,
but
I
think
there
were
some
concerns
with
that
too.
So,
assuming
that
we
identify
some
name
space
for
each
of
the
domains,
then
the
domain
is
identified
at
the
resource
level
right,
you
again
don't
need
at
the
span
and
the
each
signal
level.
C
Are
you
saying
that
page
view
plus
domain
defines
what
fields
yeah
so
so
really
it
comes
down
to
we're
indirectly
defining
that
combination,
whether
whether
you
say
name
plus
domain
or
the
main
plus
name
doesn't
really
matter
it's.
The
combination
of
both.
F
B
A
The
same
name,
the
problem
is
the
same
event.
Name
could
belong
to
multiple.
You
know,
domains
right,
like
you
know,
on
the
mobile
on
the
browser
on
the
in
you
know,
coming
from
a
iot
device
coming
from
a
back-end
server,
kubernetes
events.
So
if,
let's
say
to
avoid
any
name
conflict,
you
still
need
to
qualify
with
the
with
the
domain.
C
Yeah,
a
set
of
sorry
command,
define
a
set
of
qualified
events.
Like
I
think
last
time
we
spoke
about
this-
that
I
recall
we
were
talking
about
interactive
events
like
interactive
events,
are
shared
across
multiple
different
things
like
you
know,
a
click
event,
for
example.
C
Well,
just
what
we've
got
on
the
screen
check
out
button
click.
So
it's
a
case
of.
Do
we
really
want
to
drill
down
and
say
a
a
click
event
on
on
the
web
versus
quick
event
on
a
mobile
versus
click
event
in
a
windows
app
versus
a
click
event
in
an
ios
app?
C
I
don't
think
we
want
to
go
that
deep.
I
could
potentially
see
we
say.
A
click
event
has
these
set
of
attributes
and
optionally.
If
you
specify
the
domain,
you
may
also
include
these
other
fields
for
that
domain.
Maybe
I
can
see
that,
but
I
don't
think
we
want
to
make
that
the
norm.
I
think
we
want
to
try
and
say
this
is
a
this
event
means
this
thing
and
it
is
used
across
multiple
environments,
and
hopefully
we
define
what
they
are.
B
Yeah
I
mean
it's
like
in
in
this
example
that
I'm
look
that
I'm
looking
I
I
I
was
listing
these
examples
and
I
actually
listed
them
as
I'm
looking
at
a
click
event,
and
maybe
like
maybe
like
the
semantic
conventions
like
for
the
namespace,
could
be
just
interaction.
B
You
know
it
could
be
just
click,
it
could
be
just
interaction
or
like
if
you
find,
if
you
find
that
there
are
many
there,
there's
not
much
overlap
between
the
types
of
fields
between
different
types
of
clients.
Then
it
could
be.
You
know
it
could
be
something
like
this
like
a
browser,
interaction
namespace,
but
I
think
you
know.
I
agree
that,
like
we
should
try
to
make
the
effort
of
of
defining
the
name
spaces
so
that
they
can
be
shared
across
different
types
of
clients.
B
B
I
don't
I
don't
necessarily
propose
that
we
do
one
or
the
other.
I
just
wanted
to
put
it
down
for
discussion.
You
know
one
thing
that
came
up
yes
came
up.
I
think
in
our
previous
discussions
I
think
ted
mentioned
it.
I
think
if
I
understood
his
his
kind
of
proposal
correctly,
I
think
he
was
he
was
actually
proposing
that
we
that
the
event
name
is
more
like
just
something
that
the
the
end
user
could
define.
That's.
B
B
I'm
not
sure
I
actually
I'm
not
sure
that
we
want
to
do
this,
but
I
wanted
to
put
it
down.
I
think
the
option
that,
like
I
hear,
is
probably
probably
leaning
towards
is
have
like
an
event
name
attribute
that
that
has
some
kind
that
actually
defines
the
type
of
the
event.
So
you
can
you
can
look
at
the
value.
You
know
what
type
of
event
it
is
and
then,
based
on
that
you,
you
know
like
which
additional
fields
to
look
for
right.
B
B
And
then
then
you
know
I
just
went
through
some
other
examples.
Like
you
know,
I
don't
know
like
if
tigran
had
this
in
mind
that
just
the
presence
of
of
like
the
the
you
know
like
the
name
space
would
mean
that
it's
that
it's
an
event.
B
And
then
you
know
like
if
we
and
then
like,
I
have
like,
for
example,
number
five.
I
have
you
know.
Instead
of
having
like
a
generic
event,
name
attribute,
you
would
have
like
you
could
have
like
a
domain
specific
like
a
browser
event,
name
or
mobile
event.
Name
again,
I'm
just
listing
it
down
because
I
don't
know
like
if
everyone
else
that
we
talk
to
like
tigran
and
ted.
If
they
have
different
ideas
about
this.
So
but
in
my
mind
I
think
option
two
is
probably
the
one
that
I
would
recommend.
C
For
me,
yeah,
I
think
after
ocean
2
gives
us
the.
I
think,
the
greater
flexibility
in
terms
of
what
the
event
name.
Is
that
that's
what
we
get
to
define
like?
I,
I
wouldn't
want
to
say
browser
underscore
interaction,
but
I
prefer
to
have
a
generic
interaction
one,
but
that's
the
semantic
adventures
of
the
event
itself,
not
for
the
event
api,
yeah.
B
A
So,
martin,
I'm
thinking
that
we
would
put
it
this
way
in
the
at
least
in
the
api
specs
right
for
events,
which
is
all
events,
have
have
a
have
a
name,
and
you
know
only
along
with
only
in
the
context
of
a
resource.
You
know
they
are
unique
right
and
you
know-
and
you
know
that
that's
what
the
spec
will
probably
say
and
the
validation,
I
think.
Maybe
we
will
just
create
an
issue
on
github
to
be
taken
up
separately.
A
Where
we
extend
the
you
know
the
the
schemas
concept,
you
know
to
enable
validation
in
the
back
end
and
and
and
then.
A
Leave
it
at
that
and
and
then
I
think
your
example,
two
you
know,
fits
in
that
model,
anyways
right
where
you
know,
whatever
event
name,
you
are
you're
going
to
have
the
set
of
attributes
that
are
associated
with
that
specific
event.
Name,
you
know,
will
be
listed
in
in
in
your
other
document
right
where,
for
each
even
type
you
these
are
the
attributes
yeah.
A
B
A
I
don't,
I
don't
fully
understand
why,
so
when
you
say
the
browser
interaction
has
those
type
element
and
all
that
I
think
that
is
just
an
example
right.
You
know
what
so
so
those
are
again
a
set
of
attributes
and
browser
interaction
is
not
an
attribute
right
itself.
B
Correct
so
that
this
is
kind
of
kind
of
a
yamo
format,
so
it's
this
would
be
like
browser.
browser,
interaction.type,
browserinteraction.element.
B
B
I
think
we
would
have
to
make
them
optional
and
that
makes
that
then
makes
the
validation
a
little
bit
much
more
challenging.
I
think
like
if
you,
if
you
really
wanted
to
say
you
know
it's
a
browser,
interaction,
and
I'm
there
like
a
certain
attribute,
is
always
required,
but
only
if
it's,
if
the
domain
is
browser.
B
E
Yeah
I
can,
it
can
be
both.
I
like
the
idea
of
being
able
to
merge
things
that
are
the
same,
so
example
session
start.
If
you
wanted
to
do
that
and
it
had
zero
attributes
in
it,
then
why
not
just
say
that
you
know
that
that
applies
to
all
domains
and
then
is
it
how
much
more
work
is
it
to
yeah?
I
I
see
that
use
case
too.
I
think
that's
a
good
point,
but
then
you
can
just
define
a
unique
type
for
each
each
domain.
Right.
B
So
yeah,
I
don't
know
what
that's
you
know.
I
mean
the
in
the
specification
we
say
like
you
know,
if,
like
you
know,
this
is
required
only
if
so
it's
gonna
be
conditional,
but
but
then,
like
you
know
you
on
the
back
end,
you
would
have
to
have
those
rules
defined
in
your
back
end
right.
E
Oh,
you
know
working
you
can
like
defining
it.
You
can
always
extend
so
like
here's.
The
base,
like
the
elastic
search,
spec
thing.
As
you
can
see,
here's
the
base
event.
You
can
extend
that
if
you're
having
a
break,
if
you
have
a
browser
or
a
mobile
event
and
then
validation,
you
can
always
do
like
a
hacky
thing.
E
But
yeah
I
mean
you
can
use
inheritance,
maybe
in
your
in
your
model
and
then,
if
for
all
interactions,
use
the
base
model.
If
you
have
a
browser
interaction,
you
can
just
extend
it
and
then
say
browser
interaction.
B
E
B
E
If
I
think
about
this
from
writing
a
schema
perspective,
like
json
schema,
it's
it's
totally
doable
where
you
can
extend
it.
So
if
I
was
writing
the
schema
for
that,
I'd
have
a
base
schema
and
then
I'd
have
I'd,
just
extend
it
and
then
the
yeah,
the
namespaces,
would
be
different
for
event.
Types.
E
B
I
have
kind
of
a
silly
question
for
for
the
schema
for
the
having
actual
schema
like.
Are
you
looking
to
have
have
a
schema
provided
or
like,
like
structured
in
a
way
so
that
the
back
end
doesn't
have
to
know
about
all
the
rules?
B
B
I
mean
currently
like
the
the
schema
currently
just
tells
you
like
what
what
changed
in
the
like
the
version
of
it
right
and
so
so
the
back
end
still
need
to
know
like
what
what
that
version
of
of
the
spec
grants
back
like
what
it,
what
kind
of
fields
it
contains
so
like
if
you,
when
you're,
proposing
updating
the
schema
for
validation
like
do
you
mean
that
it's
so
so
that
backhands,
don't
have
to
have
don't
have
to
know
like
what
the
the
semantic
conventions
actually
are,
so
they
don't
have
to
have
it
hard-coded.
A
B
A
Ideally,
you
know
we
should
be
able
to
even
say
nothing
more,
nothing
less,
but
that's
a
little
hard,
but
at
least
you
know
these
are
the
attributes
expected.
So
we
can
at
least
look
for
the
presence
of
those
attributes
and-
and
possibly
you
know
some-
you
know
data
type
and
then
each
of
the.
B
A
Today's
you
know
the
schema
spec
only
enables
you
know,
changes
in
the
semantic
convention,
so
the
I
it
looks.
B
A
B
Yeah,
I
guess
I
guess
what
I'm
trying
to
say
is
like
when,
when
you
receive
a
message
on
the
back
end
and
you
have
on
the
kind
of
the
the
instrument
scope
level,
you
get
the
schema,
and
so
in
the
schema
you
can,
you
can
get
the
version
of
the
spec
and
and
the
version.
A
B
The
version
of
the
spec
is
tied
to
you
know,
specifics
semantic
conventions
which,
which
you
know
tell
you
which
fields
are
in
those
semantic
conventions
which
are
required
and
so
on.
So.
A
Oh,
I
see
I
see
what
you're
saying
so.
The
current
semantic
conventions
already
has
a
required
field.
Yes,.
B
B
Mean
the
the
the
difference
is
still
I
mean
the
the
the
difference
is
that,
like
the
the
back
end
needs
to
know?
Okay,
I'm.
This
is
a
version,
I
don't
know
version
four
or
five
or
whatever,
and
in
version
five
I
have
these
these
fields.
So
I
have
you
know,
that's
what
I
need
to
look
for
so,
like
the
back
end
needs
to
know
that
right.
E
So
we
use
we
use
json
schema
for
this,
so
we
we
encode
all
our
schemas
in
json
and
that's
probably
what
we
do
for
hotel
too.
We
take
the
spec
or
the
semantic
conventions.
We
turn
that
into
a
json
schema
and
then
the
server
has
it
has
access
to
all
those
schemas
and
it
just
does
the
does
the
validation
so
yeah.
It's
not
hard-coded.
E
A
Yeah
martin,
can
you
show
what
you're
talking
about
that
way?
It'll
be
easier,
so.
A
A
A
I
think
it's
also
tricky
if
we,
we
need
to
say
it's
required
in
the
context
of
this
event,
if
the
same
attribute
is
used
in
another
context,
you
know
it
is.
A
Okay,
I
think
this
is
a
good
point.
I
think
we
should
investigate
this,
whether
we
could
leverage
this
for
the
validation.
C
C
C
Yeah,
I
would
prefer
to
see
that
saying:
okay,
we
have
event
name
and
then
we
have
event
data
or
maybe
event,
browser
interaction
and
then
it's
then
a
nested
object
which
the
protobuf
supports.
Pinping
means.
So
it's
a
case
of
your
effect.
You
have
a
nested
level
of
objects
which,
from
a
decent
perspective,
is
just
like
you
you're,
just
jason,
stringifying
it
and
then
from
a
validation
perspective
effectively.
C
A
Yeah,
I
I
don't
know
how
to
solve
that,
though
it
doesn't
fit
in
the
current
way
of
things.
C
Well,
yeah,
so
in
the
case
of
there
we
had
like
a
browser,
interaction,
type,
an
element.
I
would
want
to
see
that
as
a
top
level
single
attribute,
saying
browser
interaction
which
had
in
itself
had
two
values
called
type
and
element
rather
than
two
attributes
called
browser,
interaction,
dot,
type
and
browser
induction
element.
That's
one
thing.
E
C
Well,
from
a
browser
perspective,
yes
sterilize
json,
but
from
a
protobuf
perspective,
it's
just
embedded
objects.
So
there
was
the,
I
think,
ted
pointed
out.
There
was
a
an
any
type,
so
any
type
of
factory
is
effectively
a
name
and
a
value
and
the
value
could
be
in
any
type.
So
that's
how
you
get
your
nested
objects
in
forever.
A
Hey,
I'm
sorry,
I
I
need
to
drop
down
another
call.
Let's
go
okay.