►
From YouTube: T2TRG Interim Meeting 2020-03-20
Description
T2TRG Interim Meeting 2020-03-20
A
A
We
are
a
little
bit
sloppy
with
our
terminology
here,
but
for
today,
I
think
that
that's
pretty
much
ok,
so
that's
1
p.m.
and
1
p.m.
is
amazingly
successful
in
that
they
have
both
a
set
of
a
three-digit
set
of
data
models
that
are
nearing
completion,
as
well
as
common
idea
of
a
language
that
is
used
to
represent
those
data
models,
so
that
that's
a
really
interesting
group
and
on
the
other
hand,
we
have
the
finger
thing.
A
Research
group,
which
is
a
research
group
inside
the
I
RTF,
which
is
IDF's
research
arm,
and
we
are
interested
in
bringing
researchers
and
Senator
of
us
together
to
get
progress
on
the
long
term
problem
of
a
29
of
things.
So
the
IETF
is
creating
standards
and
we
are
looking
at
what
what's
missing.
What
are
the
gaps?
A
What
needs
to
be
done
not
necessarily
done
within
the
IDF,
but
some
of
the
gaps
we
find,
of
course,
will
then
be
addressed
by
the
idea,
so
that
that's
the
the
background
for
today's
meeting
and
in
in
Vancouver
time
we
are
starting
with
the
introduction.
This
is
the
ten
minutes
here
and
we
have
three
big
headlines.
We
have
versioning
and
evolution
as
one
headline.
We
want
to
spend
half
an
hour
on
that.
We
have
one
DM
key
technical
issues
and
I
neglected
to
actually
update
this
properly.
A
So
we
we
have
the
the
major
part
of
the
time
for
that
from
942
1120
and
in
the
end
we
should
spend
some
time
about
prospects
of
actually
getting
standardization
going
for
SDF
for
the
language
one
year
has
defined
and
yeah
look
at
how
you
the
IDF.
You
could
be
useful
for
that
and
what
are
the
next
process
steps?
We
have
to
do
to
make
that
happen
and
yeah.
Then
we
have
a
little
bit
of
time
for
a
wrap-up
by
seeing
whether
we
want
to
do
this
again
and
so
on.
A
We
want
to
have
a
10
minute
break
in
the
middle
now.
This
is
in
the
middle
of
Michael's
time.
So
at
some
point
we
should
just
say:
okay
Michael,
our
brains,
an
overload,
we
need
a
ten-minute
break,
and
so
the
the
time
that
is
taking
down
here
isn't
really
a
hundred
minutes.
It's
only
90
minutes
and
there
need
to
be
some
some
10
minutes.
In
the
end,
we
will
not
shoot
Michael
to
actually
start
this
10-minute
break
any
comments
on
the
agenda.
A
Okay,
logistics,
the
pointer
to
the
live
notes
that
we
are
taking
in
techempty
here
can
be
as
a
kind
of
easier
pair
just
for
formal
documents
is
in
the
WebEx
chat
and
on
the
slides
here
and
well.
You
wouldn't
hear
this.
If
you
didn't
know
about
the
WebEx
meeting,
so
I
don't
have
to
say
anything
about
that.
So
that's
the
introduction
anything
else
on
the
logistic
side.
A
So
if
you
hear
me
not
speaking
for
a
while,
this
is
me
muted
and
cuffing
a
little
bit.
Oh,
it's
not
about
that
nothing
good!
So,
let's
start
with
the
the
first
item
on
the
agenda.
We
have
been
talking
about
versioning
and
and
evolution
for
a
while
in
the
research
group.
We
have
this
this
thing
in
the
research
group,
which
is
called
the
wishy.
A
Thank
you,
so
we
tend
to
have
call
a
month
or
maybe
twice
a
month
on
some
issues
and
two
of
these
cause.
We
have
been
discussing
versioning
already
and
it
turns
out
that
that
evolution
and
and
therefore
the
need
for
versioning
revisions
features
whatever
comes
out
at
the
number
of
different
levels
in
the
1dm
activity,
and
one
of
that
is
of
course,
that
the
models
themselves
evolve
over
time.
Of
course
they
evolve
during
initial
development.
A
That's
maybe
when
we
need
a
slightly
more
sloppy
form
of
versioning,
where
we
do
need
some
versioning
and
then
at
some
point
they
get
agreed,
but
of
course
they
do
get
fixers,
they
get
additional
features
and
so
on
so
they
evolve.
Now
we
have
to
have
a
way
to
handle
this
evolution
in
such
a
way
that
not
every
change
is
extremely
expensive
and
disruptive,
and
so
on.
So
that's
one
area
of
evolution
current
that
we
need
to
manage
and
the
other
one
is
that
the
SDF
language
that
we
are
using
to
represent
these
models.
A
This
language
will
also
evolve.
This
will
get
new
features,
I
hope
we
will
manage
to
stay
completely
backward-compatible
over
time,
but
even
that
is
not
a
given,
so
we
want
to
be
able
to
have
different
versions
of
SDF
coexist
in
in
one
ecosystem,
where
we
might
have
data
models
that
have
been
developed
at
different
times,
based
on
different
versions
of
that
language.
So
this
is
not
about
evolving
the
models
itself.
Of
course
model
evolution
has
detect
with
this,
but
about
evolving
the
language.
A
Distinctions
later,
but
we
have
to
keep
that
in
mind
also
during
the
development
of
1dm.
It's
it's
often
confusing.
We
talk
about
things
like
schemas
and
never
remember,
to
say:
are
we
talking
about
this
EEMA?
That
is
part
of
the
model
to
describe
the
data
that
are
being
exchanged
as
part
of
this
model,
or
are
we
talking
about
the
schemer
that
defines
the
syntax
of
the
language?
Both
are
schemas
and
it
can
become
very
confusing,
so
we
have
to
be
little
bit
careful
to
always
say
with
which
level
we
are
arguing.
A
So
I
have
said
versioning
all
the
time,
and
actually,
after
about
40
years
of
doing
this
in
various
protocols
and
environments,
it
has
become
clear
that
that
versioning
is
not
necessarily
exactly
what
you
want,
because
versioning
was
invented
for
for
software.
But
this
is
not
Sofia.
This
is
an
interface
definition
between
two
software
components
or
multiple
software
components
that
evolve
on
their
own
timelines.
A
So
it
has
turned
out
that
we
actually
often
can
better
describe
the
evolution
of
some
interface
in
terms
of
features
so
which
new
features
are
there
that
weren't
there
before
and
features
might
take
the
form
of
a
simple
capability
indication?
So
one
end
of
the
communication
says:
oh
by
the
way,
I
understand
this
new
data
format
or
this
new
rejection
pattern
and
so
on.
So
it's
it's
kind
of
a
unidirectional
announcement
and
it's
only
becoming
actionable
when
it's
actually.
A
Operated
by
the
pier
so
appear
that
simply
ignores
Thank
You
ability
indication.
It
doesn't
need
to
know
about
that
here,
every
indication,
because
it's
not
going
to
use
that
your
ability.
So
that's
one
kind
of
feature
and
the
other
one
is
one
we're
actually
either.
The
fact
that
a
feature
is
part
of
the
communication
really
changes
that
communication.
So
if
the
members
of
the
group
agree
that
they
all
speak
French
after
that,
we
might
want
to
start
speaking,
French
and,
and
then
people
who
come
in
and
don't
know
what
French's.
A
Oh
don't
know
the
language
will
not
be
able
to
communicate.
So
that's
a
very
different
kind
of
feature.
It's
one
that
really
is
more
of
an
agreement.
Then
then
a
simpler
capability
education
and
we
often
are
negotiating
features,
but
sometimes
we
are
simply
using
them
and
the
most
important
aspect.
Evolution
here
is
to
prevent
Falls
interoperability.
A
A
So
what
is
a
virgin
version,
then?
Where
a
version
essentially
is
a
feature
set
of
features
that
that
have
been
blessed
a
bit.
So
so
people
are
willing
to
talk
about
them
collectively
using
some
some
version
number
and
then
we
just
read
check
out
those
features
into
a
linear
space,
which
is
very
natural
when
you
think
about
evolution
of
a
single
piece
of
software,
because
that
software
has
their
future,
prevent
that
or
doesn't
have
it
implemented.
But
this
happens
in
in
linear
time
to
a
certain
extent,
at
least
so
it
makes
sense
to
say.
A
Oh,
this
is
very
true,
and
this
has
the
following
three
additional
features.
So
that
makes
sense
for
software.
It
makes
much
less
sense
for
an
interactional
specification,
but
still
it's
sometimes
nice
to
just
roll
up
a
number
of
features
in
particular
if
they
are
interdependent
in
some
way.
So
you
might
have
something
like
a
feature:
SDF
2.0,
which
would
mean
that
there
is
a
little
feature
that
we
now
take
for
granted
in
any
new
models
that
use
this
newly
version
or
dialect
of
the
language.
A
A
These
might
have
revisions,
so
I'm
I'm
changing
the
order
of
something
in
the
model
that
makes
things
easier
to
understand
for
a
human
reader
of
the
model,
but
doesn't
change
its
semantics.
I'm
fixing
a
typo
in
a
comment
or
in
a
semantics,
if
English
language,
a
description
or
something
like
that.
So
that's
a
revision
that
is
not
necessarily
creating
a
new
version.
That's
of
course,.
A
A
So
to
make
this
specific
in
a
model,
and
we
might
also
introduce
features
so
we
might
have
a
lamp
and
that
lamp
might
or
might
not
have
an
RGB
feature
and
depending
on
that,
its
behavior
is
going
to
be
different.
That's
another
thing
that
is
relevant
for
evolution,
because
very
often
you
do
model
evolution
in
a
backwards
compatible
way.
So
you
know
we
need
to
know
whether
a
specific
implementation
actually
had
that
feature
or
not.
A
So
there
is
a
difference
between
the
capability
of
a
model
and
the
capability
of
an
implementation
that
implements
this
model.
And
again
we
are
going
to
do
roll
ups
here
at
some
point.
So
at
some
point
that
we
say
we
have
a
completely
new
version
of
a
model
that
unifies
a
number
of
features
and
on
the
language
side.
A
So
it's
there
is
no
negotiation,
it's
just
going
to
say:
I
need
features
a
B
and
C,
and
well
sometimes
you
have
conditional
parts
of
a
specification
and
so
on,
but
usually
you
try
to
avoid
that
complexity.
So
a
model
will
be
clear
that
simply
you
need
to
actually
declare
which
features
it
assumes
and
that's
then,
in
interpretation
requirement
and
of
course
there
may
be
optional
things
still
things
that
can
be
ignored.
A
So
if
you
don't
know
what
a
protocol
binding
is,
then
you
don't
really
care
about
features
that
relate
or
do
particular
findings
now.
One
interesting
thing
that
also
happens
is
these:
models
need
to
live
somewhere
and
get
names,
and
then
you
reference
a
model
buying
name
from
a
different
place.
So,
for
instance,
we
might
include
definitions
from
one
model
specification
into
another
specification
that
would
be
inclusion
or
input
and,
of
course,
also
an
actual
device.
A
May
reference
model
specification.
It
may
not
be
interested
in
the
specific
revision
of
that
model,
but
just
say
I
implement
that
model,
so
sometimes
we
reference
documents
that
are
meant
to
evolve
do
not
always
reference
one
exact,
specific
revision.
So
that's
one
thing
the
Yankee
Palar
trying
to
do.
They
are
trying
to
attach
a
specific
revision
and
revision
to
every
single
yang
specification.
A
A
Now,
let's
talk
about
the
interfaces
where
we
need
all
this
stuff.
As
I
said,
the
specification
uses
a
version
of
the
language
and
the
language
may
have
evolved
and
we
have
got
additional
features,
and
this
is
not
just
a
matter
of
the
language
specification
having
evolved.
You
also
want
to
know
whether
the
language
implementation
you
are
using
actually
implements
all
the
features
you
need
to
run.
A
So
that's
something
that
may
be
useful
to
make
make
it
easier
for
an
implementer
to
manage
the
evolution
of
the
language
they
implant.
So
this
is
one
interface
and
there
we
need
versioning
of
feature
indications
for
the
language
and
the
other.
One
is
the
use
of
model
specifications
by
other
model
specifications
and
of
us,
ultimately,
the
use
of
a
model
specification
by
a
device
definition.
A
So
we
need
to
find
out
whether
we
want
to
indicate
a
specific
revision
here
to
be
on
the
safe
side,
indicate
some
semantic
versioning
to
have
a
way
to
fix
some
bugs
indicate
features.
I.
Think
that's
really
the
the
the
most
interesting
part
here.
How
can
a
lamp
say,
I'm
a
lamp
and
I'm
using
that
model
over
there
and
actually
I'm,
also
offering
certain
features
here
and
requiring
certain
features
that
from
the
model
that
may
not
be
required
by
my
other
people?
A
D
All
right
wow,
thank
you
that
actually,
it
really
makes
sense
to
think
of
these
things.
Not
really
you
know,
as
you
just
pointed
out,
not
as
like
how
you
version
something,
but
from
the
point
of
use
of
the
version.
So
the
references
and
understanding
how
the
references
to
aversion
are
used
is
really
probably
the
most
informative
thing
that
we
could.
We
could
do
to
sort
of
help
decide
how
they
should
work
and
and
medium
immediately
made
me
think
of
I.
D
Do
not
want
to
have
to
carry
around
the
logic
or
I
would
prefer
not
to
carry
around
the
logic
to
apply
different
schemas
to
different
instances
of
things.
It
seems
to
be
really
cumbersome
too.
To
have
you
know
a
set
of
models
where
different
models
have
are
pointing
to
different
schemas
and
that,
where
the
way
you
use
it
is
just
by
having
the
whole
referencing
the
schema
to
validate,
then
that
you
know
it's
better
not
to
have
a
lot
of
those
I
guess
so
there's
some
some
informative.
D
D
So
with
that,
I
guess
indicating
indicating
features
as
individual
things
and
I
guess.
I
have
some
questions
right.
So
as
capabilities
versus
agreements,
it
seems
like
capabilities
are
mostly
by
by
nature
backward
compatible,
and
so
you
might
even
be
able
to
add
those
without
changing
any
kind
of
version
or
anything
and
just
sort
of
you
know
add
those
have
provided.
D
The
right
testing
has
been
done,
but
then,
when
agreements
change,
that's
when
I
think
it
sometimes
calls
into
a
more
rigorous
review
of
whether
you
need
to
change
a
version
or
you
know
what's
breaking
and
what
isn't
breaking
the
sort
of
thing
does
that
does
that
make
sense
with
your
thinking?
The
capabilities
are
mostly
backward
compatible,
but
when
interpretations
change,
it's
more
of
an
opportunity
to
break
things.
A
A
The
the
interpretation
agreements,
of
course,
though,
those
really
require
preventing
thoughts,
enter
bility,
so
they
are
much
more
disruptive,
but
they
are
also
great
opportunities
to
clean
things
up.
So
when
things
moved
from
HTTP
1.0
to
HTTP,
1.1
the
only
place
in
the
history
of
HTTP,
where
that
actually
happened,
they
could
take
on
a
lot
of
cruft
of
the
the
headers
that
had
accumulated
that
you
hadn't
had
to
put
india
to
work
with
both
older
and
newer
hd10
implementations.
Sometimes
you
just
want
to
do
that
to
simplify
things.
A
D
E
Have
a
question:
how
do
you
deal
with
systems
that
are
increasingly
dynamic
where
a
feature
could
be
time-based?
So
something
is
very
important
now,
but
it
way
may
not
be
important
tomorrow,
because
we're
an
industrial
environment
or
something
to
that.
So
is
there
eight.
So
my
question
is:
are
these
versioning
and
features
could
be
time
limited
or
time
based
or
time
stamped
to
to
make
a
difference
between
current
information
and
steal
information.
F
A
So
I
could
imagine
this
happening
more
when,
when
we
talk
about
specific
features
being
available
in
a
device
so
that
the
device
stops
supporting
TLS
1.0,
because
we
really
don't
want
to
accept
those
insecurities
anymore
and
we
might
want
to
put
a
date
on
when
that
happens.
This
is
less
about
features
that
a
specification
language
has
so
essentially
is
the
specification
that
is
using
an
older
version
of
the
specification
language
will
will
be
around
indefinitely.
A
D
Like
Python
Python
3
at
some
point,
people
might
start
saying:
oh,
we
don't
really
trust
those
Python
2
anymore,
but
that's
not
yeah.
You
know
I'm
so
there,
but
both
exist
and
coexisted
that
there's
a
graceful
way
to
base
out
the
older
one
over
time
and
that's
probably
what
we
want
to
head
for,
but
you
probably
have
to
support
it.
It's
better
been
definitely
in
in
terms
of
an
organization
and
as
a
as
a
standard,
and
you
know
it
doesn't
just
immediately
stop
being
working
everywhere.
These.
F
F
B
G
I
think
there
is
a
huge
difference
in
data
modeling
and
what
is
actually
implemented
in
a
device
and
I
think.
The
examples
that
are
here
so
far
is
really
signalling
what
a
device
can
do.
It
has
nothing
to
do
with
the
data
modeling
and
a
version
of
the
data
model
itself,
at
least
that's
my
rasp
of
what
we're
trying
to
do
with
SDF
what
can
be
implemented
or
what
is
defined
in
the
data
model,
and
what
can
we
implement?
G
That
can
already
be
a
subset
and
it's
up
to
the
ecosystem
to
convey
what
is
the
sub
set
and,
of
course,
all
the
required
elements
of
a
data
model
needs
to
be
somehow
transported
for
a
data
model.
We
are
not
talking
about
the
interaction
model,
send
it
through
detectors
kind
of
things,
at
least
not
yet.
A
G
Yes,
if
you
want
to
do,
if
you
have
model
a
and
you
want
to
add
something
as
an
optional,
that
can
be
done
at
any
time.
You
still
need
to
recognize
that's
an
optional
thing
and
whether,
if
it's
available
on
that
implementation
or
not,
if
you
want
to
add
something
that
is
minute,
then
probably
you
should
not
call
it
data
model
a
but
data
model,
a
version
two
so
that
everybody
in
here
it's
it's
known
that
there
is
and
fundamental
change,
because
something
mandatory
has
been
added
to
it.
That.
G
A
A
But
of
course,
there's
all
this
power
field
stuff
out
there
that
doesn't
know
about
here,
let's
1.3,
so
as
long
as
that
stuff
is
out
there,
you
may
also
want
to
support
TLS
1.2,
and
so
you
have
a
mandatory
part
in
that
model
that
the
the
peer
device
doesn't
care
about,
because
the
only
has
TLS
1.2.
So
this
is
a
classical
feature
from
the
device
into
a
military
point
of
view
and
therefore
you
should
also
be
able
to
handle
it
like
a
feature
on
the
model.
11.
G
So
there
is
some
what
forwards
compatible
thing
needed
on
the
client
side
or
at
least
more
a
great
ability
of
the
client
side
than
on
the
server
side.
If
everything
would
be
upgradeable-
and
you
could
do
that,
but
in
field
situations,
you
will
never
have
the
possibility
that
everything
is
upgraded
to
the
latest
version,
if
you're
doing
it
in
a
in
a
factory,
it
might
be,
but
something
like
in
a
smart
home
where
people
buy
devices
from
different
vendors
and
have
a
good
just
a
mixed
bunch.
C
G
G
A
A
Yeah
I
agree
that
TLS
is
maybe
not
the
best
example
here
that
that's
maybe
one
of
the
things
we
much
take
at
some
work,
coming
up
with
a
number
of
good
examples
that
actually
illustrate
what
we
are
trying
to
do
here.
So
we
can
point
through
those
specific
examples
when
we
explain
our
design
decisions.
D
You
I
didn't
totally.
We
need
to
sort
of
figure
out
what
we're
talking
about.
Also
the
examples
help
us
stay
focused
on
whether
we're
talking
about
models
or
language,
which
seems
to
be
the
the
big
split
here,
that
we
need
to
talk
about
versioning
and
both
them
and,
of
course,
how
much
language
versioning.
Do
we
embed
in
the
models,
which
was
something
that
I
think
Carson
mentioned
earlier
as
being
a
a
specific
issue
that
we
would
need
to
consider
so
I
think
we're.
We
seem
to
be
getting
written.
Pardon
me.
D
B
A
Think
we
should
go
home
with
an
idea
of
what
what
we
want
to
do
until
we
have
the
next
meeting
of
this
kind
and
I
think
taking
home.
The
need
for
examples
is
pretty
useful,
but
of
course,
in
the
end,
I
think
somebody
has
to
write
this
up,
so
I
would
also
be
looking
for
people
who
are
interested
in
doing
some
of
the
writing.
B
We
don't
have
now
Jaime
in
the
coal
remember
he
started
writing
something
in
one
context
about
the
operation
like
to
pay
kuda
way
forward.
We
have
quite
a
bit
material
on
the
minutes
where
we
treat
you
good
something,
but
if
there
are
more
people
interested
on
this
topic
is
to,
let
us
know
would
be
very
useful.
The
right
right.
This
thing
things
down.
We
have
a
place
to
refer
to.
B
Well,
Thank,
You,
Kirsten
and,
and
anyone
else
who's
interested
to
work
more
on
those
who
do
the.
Let
us
know
baby
nice
good
time
to
switch
them
on
the
STF
issues,
and
we
could
then
perhaps
straight
away
on
and
on
the
versioning
and
and
think
about
how
should
we
enroll,
versioning
or
and
or
features
in
that
context,
so
model
coaster
would
like
to
make
take
the
presentation.
Okay,.
D
D
No,
what
are
you
seeing
here,
something
weird
nice
sharing?
Oh
here
we
go
there.
We
go
so
I
have
both
these
presentations
up.
What
what
I
have
up
over
here
is
that
actually
this,
this
presentation
that
I've
updated
but
I
wanted
to
sort
of
center
around
this,
because
I
know
there's
some
some
people
on
the
call
that
maybe
haven't
been
keeping
up
with
every
one
data
model
meeting.
D
So
let
me
know
if
we
need
some
context
and
I'll
switch
back
to
this
deck,
but
to
stay
focused
on
what
pardon
me
I
mean
what
we
wanted
to
well,
we
wanted
to
accomplish
today.
We
we
had
a
one
data
model
meeting
earlier
today
and
did
some
review
of
these
and
and
a
prioritized
on
work
where
we
think
the
hot
topics
are,
which
are
the
bold
ones
at
the
top,
but
here's
our
whole
list
of
things
and
and
I
guess
at
this
point
we
need
to
figure
out.
D
Does
anyone
feel
like
they
need
to,
and
you
know,
they're
totally
lost
about
what
one
data
model
is,
especially
after
after
it
haven't
even
shown
this?
Basically,
what
we
have
is
events,
actions
and
properties
and
data
types
and
objects,
and
things-
and
you
know
if
that's
not
enough-
I'm
happy
to
explain
a
little
more
okay.
D
What
was
something
that
people
can
count
on
to
be
stable
and
that
we
can
open
up
wider
access
to
you?
Currently,
the
github
is
public,
so
anyone
really
has
access
to
it,
but
what
we
want
to
do
is
sort
of
start
being
a
little
more
consistent
about
our
releases
and
policies
and
all
that,
so
the
burden
scheme
is
really
at
the
heart
of
all
this
figuring
out.
We
want
to
move
this
forward
in
a
way.
That's
people
can
both
depend
on
what
things
working
the
way
they
have
always
worked.
D
We
currently
don't
version
individual
models,
but
there
are
a
number
of
people
who
think
that
that
might
be
a
good
idea
to
try
to
do
so.
We're
almost
we're
kind
of
having
the
same
discussion
now.
What
we
do
at
smart
things
is,
we
have
a
policy
of
saying
we
don't
version
things.
This
is
very
similar
by
the
way
to
oh
I'm,
a
lightweight
into
him,
and
maybe
what
a
lot
of
other
people
do
like.
D
The
two
beret
can
need
special
exceptions
and
all
plus
it
doesn't
really
oh
I
guess
you
know
allow
for
the
kind
of
evolved
ability
that
people
want
I,
think
and
I.
Don't
know.
You
know
that
the
creating
a
new
model
is
also
a
breaking
change.
I
guess
is
another
way
of
getting
that,
so
they
feel,
like
versions,
might
be
a
way
of
you
know
having
TV
in
between
the
two
and
not
the
worst
of
both.
So
but
we
don't
really
know
about
that.
D
So
that's
our
experience
with
versioning
models
anyway,
is
that
we
currently
don't
do
it,
but
there's
some
framework
and
numbers
and
tags
that
people
want
to
start
trying
to
use,
and
so
even
the
results
of
our
decision
here.
Might
you
know,
because
we're
we're
hoping
to
contribute
our
models
to
one
DM
as
soon
as
the
all
the
licensing?
Can
we
take
it
out?
You
know
and
I
think
we're
really
close
to
that.
D
D
So
it
might
be
something
like
slash:
SDF
version
/,
one
one
one
for
example,
and
that
might
be
a
directory
that
points
to
that
has
both
the
schema
and
a
markdown
file,
and
it
that
that's
a
version
of
the
language,
if
you
will,
at
an
accompanying
schema,
put
me
an
accompanying
schema
that
validates
instances
of
models
that
are
said
to
conform
to
that
version
of
the
language.
Well,
that's
that's.
D
The
first
sort
of
part
of
the
proposal
is
that
we,
we
version
the
language
in
in
terms
of
get
to
have
branches,
and
we
tag
the
branches
and
those
are
those
are
actual
language
releases
that
that
look
like
directories
that
have
a
semantic
versioning
in
their
half
somewhere
and
the
details
of
that
can
be
figured
out.
So
that's
that's
actually
kind
of
a
concrete
proposal
that
we
have
on
the
table
that
we
would
do
if
no
one
objects
it.
If
there's
not
a
better
way
to
do
it,
at
cetera,.
D
When
we
make,
when
is
a
language
version
you
know
done
and
and
all
that
it
is
sort
of
like
Kirsten
I've,
actually
presented
a
lot
of
good
rules
for
that,
and
we
could,
we
could,
you
know
just
have
those
those
policies
and
and
and
do
that,
I
don't
know
if
there's
a
technical
issue
with
with
that,
but
I
think
you
know,
we
need
to
talk
that
through
you
know.
If
there
are
any
so
versioning
the
language,
you
know
the
rules
would
be
when
you,
you
know,
maybe
maybe
the
ruler
look.
D
You
know,
we'd
have
to
figure
out
the
scope
of
changes
that
trigger
a
version
and
whether
we
want
to
have
a
lot
of
versions
or
just
a
few
and
I
wouldn't
say
you
know,
beat
us
to
have
just
a
few
versions,
but
we
do
have
to
have
a
way
to
evolve
the
language
between
versions
and
it's
not
clear
whether
we
want
to
have
language
features,
show
up
without
a
version
number
changing
at
all
right,
so
that
I
think
that's
part
of
what
the
policy
discussion
or
the
sort
of
how
it's
done.
Discussion
on
that.
D
I
think
that
there
was
one
further
idea
that
was
coupling
the
models
to
the
versions
in
a
way
that
we
would
have
a
what
we
call
a
quality
in
the
asdf
model
to
distinguish
it
from
after
your
property
and
all
those
other
overloaded
terms.
You
have
a
quality,
that's
a
key
value
pair
that
says
SDF
version,
and
then
it
sort
of
points
to
that.
A
URI
that
points
to
that
version
and
that's
the
version
of
this
model
is
expected
to
conform
to
or
to
be
validated
against.
D
Also,
the
schema
that's
found
in
that
directory
would
validate
that
model.
So
from
what
I
heard
earlier,
though,
and
in
the
thinking
about
this,
that
that
might
have
its
own
set
of
problems
to
require
that
kind
of
coupling,
so
I
guess
at
this
point,
I'd
like
to
open
up
the
discussion
and
get
people's
opinions
on
on
those
three
things,
both
the
model
versioning,
maybe
maybe
that
features
can
be
added,
and
we
we
sort
of
don't
worry
about
version
numbers
for
models
right
now,
use
the
backward
compatibility
rule
and
for
language
versions.
D
The
proposal
is,
they
have
a
github
branch
with
a
schema
and
a
markdown
file
and
other
associated
supporting
files
in
it
that
that
changes
when
each
version
changes
and
then
also
the
third
thing
to
to
require
that
the
models
point
to
the
schema
that
they're
expected
to
validate
against
and
those
those
would
presumably
be
backward
compatible.
So
it
an
older
model
would
validate
against
the
newer
schema,
but
I
guess
that's
subject
to
discussion.
Also.
A
Fixed
some
problem
in
the
meaning
of
the
language
that
may
mean
that
that
a
specific
instance
can
be
interpreted
in
the
language
before
the
fix
and
in
the
language
after
the
fixed
and
means
different
things
there.
So
the
fact
that
this
instance,
this
specific
instance
actually
validates
under
that
schema,
is
kind
of
nice.
But
it's
not
telling
me
what
version
of
the
language
I
actually
have
been
using.
D
A
D
D
So
the
playing
that
forward
against
the
proposal
for
language
versions,
assuming
that
every
substantive
change
in
the
language
requires
a
new
version
just
for
the
time
being.
What
does
that
mean
that
either
of
those
would
require
a
language
change,
because
it
has
a
descriptive
document,
the
markdown
file,
which
could
change
the
meaning
of
something,
and
also
it
has
the
schema
which
which
could
be
changed
for
typos.
So
what
would
we
say
that
it's
and
an
inclusive
or
of
the
changes
in
either
the
meaning
or
the
syntax?
That
would
trigger
a
language
version?
D
A
D
D
D
D
That'd
be
a
reasonable
set
of
I.
You
know,
I,
don't
want
to
get
too
much
into.
You
know
one
DM
operational
stuff
here,
but
if
that
sounds
like
a
reasonable
set
of
rules
to
go
forward
with,
if
someone
you
know
on
the
one
DM
side
would
you
know,
could
write
those
up
about
language
versions
and
continue
to
use
this
sort
of
the
directory
method
and
github
branch,
and
all
of
that
and
no
one's
objected
to
that
so,
okay,
thank
you.
D
Model
versions
and
versions
of
models.
What
about
this
idea
of
just
like
what
everybody's
doing
now,
you
can
add
features,
but
you
can't
change
contracts
with
that
and
just
create
a
new
model.
If
you
do
I,
it
seems
like
we
have
some
experience
with
that.
I
know
from
smart
things.
We
have
some
experience
with
that
where
we
end
up
deprecating
the
old
model,
eventually,
because
people
just
would
rather
use
the
new
model
it
gives
the
gives
the
customer
a
better
experience.
D
So
you
know
it's
not
that
hard
to
get
people
to
switch
over,
but
it
takes
time
you
can't
just
force
people
to
go
and
write
software
and
release
it
on
your
schedule.
They
have
to
do
it
on
there.
So
those
are
that
all
those
intervals
vary
across
the
different
vendors
you
work
with,
and
all
of
that,
so
it's
the
same
I
think
it's
the
same
thing
with
us.
Is
there
any?
D
B
D
B
D
B
B
You
know
I'm
a
I'm,
but
one
thing
that
I
guess
what
we
have
agreed
on,
that
we
do
need
a
way
if
we
are
deprecating
models,
as
we
indicated
that
you're
doing,
for
example,
in
smart
things,
you
do
know
a
way
to
indicate
whether
either
on
the
model
that
has
deprecated
the
old
nor
all
in
the
old
once
something
has
been
deprecated.
But
you
have
a.
G
B
Revision
of
a
model
because
it
doesn't
really
change
the
interface,
but
you
have
something
indicating
there
at
this
model,
there's
new
model
that
replaces
this
model
and,
of
course,
the
one.
The
way
of
doing
that
is,
we
took
me
the
version
numbers,
but
since
that
is
that
version
numbers
have
their
own
issues,
this
kind
of
a
pointer
to
the
new
version,
or
back
or
forth.
It's
a
more
flexible
way
of
indicating
that
that
might.
B
D
For
example,
it
could
be
a
life
cycle,
design,
a
life
cycle
with
some
states,
and
we
use
it
smart
things
we
used
proposed,
live
and
deprecated,
and
so
a
proposed
capability,
as
sort
of
while
it's
in
staging-
and
you
know
even
for
a
little
while
after
when
we
make
sure
it
doesn't
need
any
changes,
then
it
goes
live
and
then
is
stable
and
then,
when
we
replace
it,
it
becomes
eventually
deprecated
than
that.
It
goes
through
that
process
of
having
both
available
but
they're
just
different
names.
D
But
what
an
additional
thing
that
you
brought
up
is
that
we
could,
when
we
deprecate
one,
we
could
say
replaced
by
select
like
with
IETF
drafts
when
you
go
on
the
draft
system,
and
so
that
you
can
says
oh
yeah,
this
this
the
name
change,
but
the
three
places
that
draft
right,
and
so
you
could
put
a
tag
in
the
old
when
you
deprecated.
You
know
you
could
say
sub
whatever
by
the
word
now,
but
you
know
succeeded,
succeeded
by
or
whatever
that's
the
plan.
D
That
is
the
only
one
I
can
think
of,
but
you
know
we
could
put
a
couple
of
qualities.
We
could
add
a
couple
of
qualities
that
a
lot
of
lifecycle
management
of
the
model
instances
themselves
in
the
header
I
mean
we
don't
have
to
design
the
whole
thing
here,
but
we
could
talk
about
different
sort
of
the
merits
of
different
approaches.
I
think.
A
It's
really
important
that
we
spend
some
time
thinking
about
the
model
metadata
that
go
into
that
head
on.
So
I
think
that
this
versioning
feature
mechanism
is
just
part
of
things
that
we
want
to
be
able
to
say
about
models
without
actually
changing
the
model
itself.
Because
then
the
thing
being
model
doesn't
care
about
which
version
that
was
modeled
with
exactly.
D
If
we
were
to
add
a
an
interface
class
to
virtualize
views
of
things,
then
that
that's
actually
a
change
in
model
metadata
and
it
adds
qualities
and
a
set
of
qualities-
is
also
a
guess
model
metadata
that
specifically
those
things
in
the
header
tell
you
about
the
other.
Things
are
sort
of
effects
of
the
things,
so
it's
like,
if
you
have
a
version,
the
changes
that
changes
the
feature
set
and
that's
sort
of
the
qualities
in
classes,
all
right,
I
guess,
yeah.
A
A
And
at
some
point
you
you'll
need
to
decide
whether
you
will
be.
We
want
to
accommodate
that
reality
or
just
just
reacted,
but
them
then
rejected
in
a
in
a
well
thought-out
well
considered
way.
We
really
want
to
get
rid
of
the
draft
15
version
and
we
deprecated-
and
it's
now
gone
so
I-
think
that
would
be
a
nice
thing
if
we
could
track
that
particular
nut
and
and
find
a
good
way
to
handle
version
transitions
that
actually
reflects
the
fact
that
versions
exists
in
drafts
and
people
sometimes
go
ahead
and
implement
those
drafts.
Oh.
D
There
is
a
weight
with
evolution
and
you
can't
make
it
go
away.
You
can't
even
push
it
sideways
very
far,
so
it
kind
of
roll
down
the
hill
and
the
on
the
down
the
track.
So
we
need
to
deal
with
that
in
a
way.
That's
realistic
and
we
need
to
probably
have
rules
that
evolve
as
our
designs
evolve
and
we
recognize
that
things
do
become
more
stable,
but
not
to
give
it
such
a
binary
character
in
our
in
our
work
process.
D
Again,
it
feels
like
grounded
on
a
lot
of
this,
though
we
need
a
I
need
for
one
DM.
We
need
a
proposal
and
I
think
the
idea
of
tracking
what's
happening
and
lightweight
m2m
and
tracking,
what's
happening
and
sort
of-
let's.
Let's
maybe
use
this
as
a
forum
for
keeping
this
this
versioning
and
we
already.
C
D
D
F
D
F
Yeah
you,
the
container,
if
it's
container
is
certified,
you
know,
like
the
data
model,
has
a
hasn't
had
signed
or
something,
and
you
can
handle
things
that
way
for
review
list
of
prerequisites
that
a
system
needs
and
those
things
have
versions.
But
you
sign
the
entire
thing.
You
necessarily
have
to
sign
the
individual
references
I'm,
just
bringing
up
the
now
and
I'm
just
wondering
if
it
matters
odd,
maybe
an
otoscope
which
is,
if.
G
G
F
Actually
does
journalism
you're,
saying
I
think
that
versions
are
an
example
of
I.
Have
certain
prerequisites
that
be
satisfies
me
to
work
right,
and
so
one
of
the
things
that
we
satisfied
is
having
an
you
know,
interface
with
certain
version
or
whatever
better,
and
so
what
I'm
really
doing
is
stealing
my
requirements.
No
other
requirements
like
route
rust.
They
may
be
related
but
aren't
exactly
versions.
They're
there
other
things
you
need
to
have
satisfied
other
conditions.
G
D
F
F
G
F
G
Although
organizations
that
I've
worked
with
that
had
a
certification
program,
if
you're
putting
that
sticker
on
that
you're
certified
and
you
were
not,
then
you
can't
get
a
letter
from
the
lawyer's,
that's
strong
and
if
you're
doing
something
that
is
not
according
to
this
back
and
you
had
certified.
But
you
launched
a
different
version
of
your
code.
F
D
And
that's
actually
the
key,
that's
something
that
we
haven't
decided
yet
in
in
DM.
You
know
where
we,
but
what
we're
gonna
do
about
that
and,
however,
whether
whether
and
how
so
that's
an
interesting
topic,
probably
to
take
in
another
discussion,
because
it's
probably
not
a
research
topic
for
thing
to
thing,
research
group.
But
but
it's
very
interesting
about
you
know
when
you
do
decide
to
certify
something,
then
you
know:
is
there
a
cryptographic
chain
that
you
establish,
etcetera,
etc?.
D
Know
and-
and
so
much
turns
around
whether
you
do
certification
or
not
as
I'm
finding
out
with
getting
involved
in
this
initial
program
in
ZigBee.
So
I
think
that
a
big
there's,
a
big
dividing
line
on
organizations
that
certify
things
and
organizations
that
don't
and
I
think
there's
there's
a
lot
to
be
cognizant
of
and
sort
of
what.
What
kind
of
when
we're
building.
F
G
D
G
In
the
same,
you
know
if
the
XMPP
client
doesn't
work,
I
will
get
another
XMPP
client
and
that's
the
same
thing
in
general
with
the
internet
web
browser
is
network,
I
will
take
another
browser
and
I
guess
everybody
gets
on.
The
pole
has
one
browser
on
their
system,
because
some
browsers
are
good
and
better
better
things.
G
C
B
D
D
No,
it
sounds
good,
the
ones
that
we
in
in
one
data
model
just
a
couple
of
hours
ago.
You
know
we're
interested
in
talking
about
or
in
bold
here,
so
that
was
those
are
sort
of
our
choices,
and
you
know
it
has
to
do
the
class
hierarchy
thing.
There
was
some.
You
know,
you
know,
you
know
who
you
are
with
the
issues.
D
You
know
things
you
want
to
do:
they're,
complex
data
types
or
some
question
about
a
use
case,
they're
having
to
do
with
what
happens
when
you,
you
really
want
to
have
a
data
type
that
has
a
lot
of
elements
and
and
maybe
as
hierarchical
itself.
How
do
we
represent
that
and
model?
It
there's
some
interesting
discussion
around
how
we
define
events
and
actions
and
sort
of
a
suggestion
that
we
look
at
an
event
condition
action
as
being
a
framework
for
defining
what
Evensen
actions
are
and
at
least
gives
people
some
grounding
in.
D
What's
there
for
there's
some
discussion
about,
you
know
long-running
actions
and
how
the
state
machine
works,
and
maybe
we
have
events
versus
versus
some
readwrite
status,
and
you
know,
however
restful
does
that
need
to
be
that's
that's
interesting
instance
bindings
and
protocol
bindings.
The
question
was
sort
of.
D
To
what
extent
do
we
need
to
model
the
target
architectures
that
are
these
one
data
models
will
be
used
on
so
we're
talking
about
specifically
the
sort
of
thing
that
a
w3c
protocol
binding
does
where
it
takes
a
generic
description,
and
you
know
have
some
your
eyes
and
method.
You
know,
method,
descriptions
and
things
like
that.
This
is
here's
how
you
use
the
protocol
instance
bindings
are
just
sort
of
for
those
that
that
aren't
deep
in
one
diem
1dm
doesn't
really
have
data
schemas.
That
says
this
is
what
it
looks
like
over
the
wire.
D
D
This
interaction
has
these
data
elements,
and
then
we
rely
on
another
descriptor
in
the
eCos,
because
in
a
protocol
to
say
what
this
data
schema
looks
like
on
the
wire
and
what
protocol
elements
are
used,
but
that's
kind
of
a
fuzzy
boundary,
because
we
do
have
things
in
one
data
model
that
can
describe
data
schemas
to
the
extent
that
you
could
just
use
them
as
payload
schemas.
If
you
wanted
to
so
that's
an
interesting
discussion
and
then
these
these
other
ones,
you
know
multiple
instances
of
a
definition
virtualization
have
to
do
with.
D
You
know
how
you,
how
you
have
a
generic
definition
that
can
be
expanded
and
sort
of
implemented
in
a
number
of
different
ways:
readwrite
constraints
about
how
restrictive
you
want
to
be
with
the
definitions
and
there's
a
really
any
data.
That's
inherently
write,
read-only
stuff
like
now,
you
know
how
you
handle
reusability
with
defaults,
there's
some
questions
about
ID
numbers
that
are
used
to
have
compact
wire
representations
for
different
protocols,
but
they're
used
differently,
and
how
do
we
represent
them,
and
so
on
and
so
forth.
D
There's
I
think
some
of
these
at
the
end,
are
like
enum
URI,
using
a
URI
to
define
values
of
an
enum
and
then
having
them
map
to
difference.
Realizations
I
would
be
handle
that
and
how
do
we
handle
namespaces?
So
these?
These
are
all
topics
that
that
are
sort
of
on
the
big
list
of
things
to
refine
for
SDF.
D
They
don't
all
have
to
be
done
for
the
first
version,
but
we
do
need
to
prioritize
what
we
are
going
to
do
and
we
have
ways
we're
doing
all
this
stuff
now
and
so
a
lot
of
these
are
sort
of
enhancements
on
the
language
that
we
can
decide.
You
know
what
the
merit
is
of
when
we
need
them
and
if
we
need
them
at
cetera.
So
if
anyone
has
any
strong
eye
ideas,
I
think
I've
just
briefly
explained
what
what
each
of
these
is.
So
we
can.
A
D
A
Is
a
triple
of
words
that
use
the
same
English
words
as
the
terms
event
and
action
in
one
there's:
no,
no
relationship
whatsoever.
Otherwise,
that's
really
interesting
and
also
the
the
definition
of
what
an
action
actually
is
would
be
interesting.
I,
wouldn't
even
start
thinking
about
what
an
event
is,
because
we
are
so
far
away
from
a
common
understanding,
but
maybe
we
could
make
some
progress
on
action
here
today.
So
I
really
would
like
to.
A
We
had
some
focus
on
that
and
if
we
have
some
time
you
might
want
to
talk
about
complex
data
types,
but
but
really,
let's
talk
about
interaction
patterns
and
and
the
in
particular
the
action
pattern
for
most
of
the
time
and
then
may
be
complex
data
types.
After
that
ten
minute
break
now
and
reconvene
at
10:45,
Pacific.
B
B
B
B
B
B
B
B
B
B
B
B
B
B
B
B
B
B
B
B
B
B
C
B
We
originally
were
planning
to
continue
this
till
11:26
Oh
will
be
about
half
an
hour
more
okay,
but
we
can
see.
We
can
maybe
also
shrink
a
bit
the
final
two
slots
I
mean
it
may
be
necessary
half
an
hour
for
them.
I
just
noticed
a
some
considerations,
but
let's
see
how
this
goes
and
how
much,
how
much
overtime
volition
we
shall
take
it
well
start
with
him.
Go
ahead.
D
D
Probably
the
best
example
is
if
I
might
have
a
state
property
on
off,
and
you
know
an
on
off
state
property.
That's
a
boolean.
I
might
have
an
action
that
takes
that
as
the
setter
for
that
that
takes
the
same
data
type
as
a
payload
and
they
might
have
an
event
that
gets
generated
when
the
property
value
changes
that
sends
the
same
data
type
as
a
payload.
So
that's
the
idea
of
a
reusable
data
types.
D
D
It's
is
sort
of
we
have
events,
actions
and
properties,
okay
and
and
the
the
current
working
definition
is
pretty
loose
and
says
that
properties
represent
the
states
of
things
and
they're
generally
readable
and
writeable.
But
there's
another
issue:
there's
another
item
on
this
list
that
has
to
do
it.
D
Actions
are
sort
of
the
way
we
represent
commands
typically
commands
that
you
send
so
they're
a
little
more
complex
than
just
changing
the
state
of
a
property
they
may
have
to
do
it
into
the
state
of
multiple
properties.
Together,
they
may
have
to
do
a
starting
something
on
a
device
that
might
take
some
time
to
complete
and
it
might
complete
correctly
or
I,
not
complete
correctly.
So
actions
are
more
about.
How
do
I
get
this?
That's
the
affordance
for
how
do
I
get
this.
You
know
to
perform
something,
and
the
events
are.
D
D
D
So
what
we'd
say
in
action
is
is,
as
I
said,
something
that
something
that
you
make
this
this
affordance
for
making
your
device
or
the
thing
your
device
is
connected
to
you,
perform
something,
and
so
the
definition
of
an
action
has
a
semantic
anchor
for
what
the
action
is
in.
The
way
of
this,
for
example,
of
a
light
bulb
might
have
a
turn
on
action
and
it
turn
off
action
or
a
you
know,
dim
the
light
or
brighten
the
light,
or
something
like
that
that
that
have
more
than
just
changing
the
value
of
a
brightness.
D
There
might
be
a
time
of
slope
involved
at
transition
time
or
other
other
kinds
of
things
involved
with
it,
and
when
we
define
an
action,
it's
really
the
semantic
anchor
of
what
the
action
is
and
its
input
parameters
and
perhaps
its
output
parameters
as
well.
So
look,
we
said.
Sometimes
you
can
invoke
an
action
and
then
get
some
response
back.
D
So
really,
what
we're
doing
is
we're
not
so
much
trying
to
from
first
principles
to
decide
what
the
meaning
of
an
action
is,
what
we
already
have
meaning,
because
we
have
these
devices
like
say
V
devices
that
have
commands
and
z-wave
devices
that
have
commands
and
UPnP
devices
that
have
actions
and
those
definitions
are
already
pretty
consistent
about
what
those
means.
So
we
just
decided
to
call
that
at
an
action.
D
Events
are
a
little
pretty
much
the
same
thing
rather
than
try
to
really
define
from
first
principles.
The
semantics
of
what
we
mean
by
a
pad,
we
already
have
examples
of
UPnP
having
events
of
ZigBee
devices,
sending
notifications
when
property
values
change,
and
so
those
all
fall
under
what
we,
what
we
call
events
and
they're
defined
in
one
data
model
as
having
a
semantic
anchor
for
what
this
semantic
definition
of
this
event
is
like
it
might
be,
just
a
general
device
alarm
something's
wrong.
D
Am
I
something
very
specific
like
an
over
temperature
aerial
per
current
event?
And
we
don't
really
try
to
say
that,
because
existing
devices,
an
existing
you
know,
infrastructure
is
already
modeled
is
already
defined
and
we
just
need
to
figure
out
how
to
model
it.
So
you
know
that's
sort
of
the
background
on
what
we
mean
by
events
and
actions
in
one
data
model,
and
then
this
morning
we
have
this
discussion
around
event,
condition
action
pattern
and
I
was
quick
to
point
out.
D
Maybe
maybe
this
would
be
a
good
way
to
start
the
discussion
that
really
the
way
we
use
events
and
actions
in
IOT
applications
is
closely
related
to
the
event
condition
action
pattern,
because
we
have
something
that
happens.
We
have
a
rule
that
evaluates
it
and
then
action
that's
generated
to
take
place
so,
for
example,
in
our
smart
things
platform
we
have
the
events
coming
in
from
devices.
D
You
know
the
motion
is
being
sensed
in
your
living
room
or
you
know
someone
turned
the
light
off
in
the
kitchen
and
there
are
rules
that
we
set
up
and
behaviors
that
we
set
up
to
respond
to
these
events
and
they
generate
commands
to
oh
when
this
happened
to
do
this.
This
other
thing.
So
to
me,
that's
a
the
way
that
events
and
actions
on
IOT
devices
that
we're
talking
about
are
used
is
in
a
pattern,
that's
very
similar
to
event
condition
action
with
that
I'd.
You
know
enough
for
discussion
so.
I
So
there
is
other
places
where
this
formalization
is
being
adopted
and
done
and
I
think
that
is
good,
because
the
more
people
do
it,
the
better
is
understood
and
the
better.
It
is
understood
how
conditions
and
actions
actually
late
and
hope.
For
example,
an
action
could
be
another
event,
omission
and
such
so
maybe
an
action
is
creating
a
new
event
and
so
on
earth
has
changed
and
yeah.
So
we
are
not
doing
this
alone.
If
you
would
adopt
that
model
at
some
point
and
that
is
actually
I
think
a
good
good
start.
I
D
The
other
observation
that
I
made
now
I
guess
to
back
up
a
little
bit:
I'm,
not
deeply
aware
of
any
formal
event
condition
action
framework,
so
there
may
be
some
internet
drafts
or
other
you
know,
sort
of
formal
writing,
I'm,
I'm,
I'm,
sort
of
aware
more
of
a
general
design
pattern.
Oh
I
guess
I'm
speaking
more
of
the
general
design
pattern,
but
it
seems
also
that
we
have
a
lot
of.
D
Interest
in
this
group
defining
more
just
events,
actions
and
properties,
but
also
defining
in
a
way
that's
reusable
and
interoperable.
You
know
what
has
all
the
qualities
of
the
other
work.
We
do
to
define
things
like
the
context
of
devices,
so
you
know
machine
parts
or
locations
or
whatever,
and
also
to
define
behaviors
and
behavior,
meaning,
essentially
things
like
rules
and
scenes.
D
That
goes
with
them.
So,
in
a
way,
I
was
interested
in
and
also
this
idea
of
event
condition
action
being
something
that
we
could.
You
know
anchor
on
as
as
far
as
how
we
define
and
rules
and
things
like
that,
I
don't
know,
though
I
don't
know
again.
Is
there
a?
Is
there
already
a
well-known
sort
of
framework
that
has
very
narrow
definitions
for
event,
condition
an
action
that
that
we
need
to
sort
of
take
into
account
here
or
is
it
a
the
general
pattern
that
you're
talking
about
I.
I
The
explosion
and
complexity
can
be
vast
yeah,
especially
with
the
conditions,
so
it
should
be
basic
and
it
should
be
simple
to
interpret
by
every
data
model
are
represented
by
every
day
tomorrow.
That
is
one
of
the
goals
I
think
and
my
yeah
from
the
top
of
my
head.
I
cannot.
The
name
of
the
drop
I
have
a
positive
chat
in
the
next
minutes.
I
D
Well,
it
may
be,
it
may
be
that
we
need
to
understand
how
our
definitions
of
events
and
actions
relate
to
what's
being
defined
there,
but
I
think
our
job
is
to
really
say.
Are
we
happy
with
our
definition
of
what
we
mean
by
event
or
what
we
mean
by
action,
and
what
do
we
need
to
improve
that
or
or
change
it
as
needed?
I
see,
there's
Stern.
A
This
is
really
a
fallacy
of
using
the
same
comes
for
some
country,
different
things,
so
the
end
condition
action
systems
are
the
sub
set
of
rural
systems.
You
may
know
about
don't
know
how
to
pronounce
this
in
English
of
retail
systems.
These
are
really
the
most
powerful
ones
and
in
a
rural
system
you
describe
the
behavior
within
one
system.
A
So
you
might
use
an
incoming
event
as
a
trigger
to
evaluate
your
condition
and
send
an
action
back
to
a
device,
but
that's
that's
completely
outside
the
scope
of
a
data
model
describing
the
interaction,
because
the
whole
ECA
stuff
is
happening
locally
on
one
system
and
yes,
we
may
want
to
have
a
language
for
describing
these
things
and
so
on
and
mobile
code
and
and
lots
of
beautiful
things
can
be
done
there.
But
it's
just
something
completely
different.
A
What
what
the
thing
looks
like
at
the
moment
when,
when
it's
actually
interchanged
so
from
a
data,
modeling
point
of
view,
events
and
and
properties
are
identical,
and
you
can
see
that
by
by
the
fact
that
we
have
frameworks
like
4n,
where,
where
we
have
notifications,
which
some
think
people
think
are
aspects
of
properties,
property
tells
you
when
it
has
changed
and
other
people.
Things
are
aspects
of
events,
and
you
really
have
to
look
at
the
details
of
those
interaction
patterns
to
find
out
what
are
the
actual
semantics.
A
So
there
is
a
very,
very,
very
big
difference
between
a
temperature
sensor
telling
me:
oh,
the
temperature
is
now
80
31
degrees
and
the
temperature
is
now
32
degrees
and
so
on.
That's
a
very
different
thing
from
a
coin
checking
device
that
is
telling
me
somebody
took
put
in
a
coin
and-
and
somebody
put
in
another
coin,
in
one
case,
you
could
just
use
one
of
these
events
and
the
other
event
would
still
mean
exactly
the
same
thing.
A
In
the
other
case,
it's
really
really
important
to
not
lose
those
events
so
that
they
are
semantically
very,
very
different,
and
the
question
in
an
interaction
pattern
always
is
beyond
the
data
model.
What
does
it
actually
mean
for
the
thing
to
actually
happen
to
actually
be
triggered,
and
so
on?
So
the
the
the
event
itself
and
now
I'm
using
the
term
event
in
science
is
of
interest.
So
there
are
event
triggered
and
level
triggered
concepts
in
electrical
engineering,
which
also
have
this.
This
interesting
dichotomy
so
I
think
CA.
A
It's
not
not
going
to
lead
us
anywhere
here,
except
that
at
some
point
it
would
be
nice
if
we
could
see
events
that
are.
We
are
modeling
here
into
and
you
see
a
pattern
and
use
the
same
description
technique
and
then
on
the
other
and
get
out
actions
and
by
the
way,
actions.
Also
have
these
interesting
dichotomy
between
being
non
usable.
A
Somebody
put
in
payment
of
$20
now
what
what's
the
total
paid
amount?
That
would
be
an
action
of
the
non
Brazil
away
and
the
other
one
would
be
set.
The
set
point
of
the
thermostat
to
32
degrees,
where
the
actual
action
is
idempotent,
so
I
think
we
have
to
look
at
the
the
details
here
and
not
let
ourselves
be
misled
by
the
the
beautiful
thing
that
people
only
seem
to
know
three
words
for
these
things,
which
which
are
properties,
events
and
actions,
but
they
all
mean
different
things.
It's
trying
to
use
them.
D
And
really
that
was
the
I
was
trying
to
make
to
say
that
in
our
model
we
mainly
only
describe
the
input
and
output
data
for
events
and
actions,
and
we
don't
really
just
describe
much
about
what
that
does.
So
in
many
cases,
especially
when
the
two
special
cases
that
you
brought
up
and
I'm
only
seeing
four
cases
I'm
sure
it
could
be
more
but
there's
satirist,
which
is
a
what
we
call
an
action.
D
D
Their
state
changes
in
a
state
machine,
whereas
if
you
miss
one,
you
don't
end
up
in
the
same
state
and
actions
are
I.
Think
that's
I
think
it's
a
very
good
point
that
that
some
actions
are
just
setters
and
they
they're
item
potent
and
they
don't
have
that
property
and
other
actions
do
have
that
property
that
if
you
miss
an
action,
you
don't
end
up
in
the
same
state
and
then
the
intended
result
is
not
what
was
expected
and
I
think
this
is
all
an
artifact.
What
happens
between
two
systems?
D
I
think
that's
a
correct
framing.
Also
an
important
training
issue
today
and
I
also
agree
that
ECA
and
I
think
it
was
what
I
was
trying
to
get
at
is.
Maybe
ECA
isn't
helpful
in
defining
what
we're
doing
other
than
as
a
use
case,
but
it
is
sort
of
a
use
case
in
that
I
agree
that
it's
helpful.
If
we
can
define
what
happens
between
events
and
actions,
you
know
in
a
system
as
in
some
commonality
with
the
ECA
framework,
so
I
think.
D
The
interesting
part
of
this
discussion
is
what
do
we
need
to
do
about
reconciling
actions
that
aren't
setters
and
events
that
aren't
property
changes
and
whether
those
needs
different
classes
or
whether
because
modeling
them
on
existing
ecosystems,
tends
to
sort
of
squash
those
definitions?
What
do
we
do
about
that?
What
do
we
need
to
do
and
what.
A
A
Whatever
so
something
is,
I
didn't
put
it
or
it's
not,
and
they
also
have
this
idea
of
something
being
unsafe,
which
is
really
about
when,
when
you
do
it,
it
means
something
in
which
you
do
it
twice.
It
might
mean
the
same
thing
or
a
different
thing,
but
it
the
fact
that
you
didn't
need
something
so
I
think
this.
These
are
actually
two
real
engines.
We
probably
need
a
couple
modern
engines,
and
then
we
can
put
the
various
usages
of
event,
action
and
poverty
into
this.
D
D
All
that
one
way
to
accomplish
that
in
in
our
1
DM
framework,
as
it
is,
if
we
want
to
look
at
just
having
events,
actions
and
properties
is,
we
could
have
some
kind
of
additional
descriptors
for
events
and
actions
that
describe
these
things.
Like
item
potency
and
the
safety
and
things
things
like
that,.
D
But
it
also
seems
like
a
model,
could
it's
simply
model
properties
and
have
these
additional
frameworks,
as
like
protocol
bindings?
It's
it's
really
going
to
another
level
of
you
know:
austerity
and
the
modeling.
But
if
you
you
know
the
core
right,
it's
saying:
okay,
every
we're
already
modeling
events
and
actions,
essentially
as
data
types
that
have
these
additional
semantics
sort
of
hooks
that
give
them
additional
meta.
Meta
operations
like,
for
example,
actions
are
things
that
have
multiple
data
items.
D
You
can
invoke
them
and
there's
possibly
a
long-running
status,
but
we're
really
just
doing
we're
still
modeling
the
data,
but
we're
also
saying
that
there's
a
a
state
machine
semantics
around.
Likewise
with
events,
we're
still
modeling
the
data,
but
we're
implying
a
kind
of
an
interaction
state
machine
with
events
with
properties,
we're
implying
an
interaction
state
machine.
That's
not
always
there
it's
read
and
write,
and
then
you
know
I
guess
another.
One
of
my
points
here
is
that
often
you
have
published
in
subscribing
I
mean,
have
read
and
write
on
the
protocol.
D
You
have
sort
of
you
upload
all
the
state
and
then
you're
sending
for
mental
changes
and
the
read
and
write
only
happens
at
the
you
know:
digital
twin
or
shadow
or
whatever
you
want
to
call
it.
That's
that's
somewhere
else
and
not
on
the
other
side
of
the
the
other
system
right.
So
when
we
describe
interactions
between
two
systems,
we
don't
always
even
have
read
and
write.
So
there's
a
bunch
of
things,
but
it
you
know
again.
D
D
It
makes
sense
to
just
add
things
to
actions
and
events,
to
further
describe
them,
that
that
seems
to
me
to
be
a
forward
approach
forward,
but
but
also
keeps
this
notion
of
actions
and
events,
as
opposed
to
having
only
properties
that
have
different
ways
of
interacting
on
them
as
another
layer
which
actually
seems
like
an
alternative
model.
Now
that
I
think
about
it.
A
A
A
D
In
in
thinking
of
the
boundary
between
two
systems-
and
you
can
even
think
of
a
single
system
that
has
a
boundary
like
this,
what
we
have
are
and
to
just
restate
what
you
just
said,
we
have
properties
that
are
examined
from
the
other
side,
I
like
that,
because
it
doesn't
really
say
how
they
got
there.
Events
and
actions,
though,
do
say
something
about
their
sister
boundary
and
it
says
that
actions
or
things
that
go
from
the
the
right
hand,
side
to
the
left
hand
side.
D
If
you
follow
what
I
mean
that
they
go
from
the
operating
operation
side
operate
or
to
the
operate,
that
I
don't
even
know
what
what
the
terms
are,
but
actions
a
one
direction
into
the
device
from
the
controller
I
would
call
it
a
controller
if
I
was
in
an
industrial
control
system
and
events
go
from
the
device
back
up
to
the
controller,
so
actions
dopin
the
controller
to
the
device
it
from
one
system
to
another.
If
you
played
it
that
way,
and
the
events
go
from
the
device
to
the
controller.
D
Is
that?
And
so
that's
really
the
only
thing
that
we
say
about
them
now.
We
say
the
properties
are
things
that
you
can
examine,
actions
of
things
that
are
transmitted
and
we
could
also
say
asynchronously
in
a
way
on-demand
or
whatever,
from
the
controller
to
the
device
and
events
are
things
that
are
usually
transmitted
asynchronously,
although
we
could
think
about
them
being
batched
and
we
could
think
about
different
methods
of
obtaining
them.
D
Their
happenings
that
have
sequence,
dependencies
and
I
guess
you'd
have
to
say
a
little
bit
more
about
the
semantics
of
events
in
the
reference
dependencies,
but
then
some
of
them
don't.
So
if
we
only
say
that
they're
things
that
are
transmitted
from
the
device
to
the
controller
and
then
we
further
characterize
them
in
the
model
as
being
having
these
qualities
of
either
an
important
C's
safety.
Maybe
we
have
to
identify
some
some
things
for
events
that
say
whether
they're
property
state
changes
or
or
happenings.
D
You
know
whether
they're,
serializable
or
I
want
to
say
monotonic
course.
You
know
we
come
up
with
a
concept
like
that.
That
represents
that
you
can't
drop
them.
For
example,
I
think
I
go
back
to
the
proposal
or
if
I
was
going
to
make
a
proposal.
I
would
say,
let's
keep
actions
and
events
because,
as
you
say,
people
love
them
and
they
kind
of
understand
that
it.
It
has
a
directional
meaning
and
it
has
an
asynchronous
kind
of
connotation.
But
we
provide
enough
descriptors
to
really
in
the
model
nail
down
what
they
do
right.
A
And
then
we
will
maybe
have
three
things:
three
bits
we
can
set
our
nut
set
and
we
will
have
to
find
anything
and
then
we
can
just
go
ahead
and
say:
oh
those
combinations
are
events
and
those
combinations
are
actions
and
those
are
properties.
But
this
is
just
sugar
on
the
the
real
semantics
which
is
based
on
which
of
the
the
bits
is
on
and
which
one
is
not,
and
and.
D
That's
interesting,
that's
yeah,
I
think
it
feels
like
we
could
do.
That
also
feels
like.
We
need
to
now
go
and
think
about.
You
know
some
examples
and,
like
you
say,
does
it
does
it?
Does
it
really
the
the
win
here
as
if
it
can
describe
cried
an
without
having
to
add
passions
and
properties,
I'm,
sorry,
actions
and
events
because
they
don't
exist
in
put
in.
D
I'm
not
saying
that
always
how
it
should
be
done.
It
could
be
that
we
always
want
to
model
things
that
are
called
actions
and
events,
but
the
mapping
on
to
crud
end
could
be
done
without
a
lot
of
gyrations.
Potentially,
although
you
still
have
to
say
how
you
send
multiple
things,
and
you
know
they
may
be
a
different
URI,
there's
still
a
mapping
task
to
do
where
something
at
the
system
that
was
designed
as
as
a
rest,
restful
interactions
from
the
beginning
may
not
have
you
know
things
that
are
easily
well
I.
A
G
H
G
F
D
G
Soliciting
the
service
and
something
back
to
you,
and
that
means
that
either
you
have
to
have
an
open
connection
or
you
have
to
have
a
server
to
make
that
connection
to
deliver
that
message
and
basically
I,
don't
care
what
you
do.
So
if
you
open
a
web
socket
truth
is
also
plenty.
I've
seen
plenty
implementations
that
just
uses
a
WebSocket
for
receiving
events
because
they.
D
D
Then
this
goes
right
back
to
what
you
said
earlier.
It's
like
that.
There's
this!
This
I
forget
what
you
called
it,
but
like
basically,
a
layer,
a
transport
layer
is
really
what
it
is
or
transfer
layer
where
you
decide
how
the
stuff
gets
moved,
but
the
modeling
itself
on
the
data
and
the
qualities
of
data,
don't
need
to
be
tightly
bound
to
any
particular
transport
operation.
D
If
we
can
define
data,
that's
idempotent
and
halves,
idempotency
quality,
a
certain
safety,
it's
confirmable,
whatever
you
can
send
that
as
a
post
and
call
that
in
action
and
that's
what
we
would
do
in
the
modeling,
because
that's
what
everyone's
familiar
with.
Likewise
for
events,
we
come
up
with
data
that
has
particular
qualities
like
serializable
and
monotonic,
and
you
know
whatever,
and
we
could
define
some
levels
of
strictness
or
whatever
sort
of
like
consistency.
D
Oh
sorry,
coherence
protocols
and
you
know-
and
maybe
even
have
you
know
also
you
know
serializable
being
like
you
know
that
definition
right.
So
we
could
have
different
qualities
of
data
that
he
could
even
define
serializable
locks
if
we
wanted
and
then
those
operations
that,
whether
you
do
test
and
sat
on
them
or
whether
you
know
what
you
do
is
part
of
the
protocol
binding.
So
if
we
could
move
it
more
toward
that,
and
certainly
events
are
always
you
know
into
certain
bindings
like
pub/sub-
and
you
know-
you'll
always
have
that.
D
D
Maybe
they
have
society
facts,
they
might
just
be
setters
and
they
might
have
items
they
might
be
an
item
vote
in
and
safe
and
non
confirmable,
and
they
might
look
just
like
properties
and
that
you
would
call
that
a
setter,
but
you
could
still
model
it
as
an
action
in
the
model.
It
seems
like
that's
kind
of
the
direction
that,
in
terms
of
a
practical
direction
that
we
we
could
head
to
really
reconcile
all
of
this
stuff.
B
Comment
on
the
action
part
is
that
I've
seen
it
commonly
described
compared
to
a
a
property.
When
you
invoke
an
action,
you
would
get
a
big
handle,
then
you
can
inspect
what
the
state
of
the
action
will
be.
Cancel
the
action
then
or
get
get
more
information
about.
What's
going
on
with
the
action
where
property,
it's
simply
get
set
and
you're
done
with
it.
A
A
G
Is
a
time
aspect
and
if
you
already
know
what
you're
doing
mulling
wise
can
take
a
long
time,
you
can
model
it
already
in
a
way
that
that
time
aspect
is
being
handled
correctly
by
the
model,
so
action
returns
and
you
get
indeed
information
where
you
can
access
the
if
the
time
expects
duration
press
whatever
on
that
on
our
action,
which
is
this
is
just
a
normal
pattern,
and
that
is
basically
nothing
to
do
with
the
action
pattern
itself.
It's
just
again
a
pattern
on
top
of
the
action
pattern,
yeah.
D
You'd
call
it
like
sequence,
clock
or
something
like
that,
where
you'd
get
multiple
output
data
elements
that
that
had
some
element
of
timing
and
sequence
associated
with
them
and
then
yeah,
you
know
that's
that's
kind
of
the
idea
that
we
we
define
an
action
as
an
action
in
the
model
semantically,
but
we
also
define
its
input,
data
and
output
data
as
having
the
qualities
that
we
we
need
to
make
it
work
right.
So
the
if
it's,
if
its
input
only.
G
That's
why
I
think
an
action
should
just
be
something
simple.
Like
a
soap
call
your
define
what
input
parameters
are
and
you
define
what
output
parameters
are
basically
just
to
see
a
see
function.
You
define
your
inputs
and
you
define
what
is
being
returned
by
the
function
writer
right
about
by
the
argument
list
or
by
the
return
clause
of
a
c
function.
I
think.
G
If
I
just
go
back
to
my
old
days,
when
I
was
very
active
in
the
UPP
forum,
we
had
we,
we
had
state
variables
with
ease,
we
had
more
or
less
like
the
ODN
properties.
You
just
have
setters
and
getters
on
them,
and
then
you
have
actions,
soap,
actions,
it's
the
same
thing
as
we
are
now
defining
with
odm
actions,
and
you
had
events
and
and
that's
what
we
had
to
subscribe
on
it
right.
G
You
just
define
architecture,
you
just
define
what
what
kind
of
data
it
is
and
also-
and
you
would
when
it
when
it
would
be
triggered
by
something
else
and
that
RDD.
I
think
the
concert
feel
that
we
also
do
in
SDF,
which
works
pretty
well.
I
could
map
whole
whole
upp,
all
the
the
architectures
to
as
DF
we'd
be
not
too
much
problems
with
it
and,
of
course,
the
upp
architecture
fills
in
a
few
blanks.
That's
what
we
want
to
do
it
as
DF
as
well,
and
you
want
to
make
that
mapping.
G
D
You
know
maybe
even
a
little
more
abstraction,
but
that's
that
is
definitely
the
pattern
and
I
think
the
idea
that
having
events,
actions
and
properties
where
we're
describing
just
the
data
exchanged,
and
then
you
know
not
really
fight
by
that
I
mean
we
aren't
really
specifying
that
you
have
to
use
a
particular
protocol
that
that
really
is
in
line
with
what
you
were
just
saying
that
that
we
know
what
actions
are
for.
Therefore,
creating
side
effects
the
clipping,
and
we
know
what
events
are
for
and
they're
for
observing
happening.
D
You
know,
and
then
we
have
all
these
other
qualities
that,
even
if,
even
if
you
were
to
define
events
without
you
know,
even
if
they
were
sort
of
tightly
coupled
to
protocol
artifacts
you'd
still
have
to
specify
constraints
on
what
those
protocol
artifacts
did.
So
we
might
as
well
try
to
abstract
them
and
specify
them
as
data
artifacts,
even
though
they're
protocol
artifacts,
but
it
by
that
I
mean
an
event,
isn't
just
a
piece
of
data.
It's
understood
to
be
a
sequence
of
data
items
that
have
certain
qualities
of
sequential.
B
Yeah
I
think
that's
a
good
way
to
summarize
it's
like.
We
have
very
good
points
on
all
around
what
we
have
to
mean
by
this
and
getting
us
some
examples
and
working
through
those
get
it
more
clarity
here,
I'm,
looking
at
the
clock
now
we
have
only
about
20
minutes
time
session.
We
have
one
more
one
more
aspect
we
want
to
cover
in
this
workshop.
B
D
But
that's
that's
all
implementation
detail,
but
essentially
that
the
takeaway
here
is
that
we
wanted
to
find
the
events
and
actions
in
the
context
of
the
qualities
around
the
way
that
data
are
obtained
and
transmitted
without
mapping
them
to
any
particular
protocol.
So
there
are
things
like
idempotent,
safe,
confirmable,
non
confirmable,
input-output,
sequential
monotonic.
You
know
we
need
to
come
up
with
some
words,
but
that's
that's
basically
the
flavor
of
it.
That's
that's.
The
takeaway
I
have
so
far,
I
think.
G
D
That
was
probably
the
wrong:
that's
probably
the
wrong
choice
of
confirmable
and
none
confirmable,
but
I
think
what
I
really
meant
by
that
was
when
I
have
an
action.
Do
I
expect
there
to
be
a
return
to
the
action
or
is
it
more
of
a
fire-and-forget
and
I
think
we
decided
that
that
is
needs
to
be
part
of
the
model?
Maybe
not
in
all
cases,
maybe
sometimes
it
needs
to
be
constrained
in
the
model,
and
sometimes
it
needs
to
be
left
open
to
the
implementation.
D
G
G
D
D
You
could
get
the
events
right
back
in
the
same
channel
sure,
so
what
we
want
to
do,
though,
in
the
modeling,
is
avoid
saying
we
want
to
be
able
to
create
a
generic
model.
It
doesn't
depend
on
any
particular
mechanism,
but
allows
all
those
mechanisms
and
provides
some
application.
Interoperability
at
the
endpoint.
A
F
B
D
H
A
Yeah,
so
I
propose
to
look
at
what
the
procedural
steps
are
to
move
the
specification
forward.
So
we
have
talked
about
technical
issues
for
most
of
the
meeting,
but
I
think
it
makes
sense
to
think
about
what
we
need
to
do
on
the
side
of
organizing
things
and
in
previous
one-year
meetings.
There
was
some
sentiment
that
the
ITF
might
actually
be
a
good
place
to
finish,
to
complete
the
SDF
specification
that
we
have
been
talking
about
today,
and
there
are
good
reasons
for
that.
There
are
also
reasons
against
that.
A
So
I
think
it's
not
not
a
complete
slam-dunk
that
that,
of
course,
we
want
to
do
that.
We
have
to
think
about
that.
So
on
the
plus
side,
we
have
aspects
like
well-defined
process
for
for
turning
out
specifications
and
a
well-defined
way
to
engage
the
community.
So
a
lot
of
the
questions
that
would
have
to
be
answered
within
one
am
how
to
end
in
the
process
already
are
answered
in
the
ITF.
We
could
just
use
that
process.
A
Also,
there
is
an
established
review
process
that
that
is
exceptionally
the
row
and
and
generally
provides
a
significant
quality,
improvement
and
I'm,
saying
that
as
an
author,
that
that
has
been
on
the
receiving
end
of
that
quality
improvement
quite
a
few
times
so
and
sometimes
a
little
bit
hard
to
bear.
But
you
have
to
bear
it.
If
you
want
to
create
something
high
quality,
you
need
some
some
pushback
on
things
that
maybe
weren't
server
and
the
third
thing,
because
people
know
that
this
review
process
happens
in
the
IDF.
A
There
is
generally
a
good
reputation
of
the
documents
that
come
out
of
the
IDF,
the
aseneth
track,
our
sees.
So
these
are
all
good
reasons.
Why
choosing
the
IGF?
What
make
a
lot
of
sense?
On
the
other
side,
there
are
a
few
things
that
really
have
to
think
about,
and
one
thing
is
that
the
IGF
is
not
exactly
the
leading
organization
in
defining
modeling
languages,
so
yeah,
typically
modeling
languages
are
defined
by
by
ISO
and
in
the
same
space
in
which,
for
instance,
programming
languages
are
it's
more
defined.
A
There
are
things
like
UML
and
so
on
and
for
document
modeling
language.
Also
w3c
is
a
very
known
organization,
so
ITF
is
a
little
bit
of
an
outlier
here.
On
the
other
hand,
it
has
happened
so,
for
instance,
ITF
has
its
own
specification
for
syntax
for
modeling
text
based
protocols
called
a
B
and
F
I
TFS
recently
done
CD
DL
for
modeling
Jason
and
see
more
data.
So
it's
not
like
this
has
never
happened,
but
it's
also
not
like
all
the
community.
A
That's
interested
in
standardizing
modeling
languages
is
already
sitting
in
the
room
when
we
start
that
work,
so
we
still
have
to
attract
some
of
those
people.
The
second
thing
that
we
have
to
be
aware
of
is
that
starting
work
in
the
IGF
is
a
relatively
arduous
process
and
also
somewhat
risky.
So
you
don't
always
get
the
result.
That
would
be
logical
from
your
point
of
view.
A
So
yeah
it's
a
little
bit
of
a
game,
so
usually
it
works,
but
it
also
can
turn
out
to
be
a
detour
at
the
end
that
doesn't
lead
to
a
result
and
that
might
cost
us
some
time,
and
the
third
thing
is
that
thorough
process
are
referred
to
above
that
just
takes
some
time.
So
if
we
just
want
to
do
some
rubber,
stamping
on
something,
we
already
is
the
right
way
to
do
things
we
might
go
to
Oasis
or
one
of
these
other
organizations
that
do
rubber,
stamping
ikema.
A
So
the
next
step
we
we
probably
have
to
answer
is
what
is
it
actually
that
we
want
to
standardize
and
clearly
we
want
to
standardize
SDF
the
language,
and
there
are
several
aspects
to
it
and
one
is
of
course
the
structure.
So
so
people
who
are
doing
defining
this
language
think
about
the
language
as
defined
by
a
schema
which
I
think
I
have
pointed
out.
It's
not
all
good
story.
There
are,
of
course,
semantics
and
I
think.
Ultimately,
we
have
to
be
able
to
explain
our
processing
model.
A
A
So
that's
one
thing
and
then,
of
course,
there
is
also
the
the
data
validation
aspect
and
that's
currently
done
by
JSON
schema
hog
in
SDF,
and
we
would
have
to
think
about
good
ways
to
put
these
parts
together.
So,
of
course,
one
one
way
forward
would
be
to
convince
the
IDF
that
the
json
schema
hog
stuff
should
be
standardized.
That
has
not
happened
yet
so
far,
but
there
are
people
arguing
for
that,
so
we
could
put
ourself
on
the
side
of
the
argument.
A
A
Given,
given
that
we
at
some
point
define
what
we
actually
want
to
standardize,
the
next
question
is:
what
is
the
right
structure
organizational
structure
to
do
this
in
and
most
likely?
The
best
answer
is
to
create
a
working
group
in
the
IETF
applications
area,
which
has
recently
been
merged
with
the
real-time
area.
That's
why
it's
called
arch
for
applications
at
real-time
area,
so
that
would
be
a
working
group.
That
partner
would
work
on
one
or
more
internet
drafts
that
contain.
A
I
think
we
need
to
be
able
to
point
to
those
implementation
of
efforts
at
the
point
in
time
when
we
actually
asked
for
creating
a
working
group.
So
the
way
we
get
this
working
group
is
ultimately
to
run
a
buff
which
is
a
weird
world.
The
IDF
uses
for
meetings
in
which
we
decide
whether
we
want
to
take
on
some
work
or
not
to
do
this,
so
we
have
to
create
a
charter.
A
charter
is
a
former
text
that
defines
what
the
working
group
that
we
are
creating
is
supposed
to
do.
A
It
often
comes
with
milestones
there
that
specifically
decide
what
the
outcome
is
supposed
to
be
and
in
order
to
survive
in
above,
we
need
to
demonstrate
interest.
So
so
we
need
to
demonstrate.
There
is
a
chance.
People
actually
will
implement
and
use
this
protocol,
and
it's
not
just
an
academic
exercise,
and
we
also
need
to
demonstrate
that
we
have
a
chance
to
reach
a
consensus.
So
if
there
is
lots
of
industry
interest,
but
the
industry
simply
cannot
agree
on
something,
that's
not
a
good
thing.
A
A
It's
probably
a
good
idea
to
have
some
people
in
mind
who
could
run
this
process
in
a
reasonably
detached
way.
That's
why
I'm
writing
that
they
should
not
be
the
authors,
but
there
will
be
different
people,
maybe
with
some
experience
in
this
space.
So,
let's
all
think
about
people
who
who
might
want
to
do
this
and
finally
slide
on
the
training.
A
The
timing
is
very
good
with
respect
to
the
fact
that
Anu
is
G
will
be
seated
next
week
that
that
ice
tree
will
be
stable
for
one
year
we
always
exchange
one
half
of
the
energy
every
year,
so
we
have
will
have
a
stable
set
of
people
to
talk
to
that's
good
they're.
Not
a
good
thing
is
that
the
IDF
is
in
this
covered,
19
state
right
now.
A
We
are
the
way
we
usually
work
is
completely
disrupted
and
most
people
who
have
a
management
role,
and
that
of
course
includes
the
ASG
are
very
busy
understanding
how
to
continue
to
operate
in
this
environment.
So
it's
probably
not
not
very
successful
to
go
to
the
ladies
next
week
and
say
we
want
this,
but
maybe
after
a
month
or
so,
we
could
be
in
a
position
to
have
these
discussions
and
to
prepare
a
little
bit
of
consensus
that
might
lead
us
to
have
a
buff
at
the
next
IDF
now.
A
The
next
IDF
is
in
July,
and
most
people
who
understand
what
covered
19
is
fami,
that
there's
no
chance
in
on
the
earth
or
in
heaven
are
some
ways
that
this
will
happen.
But
I
think
by
the
time
we
this
is
supposed
to
have,
we
will
have
a
really
fine
way
to
run
this
in
a
virtual
way,
so
I
think
we
should
not
be
discouraged
by
that.
We
could
start
getting
consensus
from
from
the
people
who
run
the
IDF
about
a
month.
I
Idea
is,
and
Carson
mentioned
it
takes
a
long
time
to
get
charged
and
you
get
the
first
RFC
out.
That
is
true,
but
on
the
other
hand,
creating
an
ITF
charter
really
focuses
the
scope
with
a
lot
of
input
and
a
lot
of
people
asking
you.
Why
is
this
not
more
precise,
and
why
are
you
putting
this
in
scope
under
than
that?
I
So
the
review
process
of
chartering
is
also
a
good
enabler,
even
if
you're
not
going
to
be
chartered
and
therefore
become
a
working
group
on
the
ITF
I
think
trying
that
in
creating
the
Charter
focuses
the
work
very
well
and
it
is
a
good
exercise
at
the
very
least,
at
the
very,
very
least,
and
in
the
best
case
scenario,
where
we
become
charter,
did
we
get
charted
in
and
become
a
working
group?
So
that
is
my.
I
D
Think
we're
well
with
a
chance
for
consensus.
We
have
achieved
quite
a
bit
of
consensus
already
and
we
have
a
good
working
process
that
that
sort
of
results
in
closure-
and
we
have
a
lot
of
stuff
to
deal
with,
but
also
you
know,
I-
think
we're
in
good
shape
there
and
on
implementation.
I
think
we're
in
pretty
good
shape,
so
I
don't
think
either
of
those
is
going
to
delay.
This
I
think
that
the
timeframe
sounds
about
right
to
me
to
come
up
with
something
Thank
You
Hank
for
for
that
yeah.
D
D
I
D
So
anyway,
the
first
the
steps
are
to
the
the
first
engagement
is
with
a
Boff.
So
that's
sort
of
the
leading
engagement
with
with
IETF
then
and
for
us
to
do
our
homework
is
create
a
charter
and
probably
start
working
on
what
an
ID
would
look
like
and
those
things
that
Kirsten
had
earlier
than
the
slides
about.
You
know
we
were
gonna,
have
to
demonstrate
processing
model
and
things
like
that.
D
A
D
D
A
A
J
I'm
sorry,
so
this
is
a
I
come
from
Technical
University
of
Munich
and
I.
Didn't
know
when
to
ask
this
question
precisely,
but
from
these
questions
I
see,
the
work
is
really
close
related
to
the
above
thing,
sting
description
and
which
also
has
the
very
similar
model
to
the
STF
model
and
I
couldn't
like
see
like
what
I'd
like
some
more
concrete
differences,
but
then
I
maybe
like
takes
Breen's.
That's.
D
J
F
About
this
but
ike
to
comment
which
at
least
coordinate
some
activities,
there's
one
thing
particular
about
the
json
schema
that
we
definitely
want
to
be
using
the
same
subset
of
JSON
schema
to
be
compatible.
I
think
that's
very
important.
I
think
we
also,
as
Michael
just
say,
we'd
work
up
some
concrete
examples
as
sure
they
work
together
and
where
they're
complementary.
We
are
currently
talking
about
thing
templates
and
about
class
definitions,
and
you
know
pointing
to
things
so.
I
can
I
need
to
think.
F
We
need
to
look
at
how
we
state
formally
relationship
between
a
thing
description
and
what
it
uses.
We
already
have
contexts
those
which
may
be
sufficient
if
we're
including
a
context
but
I,
think
there's
also
the
issue
of
the
TV's,
an
instance
particular
model.
How
do
we
say
that
I
think
it
would
be
nice
if
we
didn't
use
different
terminology
as
well?
So
beginsnow,
you
know,
agree
on
common
names
for
things.
I'll
be
helpful
too
just
make
a
list
and
then
start
figuring
out.
What
would
you
work
on.
J
Just
a
little
on
what
my
crossword
said
and
annotating
descriptions
with
like
similar
at
least
kima
with
one
model
in
classes,
so
I
mean
in
ting
description.
We
also
have
the
the
context
file,
which
contains
the
class
classes,
so
I
can
double
annotate
in
adding
description
already
with
by
using
its
its
its
its
model.
So
it
already
has
a
model
and
I
can
annotate
within
description
model,
editing
description.
So
what
would
add
to
a
team
description
if
I
annotate
it
now
with
one
data
model
model.
D
You
get
application
specific
class
types,
so
you
get
a
light,
switch
or
a
light,
on/off
control
or
a
dimmer
or
control
or
color
control,
with
its
defined
data
types
in
and
out.
So
it's
it's
exactly
like
IOT
schema.
It
defines
the
application
layer
types,
it's
the
application
vocabulary,
if
you
will
for
what
type
of
thing
you're
describing
that
it's
interoperability,
so
essentially
it's
if
I
use
semantic
annotation
that
says
here's
the
thing
description.
D
J
Like
I
totally
understand
that
we
can
buy
for
a
light
switch,
we
can
add
further
antigens,
which
are
like
more
specific
than
just
saying.
It's.
A
property
I
totally
agree
I'm
just,
but
then
this
goes
further
than
the
m's
property
action
event
modeling.
So
so
this
means
you
have
more
specific
classes
like
an
IOT
schema.