►
From YouTube: ASDF WG Interim Meeting, 2020-11-02
Description
ASDF WG Interim Meeting, 2020-11-02
A
A
Anyway,
so
yeah,
the
usual
stuff,
be
nice,
be
professional.
Ipr
guidelines
for
itf
apply
and
there
are
the
links
for
the
our
new
newly
set
up
github
for
the
asdf
group
and
also
for
the
node
for
this
meeting.
C
A
You
know
by
heart
here
is
the
agenda
for
today
introduction
administrative
stuff.
Some
agenda
bashing
will
then
go
through
the
status
update
for
the
asdf
group.
Look
at
the
result
of
the
adoption
call
and
then
head
on
to
the
sdf-101
features.
D
If
we
had
more
of
a
consensus,
I
would
ask
us
to
more
of
a
quorum.
I
would
ask
suggest:
maybe
we
should
think
about
the
post,
ietf109.
A
Yeah
exactly
exactly,
I
think
we
need
to
do
that
at
the
we
have
some
slides
on
that
later
on,
but
yeah
yeah
good
point.
E
One
data
point
is
that
one
dm
is
going
to
a
bi-weekly
scheme.
So
maybe
you
want
to
use
the
other
slot,
but
yeah
you
can
remove
that
out.
D
Yes,
I'm
trying
to
take
notes,
but
good
thank
you
said
anything
so.
A
No,
no,
no,
no,
of
course
not,
but
just
need
to
take
a
note
taker
good.
Then
we
move
on
with
this
agenda
status
update
good
stuff.
We
have
been
chartered
as
a
working
group,
so
we
are
now
up
and
running,
and
this
does.
This
is
the
first
official
meeting
we
didn't
have
a
unofficial
meeting
before
we
were
chartered.
A
But
now
we
are
official
and
up
and
running,
and
the
plans
going
forward
is
to
have
a
virtual
intermediate
today
to
look
at
the
adoption
of
the
first
draft
and
the
content
going
into
that.
A
And
then
our
next
meeting
parts
will
be
or
meeting
events
will
be
at
109
at
the
hackathon,
where
we
have
been
discussing
with
the
randy
group
and
also
in
here
that
we
should
have
a
meeting
to
well.
We
should
we
should
somehow,
during
the
hackathon
work,
a
bit
more
of
some
features
and
a
number
of
at
least
other
sort
of
sdf
related
things
part
of
the
wishy
hackathon
group.
A
A
Yes,
so
that
that's
we
are
moving
along
there.
That's
good.
A
And
then
I
cleared
this
since
last
meeting.
Well,
since
the
unofficial
meeting
I
was
asked
to
present-
or
we
were
off
to
present
this
asdf
work
to
the
omas
blackworks,
the
msc
group,
the
like
redemption
group,
and
so
I
did
so
on
a
week
a
week
ago
and
they
were
quite
interested
in
this
work.
I
told
them
to
join.
A
I
apparently
haven't
so
far,
but
well,
I
totally
joined
anyway
either
an
idea
for
in
the
one
dm
group,
so
so
this
is,
for
the
record
is
slightly
different
than
even,
if
like
with
m2m
and
ipso,
are
closely
related.
A
Yes,
that
was
the
status
update.
Welcome
to
the
adoption
call
in
the
moment,
then
we
had
a
list
on
on
working
group
processes
just
to
since
we're
now
sort
of
official
group
we'll,
as
always,
ensure
to
make
the
decisions
on
the
mailing
list
and
there's
the
list
link
to
the
list.
A
We
do
our
work
on
github
and
there's
a
link
to
the
github
page.
The
sdf
spec
will
be
migrated.
It's
actually
has
been
migrated
already
earlier
today.
A
A
We
are
looking
beyond
109,
we
have
a.
There
will
be
a
we'll
try
to
run
regular
interims
between
the
physic
and
virtual
physical
meetings,
and
we
will
send
out
the
doodle
for
filing
a
meeting
time,
or
I
mean
that
would
be
more.
We
could
have
discussed
it,
but
but
we
will
be
following
that
up
in
the
near
future
and
then
finally,
from
a
process
perspective.
A
One
of
the
points
here,
one
of
the
ideas
here
is
to
as
we
go
along,
we
will
do
intermediary
intermediate
implementation
drafts
of
sdf
available,
and
the
reason
for
that
is,
we
discussed
this
in
the
chartering
process
was
to
have
stable
specs
that
could
be
used
by
the
one
data
model,
folks
and
others
as
kind
of
update
target
for
tool
chains
and
so
on.
A
So
how
we
actually
mark
this
is
to
be
decided,
but
the
intent
is
to
have
semi-regular
at
least
drafts
of
this
kind
as
we
move
along
to
the
final
rfc
yeah.
Any
questions
on
that.
A
A
So
to
the
big
point
of
today:
well,
the
first
big
point
in
today:
the
the
call
for
adoption
on
sdf
one
zero
draft,
and
this
was
sent
out.
A
conference
option
was
sent
out
asking
for
objections
on
october
20th
and
to
my
I
haven't
seen
any
objections
raised
so
far
so
are
there
is
it's?
Are
there
any
final
final
objections
that
somebody
wants
to
raise
here
before
we
adopt
this
draft
going
forward.
A
We
can
say
that
that
draft
is
now
adopted
into
the
astf
working
group,
and
so
it's
now
an
idf
draft.
Great,
that's
very
good.
There
should
be
some
kind
of
sharing
music
here,
but
that
means
we
have
our
first
milestone
put
in
place.
Adopting
that
draft
great.
A
And
we
will
send
out
the
confirming
mail
on
the
on
the
mailing
list
as
well.
So,
oh,
I
see
alan
joining
as
well.
Hi
ellen
welcome.
A
C
A
We
are
moving
along
in
the
in
the
slides
here
so
with
that
we
have
our
first
adopted
draft
in
the
group,
which
means
that
we
can
move
on
to
stf11
and.
A
So
do
you
want
to
take
over
driving
the
slides,
karsten
or.
E
Okay,
first
thing:
we
have
two
issues
that
actually,
if,
if
you
start
looking
closer,
are
rather
related,
so
we
we
have
found
that
the
enum
mechanism
we
have
in
sdf10
is
too
limiting,
and
we
also
have
a
discussion
of
of
the
need
for
general
choices,
something
that
that's
done
with
any
of
in
in
jason,
schema
org.
E
And
if
you
look
at
the
examples
actually
there
isn't
that
much
of
a
difference
between
the
two,
so
the
the
main
perceived
difference
may
be
that
these
look
very
different
than
jason's
being
arc,
but
actually
these
are
just
ways
to
express
choices.
E
And
now
what
is
the
point
of
having
a
choice?
Usually
we
have
different
states
or
different
settings
that
we
start
describing
by
by
giving
them
string.
Names
like
on
and
off
or
enabled
and
paid
for
and
whatever,
and
one
question
that
came
up
in
the
discussion
was:
how
do
these
text
string
names
map
to
semantic
tags
on
on
one
end
and
how
do
they
map
to
implementation
level,
entities
that
that
often
are
integers?
E
So
this
is
the
the
canonical
example.
I
think
that
that's
one
of
michael's,
michael
costas,
examples
where
we
have
an
sdf
property
called
stage
that
is
essentially
a
choice
between
on
and
off.
Of
course,
you
could
simply
describe
with
a
boolean,
but
here
we
chose
to
describe
it
with
two
named
alternatives.
One
called
on
one
called
off
and
we
also
have
a
way
to
put
a
description
there.
E
So
all
this
would
have
been
a
little
bit
more
difficult
by
by
just
using
a
boolean
and
of
course
you
might
also
have
a
third
thing
in
there
standby
heating
up
for
whatever.
So
it's
a
natural
thing
that
the
these
enums
actually
can
be
extended
over
time,
so
starting
with
with
boolean,
gives
you
a
somewhat
sub-optimal
basis
for
for
further
extensions.
E
E
There
are
more
complicated
examples.
Oh
that's
getting
a
bit
small!
You
know
that
you
can
zoom
in
in
your
webex
clients.
E
E
So
the
number
is
something
in
the
range
between
1
and
254
and
probably
an
integer
that
it
doesn't
say
so
and
the
other
one
says
it's
another
choice
which
this
time
is
not
expressed
using
any
of,
but
using
sdf
that
has
a
minimum
device
value
permitted
and
a
set
to
previous
value
state.
E
E
I
have
no
idea
how
how
currents
are
specified
with
numbers
between
1
and
254,
but
you
could
imagine
that
and-
and
the
description
could
describe
this
in
in
more
detail.
So
this
is
an
actual
number
meant
to
be
a
number
on
the
information
model
level,
and
then
there
are
two
cases
which
are
also
expressed
by
numbers
just
because
they
are
in
in
some
ecosystem.
E
Again,
the
the
labels
are
not
semantic,
but
at
least
it's
possible
to
understand
them
as
a
reader
and
the
ability
to
set
integers
here,
maybe
a
bug
or
a
feature
so
that
people
are
debating
that.
E
But
if
the
the
number
or
actually
the
question
whether
this
is
even
represented
as
a
number
is
ecosystem
specific,
then
we
are
carrying
some
baggage
here
in
the
common
information
model
that
that
actually
doesn't
transfer
over
to
to
the
ecosystem.
D
B
Yeah
is.
D
There
accommodation
for
the
fact
that
that
different
ecosystems
could
well
have
completely
different
ways
of
dealing
with
the
things
like
one
of
them
has
one
is
the
highest
number
or
the
brightest,
and
the
one
has
254
is
the
brightest
or
different.
I
mean
I
don't
know,
I
can't
imagine
things
other
than
integers,
but
maybe
there
are,
but
I
guess
does
that
make
any
sense.
What
I'm
asking.
E
D
D
Then,
or
does
it
just
like
I
try
to
understand
if,
if
the
end
result
is
that
the
controller
in
the
middle
has
to
do
some
mapping
like
of
one
to
two,
fifty
five
to
two
one
to
254,
as
you
just
described
with
some
knowledge
of
the
two
sides,
or
is
there
some
other?
D
F
Well,
I
can
throw
in
one
reflection
here:
one
thing:
well:
sdf
can
be
used
for
two
different
things.
One
is
kind
of
like
describing
a
specific
ecosystem
thing
I
mean
kind
of
quite
accurately
and
then
also
specifying
these
is
that
consolidated
models
or
whatever
we
call
them
nowadays,
those
that
have
you
know
much
more
potential
for
actually
doing
the
translations,
and
some
of
these
features
may
be
more
useful
for
one
or
the
other
use
case
of
sdf.
F
So,
yes,
I
can
imagine
you
could
describe
an
ecosystem
kind
of
especially
legacy
models
in
a
way
that
you
don't
get.
You
know
full
round
trip
ability
or
or
like
full
translation
between
different
ecosystems,
but
then
those
constellated
models
would
be
using
a
more
restrict,
more
restricted
set.
That
would
have
more
capabilities
for
that
kind
of
a
translation
and-
and
I
can
imagine
sometimes
we're
gonna
hit
some
cases
where
you
know
all
things
are
translatable
to
all
ecosystems
or
you
may
need
to
do
you
know
human
knowledge
needed.
F
So
it's
not
fully
automated
translation,
but
I
guess
in
practice
we'll
see
where
the
boundaries
between
each
of
the
use
cases
will
settle
when
we
have
more
more
ecosystems
where
we
do
automated
translation.
Now
we
have
just
a
few.
We
have
experience
from.
E
So
one
description
language
I
know
from
a
project
we
had
in
germany
a
while
ago
with
a
german
manufacturer.
They
actually
have
a
linear
transformation
as
a
standard
description
element
they
can
use.
E
So
they
would
probably
say
this
is
a
number
between
zero
and
one
floating
point
number
and
we
just
define
in
our
mapping
file
a
near
linear
transformation
of
that
number
into
the
range
1
to
254.
E
So
that
doesn't
tell
you
how
to
handle
running
errors,
but
it's
a
very
flexible
way
to
to
handle
this
situation,
and
it
puts
as
little
as
possible
knowledge
about
the
specific
ecosystems
into
the
common
model.
A
E
Yeah,
the
the
problem
with
these
mapping
schemes
is
that
they
tend
to
grow
so
in
94
I
I
wrote
a
paper
in
which
I
argued
that
any
extension
language
is
inevitably
going
to
grow
to
a
touring
equivalent
language
and
that's
probably
exactly
what
we
don't
want
to
happen
here.
E
So
I
think
we
have
to
to
look
at
the
landscape
here
and
see.
Is
there
a
reasonable
set
of
things
that
that
we
actually
can
do
in
these
mapping
rules?
So
we
can
can
rest
on
our
laurels
there
and
make
the
actual
common
models
extremely.
A
If
we
want
to
translate
back
and
forth
to
the
to
the
to
the
various
ecosystems
we
could
I
mean
that
that
is
a
way
to
measure
right
if
the
translation
is
simple
or
not,
that's
more
like
more
of
an
engineering.
E
So
I
think
we
want
to
keep
the
freedom
to
actually
use
something
like
that
in
in
the
converged
data
models,
but
we
also
probably
don't
want
to
put
too
much
mapping
information
into
the
converged
models,
but
these
should
be
in
the
mappings
that
come
with
the
converged
models
for
for
each
ecosystem.
E
Okay,
but
what
I
really
want
to
show
in
this
example
was
that
there
are
two
constructs
here:
one
is
called
any
off
and
the
other
one
is
called
sdf
enum
and
really.
The
only
thing
that
differs
between
them
is
that
in
one
case,
the
the
it's
described
by
an
array
with
unnamed
entries
and
in
the
other
case,
it's
described
by
a
map
with
named
entries
and
that's
the
kind
of
unnecessary
choice
that
you
definitely
don't
want
to
have
in
a
specification
language.
E
E
So
michael
costa,
finally
added
another
example,
and
that's
in
his
now
in
his
way
of
writing
json,
so
imagine
that
there
are
quotes
and
colons
and
other
things
in
there,
but
I
think
you
can
kind
of
guess
what
what
he's
trying
to
do
there.
E
So
he
has
a
property
here
that
has
a
choice
between
three
cases.
The
cases
are
actually
labeled,
but
the
the
label
is
in
the
alternative.
It's
it's!
Not
a
label
given
by
the
choice
to
the
alternative.
That's
in
the
alternative
and
yeah
all
three
are
numbers,
and-
and
they
have
certain
ranges-
and
this
essentially
could
be
modeled
in
in
very
different
ways.
But
this
is
of
course,
one
way
to
model
a
range
of
numbers
where
sub-ranges
have
have
specific
semantics,
like
warm,
neutral
and
cool,
and
so
on.
E
E
So
you
you
actually
can
reference
a
type
from
somewhere
else,
and
in
that
case
it's
actually
also
not
not
strictly
necessary
for
the
alternatives
to
be
non-overlapping
in
their
values,
because
you
actually
have
the
label
there.
So
this
is
a
little
bit
of
a
trickier.
E
Made
so
on
the
next
slide,
you
can
see
how
how
I
would
have
written
it,
so
the
the
label
doesn't
become
part
of
the
type.
It's
part
of
the
choice.
E
So
this
is
still
missing
a
number
of
things
here.
This
is
not
my
actual
proposal,
because
it
doesn't
say
that
this
is
a
choice.
That's
one
problem
and
the
other
problem
is
that
it
doesn't
really
indicate
optionality.
E
We
currently
have
this.
This
ugly
required
thing
yeah,
but
let's
keep
it
at
that.
So
I
think
this
is
the
the
rough
direction
we
should
be
going
in.
So
in
the
end,
both
enum
and
and
and
any
of
proposal,
move
into
this
single
way
of
doing
a
choice.
E
So
people
who
import
json
schema
org
would
have
to
translate
any
offs
and
and
enums
into
this
common
scheme
and
vice
versa.
Okay,
so
this
is
my
view
of
the
the
choice
situation.
F
I
actually
have
a
question
yeah
I
mean
it
might
be,
because
I've
been
out
of
the
discussions
for
a
while.
So
can
you
remind
me,
what
are
we
exactly
trying
to
express
here?
F
E
The
the
specification
there
doesn't
really
say
what
the
point
of
that
number
is,
so
I
I
cannot
answer
that
question
for
you.
E
Yeah,
but
I
think
the
criticism
here
could
be,
this
could
be
a
number
that
just
happens
to
encode
two
values:
the
composition
of
two
values,
and
one
is
the
warm
neutral
cool
choice
and
one
is
a
number
between
0
and
85
within
that
choice.
F
C
F
E
That
is
the
direction,
and
the
next
step
would
be
to
come
up
with
a
concrete
proposal,
so
we
can
and
see
how
that
proposal.
What
would
answer
all
the
little
detail,
questions
that
are
still
open
in
the
examples.
A
E
E
C
A
E
Say
how
to
compose
types
out
of
components
so
this
time
this
is
not
a
choice,
it's
actually
putting
in
all
the
components
in
into
a
more
complex
type,
and
it
has
been
called
complex
types
before,
but
I
think
that
that's
not
not
specific
enough.
So,
let's
talk
about
composing
types
out
of
components
and
that
that's
the
issue
number
four
and
the
the
ugly
thing
is
that
we
we
can
do
this
for
some
cases
already
in
sdf
1.0
in
particular,
for
for
actions
and
events
in
a
slightly
weird
way.
E
But
we
cannot
do
this
for
properties
right
now,
so
that
definitely
needs
to
be
fixed
and
again
we
we
don't
have
a
good
way
to
describe
optionality,
so
we're
doing
this
with
sdf
required
at
the
moment.
But
the
main
reason
for
that
is
simply
that
we
don't
have
a
syntactic
place
to
to
put
in
the
optionality.
E
So
there
are
again
two
ways
of
doing
this.
One
one
is
to
to
say
like
the
the
current
1.0
does.
This
action
has
the
following
three
types
as
parameters
that
has
a
problem
in
that
there
is
no
way
to
actually
name
the
parameter.
E
So
when
you
put
in
something
like
a
color
component
value,
you
don't
know
whether
that's
actually
red,
green
or
blue,
or
we
could
actually
give
them
names,
just
as
I've
been
arguing
before
that,
we
should
be
giving
choices,
giving
the
alternatives
in
your
choice
names,
I'm
arguing
that
we
should
give
the
components
in
a
composite
type
names.
E
So
I
think
that
that's
pretty
straightforward
and
then
kind
of
obvious.
The
other
question
that
has
come
up
is:
do
we
stop
at
composing
types,
which
is
something
that
that
we
definitely
understand
how
to
do
or
do
we
actually
want
to
compose
affordances?
E
E
So
the
the
easy
part
is
in.
In
that
example,
let's
say
we
have
a
property
called
compound
one
that
actually
is
the
value
of
which
is
actually
built
out
of
two
data
items.
Then
we
could
specify
it
using
a
syntax
like
this.
E
This
is
actually
out
of
the
the
issue,
so
michael
proposed
using
sdf
data
for
this
another
way
would
be
to
use
reuse.
The
term
object
like
it's
used
in
json
schema,
but
we
would
probably
give
it
a
little
bit
different
semantics,
so
maybe
even
coming
up
with
a
third
name
would
be
possible.
E
So
what
what's
magenta
in
this
slide
is:
is
a
data
schema?
So
that's,
it
looks
like
a
json
schema.
Aux
schema
and
the
the
green
thing
is
the
the
composite
schema
that
is
built
out
of
these
two
elementary
schema.
So
we
we
have
a
type
at
the
end
that
has
two
fields
called
element,
one
and
element
two,
and
these
are
of
type
number
and
string.
E
So
this
is
kind
of
obvious.
The
only
thing
that's
missing
here
is
optionality,
and
maybe
even
repeatability,
because
we
can
always
put
put
in
an
array
if
we
want
repeatability.
So
maybe
we
don't
need
that,
but
optionality
is
something
that
often
is
desirable
and
yeah.
We
could
of
course,
do
the
same
thing.
We
do
for
repeatability
and
invent
an
optional.
A
A
F
Yeah
I
I
actually
already
commented
on
on
this
in
in
github,
and
I
think
I
requirement
that
I
think
is
important
here
on
our
design.
Is
that
we're
able
to
flatten
the
compound
structures
for
those
ecosystems
that
don't
have
the
compound
like
this
right
now,
but,
for
example,
in
in
ipso
models?
F
E
F
You
use
you
see
it
on
the
wire.
Basically,
there's
there's
a
you:
the
property
gives
you
the
new
object
and
the
object,
I
instance
id
the
object
id
and
inside
the
user
lookup
so
yeah.
It
actually
works
in
the
wire.
E
Yeah,
so
maybe
you
could
put
an
example
somewhere
that
shows
how
how
this
is
done
in
episodes.
So
we
can
look
at
how
to
do
this
at
the
stf
level.
F
E
E
So
how
do
we
share
elements
of
a
specification
both
within
the
specification
and
between
specifications?
That's
issue
number
three,
and
we
have
a
bit
of
an
answer
to
that.
So
the
the
current
spec
says
how
to
use
json
pointers
to
do
this,
but
we
haven't
really
tested
that,
so
we
are
not
quite
sure
how
we
would
run
the
management
of
that
space
and-
and
we
have
to
find
that
out
so
before
we
can
go
into
the
details,
we
probably
have
to
decide.
E
What
can
we
actually
reference
in
stf10?
That's
always
a
data
type
and
we
essentially
only
can
reference
data
types
that
are
defined
in
an
sdf
data,
so
the
the
the
reference
is
a
universal
construct,
so
it
could
be
used
for
referencing
something
else,
but
I
don't
think
we
provide
the
semantics
for
what
that
would
mean.
E
So
we
we
probably
have
to
think
about
the
need
to
reference
and
then
maybe
combine
so
we
go
back
to
the
composition
issue
entire
affordances
and
another
interesting
thing
about
references
is
that
you
sometimes
want
to
have
something
that
is
very
much
like
something
else,
but
not
exactly
like
it.
So
there
may
be
a
desire
to
alter
a
referenced
type
or
affordance,
and
actually
1.0
has
something
there.
But
again,
that's
that's
pretty
much
untested,
so
we
need
to
find
out
whether
that
that
actually
makes
sense
in
the
next
slide.
E
That
says:
oh
I'm,
I'm
almost,
but
not
entirely
like
a
length,
but
my
minimum
actually
is
0.05
so
that
that's
a
reference
that
actually
alters
the
definition
or
make
makes
a
copy
of
the
division,
and
then
it
goes
ahead
and
alters
that
so
it's
a
sub
type
in
in
some
way
and
of
course,
obvious
thing
that
comes
up
here.
Cables
must
at
least
be
five
centimeters.
E
Is
that
something
that
adds
to
the
description
in
the
base?
Or
is
it
something
that
overrides
that
we
probably
want
to
have
a
very
simple
way
of
doing
this,
so
so
it
doesn't
become
too
complicated.
E
E
Uses
a
data
type
and
modify
that
so
we
have
an
unnamed
data
type
that
is
then
used
for
the
property
cable
length,
and
I
think
that
that's
again
something
that
should
be
possible-
and
I
think
that
poses
essentially
the
same
question
that
the
previous
slide
does.
E
E
Now
what
we
have
defined
in
1.0,
what
have
an
exercise
is
an
import
export
system.
So
when
we
have
one
specification
that
defines
a
length
type
and
does
this
in
a
namespace
that
is
called
moo
inside
the
specification
and
that
namespace
is
identified
as
default.
Namespace
then,
essentially,
this
the
yellow
specification
specifies
that
goes
into
https
example.com,
slash,
sdf
data
length
and
from
a
different
specification,
the
white
one.
Here
we
can
reference
it
by
giving
the
namespace
a
local
name
which
need
not
be
the
same
one.
So
it's
not
new
but
foo.
E
In
this
example,
and
then
by
using
foo
colon
slash,
sdf
data,
slash
length,
we
can
reference
that
specification.
So
it's
pretty
much
what
was
in
the
previous
slide,
but
it's
it's
distributed
between
two
specifications.
E
So
the
idea
cannot
be
that
we
use
the
namespace
identifiers
for
for
dereferencing
such
a
namespace
identifier
and
then
then
find
that
somewhere,
because
that
means
we
we
need
centralized
management
of
of
these
of
each
namespace
and
that
that
makes
it
really
hard
to
do
things
like
experimental
versions
of
of
documents
and
the
whole
process
becomes
complicated
when
you
have
to
give
provisional
specifications
different
namespaces,
because
the
the
real
one
is
the
serious
one
and
you
cannot
touch
it
and
so
on.
E
So
within
the
playground,
for
instance,
we
could
say
playground.
Specifications
can
only
ever
reference
data
from
other
playground,
specifications
or
from
converged
specifications,
and
then
we
would
have
a
clear
well-delimited
domain
where
these
names
are
actually
resolved.
E
E
E
So
this
is
my
response
to
to
the
issue
three
about
references
and
again,
I
think
we
have
a
pretty
clear
direction
which
is
trying
out
what
we
already
have
and
then
we
have
to
take
it
from
there.
A
C
F
Yeah,
I
think
this
also
looks
good
one
thing
to
consider
on
the
descriptions
is
we
may
want
to
have
on
two
levels
of
descriptions.
One
is
that
is
especially
for
these
reusable
data
properties.
F
One
is
kind
of
the
generic
description
and
the
second
one
is
description
of
that
thing
in
the
context
where
it's
used,
that's
something
what
we're
currently
wasn't
lacking
in.
You
know
in
ipsa
models,
but
something
I
would
love
to
have
there
too.
That's
something
might
be
a
useful
feature,
because
it's
very
hard
to
do
good
generic
description
that
fits
in
all
the
contexts
nicely.
F
Yeah,
I
think,
like
one
of
them
was
a
a
property
called
level
and
you
would
like
to
use
the
same
level
on
a
a
a
dimmer
and
on
a
buzzer
and
yeah.
You
cannot
write
there.
This
is
the
you
know,
intensity
of
the
light
or
the
volume
of
the
buzzer,
because
it's
level,
I
think
that
was
one
of
the
where,
where
we
struggled
back
in
the
days.
D
How
is
the
intention
that
we
could
say
run
it
at
50
of
the
quote
level?
Was
that
what
you
want
to
be
able
to
do,
or
is
there
something
else
that
I
don't
understand.
F
For
example,
yeah
yeah,
so
so
what
the
the
good
thing
about
having
this
generic
level
property,
is
that
you
would?
You
know
when
you,
for
example,
do
a
ui?
You
would
have
some
kind
of
you
know
a
dial
for
the
person
to
tweak
hey.
You
know,
I'm
changing
the
level
of
this
thing
and
instead
of
having
you
know,
audio
level
and
light
level
different
things
you
could
actually
have
them
in
the
same,
but
then
have
kind
of
this
additional.
F
D
A
So
I
guess
we
do
have
a
way
forward
here
as
well.
Right
did
you
did
you
have
note,
I
mean
yes,
as
carson
said,
you
had
a
good
point
there.
So
a
good
example.
Can
you
write
that
up
in
the
issue
as
well?
So
we
don't
remember
things.
A
Okay,
yeah,
I'm
done
let's,
let's,
let's
you're
done
yep.
A
A
Nope,
so
with
that,
we
have
gone
through
the
three
or
four,
depending
on
how
you
count
them.
Issues
that
are
were
proposed
already
back
in
one
dm
days
to
be
their
sort
of
sdf-11
features
and
the
missing
bits,
and
I
guess.
A
A
Big
features
that
are
missing
right
now,
so
I
think
these
features
are
worth
the
components
to
bring
in.
I
mean
they're
complex
enough
to
be
some
tool,
workers
so
needed
to
bring
into
one
one
and
have
then
have
one
one
released.
As
a
as
I
talked
about
this
intermediate
implementation
draft.
A
A
E
Well,
we
have
a
up
to
the
hackathon.
We
have
hackathon
week.
Nothing
will
happen
during
the
iatf
week
and
then
the
week
afterwards,
that's
thanksgiving
week,
but
for
for
the
europeans
among
us,
that's
a
good
way
to
get
work
done.
E
F
A
B
A
And,
of
course,
there
is
a
because
we
only
have
aob
business
here.
There
is
one
thing
that
I
was
thinking
of,
but
actually
forgot
to
put
into
the
agenda
here,
which
is
slightly
related
to
this,
and-
and
this
is
of
course,
that
we
should
look
at
various
ways
of
of
reaching
out
to
other
iot
ecosystems
that
are
not
part
of
one
dm
for
whatever
reason
and
if
they
want
to
sort
of
pitch
in
and
have
their
particular
ideas
and
so
on.
A
So
any
suggestions
to
about
wasn't
what
ecosystems
to
research
to
reach
out
to
and
also
sort
of.
If
we
have
good
entry
points
into
other
ecosystems,
that
would
be
valuable
to
have
here.
D
But
I
think
that
maybe
opcua
has
gotten
is
fallen
through.
There's,
probably
some
other
transport
focused
ones
that
maybe
some
siemens
people
would
know.
I
don't
know
like.
In
other
words,
I
probably
don't
know
what
they
are,
and
I
don't
know
if
the
automotive
space
is
even
close
to
the
point
of
having
regular
object
models.
I
think
they're
well
they're
still
arguing
about
connectors
and
wires
right
so,
but
there
may
be
some
work
there
that
we
just
I'm,
I'm
I'm
ignorant
of.
D
Means
adopting
each
other's
protocols,
which
they
don't
want
to
do,
but
but
sdf
kind
of
isn't
doing
that
right.
So
maybe
it
would
work.
Maybe
there's
maybe
there's
some
more
presentations
like
the
one
you
did
last
week
that
are
would
be
in
order
yeah.
D
I
I
what
I
know
of
it
comes
from
one
automotive,
ethernet
conference
I
went
to
in
february
in
munich,
which
is
where
I
learned
that
they
were
hyper
obsessed
about
security,
but
didn't
really
know
what
to
do
anything
about
it
and
and
and
yet
still
arguing
over
the
shape
of
the
connectors
and
the
logic
of
the
wires
and
the
you
know
ethernet
versus
can
plus,
plus
plus
versus
other
stuff.
D
But
anyway
I
pasted
in
the
notes
I
pasted
the
december
calendar
hearing
that
you
said
we
thought
we
could
have
all
of
november
to
nail
this
down,
and
so
the
question
was
whether
there
was
a
worth
having
a
virtual
interim
in
december
to
provide
a
a
a
deadline
to
this
or
whether
that
may
make
sense
to
do
this.
In
january.
Beginning
of
january,.
D
E
A
I
wasn't
at
the
meeting,
but
the
bi-weekly
schedule
was
discussed,
but
I
guess
we're
moving
to.
They
were
earlier
at
hours
that
were
not
nice
to
our
pacific
coast
team
members.
C
E
D
A
A
Exactly
so
so,
but
on
the
14th,
and
we
have
to
call
for
that
two
weeks
in
advance,
so
I
I
think
we
should
look.
I
think
we
should
have,
let's
let's
say
14th
for
now
and
then.
C
A
Yeah
but
but
also
as
we
get
around
the
later
half
of
november,
we
can
see,
I
mean,
are
we
getting
anywhere
or
are
we
not
getting
anywhere
and
if
we
are
getting
anywhere,
then
I
mean
we
should
roll
with
that?
A
D
Sounds
good
to
me,
so
I
think
we've
got
to
the
end
of
the
meeting.
I
will
make
sure
that
the
youtube
link
when,
as
soon
as
I
see
it,
reposted
by
the
secretariat,
I
will
make
sure
that
gets
posted
into
the
list,
and
maybe
some
people
will
watch
the
watch
our
meeting
and
wish
to
comment
since
we're
so
small
and
we
should
find
out.
We
should
probably
reach
out
to
the
people
we
expected
to
come,
find
out
why
they
missed
it.
And
what
do
we
do
to
fail
to
capture
their.
D
Yeah
we'll
go
through
the
doodle
and-
and
there
may
be
some
other
names
that
we
didn't
we
missed.
I
will
I
will
go,
pull
up
the
doodle
and
and
do
that,
but
maybe
you
list
your
message
to
the
1dm
list
obviously
was
late.
So
I'm
not
on
that
list.
D
F
Good
one
quick
question:
are
we
collecting
already
backlog
for
1.2.
F
I
was
wondering
there
was
some
discussion
in
the
in
the
idf
meeting
when
this
was
presented
in
the
both
about
being
able
to
add
more
descriptions
about
those
affordances.
I
think
it
was
something
on
reliability.
If
I
remember
correctly,
I
was
wondering
was
that
followed
up
on.
A
D
A
The
problem
with
no
I
mean
and
the
problem
with
that
was-
and
that
was
not
asked
for
by
the
by
the
in
the
charter
during
the
charter
discussion
either.
I
think
the
problem
with
that
request
was
to
have
more
psa
soft
requirements
like
performance,
reliability
and
so
on,
included
here
and
given
that
none
of
the
ecosystems
today
model
those
and
that
I
guess
I
mean
it's
probably
a
whole,
I'm
not
saying
that.
A
I
mean
it
really
is
super
cool
to
have
it
there,
and
I
mean
they
also
ask
for
things
like
traffic,
like
kind
of
traffic
parameters
or
traffic
dimensioning
parameters
and
stuff.
I
don't
think
that
seems
like
sdf
needs
to
rely
on
other
people
defining
those
terms
first,
and
then
we
can
bring
them
in
rather
than
the
other
way
around.
A
E
I
have
nothing
to
say
you
guys
are
doing
a
great
startup
here.