►
From YouTube: ASDF WG Interim Meeting, 2020-10-12
Description
ASDF WG Interim Meeting, 2020-10-12
A
A
C
A
Well,
not
necessarily,
let
me
see
here,
oh
how
we
are
on
the
we
have.
Some
folks
are,
maybe
not
so
so
familiar
with
this,
so
I
would
say
yes
yeah.
This
is
a
rough
timeline
and
it's
also
about
if
we
get
questions
or
discussion
points,
so
that
this
is
a
rough,
I
would
say
a
rough
outline,
of
course,
the
faster
we
can
get
through
the
tutorial
and
the
background
stuff,
the
better
it
is
so.
D
D
A
Okay,
so
well,
of
course,
since
most
of
you
here
are
familiar,
but
still
we
wanted
one.
At
least
one
interest
slide.
What
is
asdf
and
super
briefly?
This
is
the
iftf
working
group
that
that
is
being
formed
to
specify
the
semantic
definition
format,
and
it
follows
up
on
above
with
the
same
name
that
took
place
at
ietf108
and
then
what
is
sdf?
We
will
talk
a
lot
more
about
that
or
carson
will
talk
a
lot
more
about
that
in
a
moment.
A
Briefly,
it
was
created
by
the
one
data
model
group
and
as
the
way
to
describe
iot
device
information
models
in
a
highly
portable
fashion
to
to
improve
semantic
interoperability
across
different
iot
ecosystems,
and
the
first
spec
is
well
the
outcome
of
the
one
data
model
work
and
which
is
now
the
input
to
this
work.
Is
this
sdf
the
first
sdf
spec
sdf10
and
it
is
there's
a
link
there?
A
So
the
question
is,
of
course:
where
are
we
now?
We
are,
I
shouldn't
say
limbo,
but
we
have
passed
the
isg
reviews
as
we
understand
it.
There
are
no
final
objections.
We've
sent
the
final
charter
to
barry,
and
so
really
we
should
be
up
and
running
any
day
now.
So
I
guess
it's
just
basically
a
couple
of
days
off
until
we
are
formally
a
working
group
and
that's
also
one
reason
why
we
have.
B
A
Unofficial
meeting
here
today
that
we
can't
really
call
for
a
meeting
until
we're
really
working
group,
the
chairs,
michael
richardson
or
myself
nicholas
bell,
and
here
are
the
rough
plans
from
which
is
a
meeting
perspective.
We
have
this
hallway
meeting
today,
just
to
get
going
and
do
a
brief
tutorial.
A
We
have
a
virtual
interim-
hopefully
in
about
two
weeks
time,
so
we
can
call
for
adoption
on
the
on
the
first
draft,
then,
as
we
get
closer
to
iftf
109,
we
plan
to
do
some
in
the
hackathon
week
before
itf-109.
Do
some
preparation.
Work
for
sdf-11
have
a
long
list
of
ideas
there
and
then
for
the
actual
ipf
109.
A
There
is
a
two-hour
meeting
slot
requested,
so
we
will
meet
them.
Yes,
and
if
you
have
no
idea
what
that
one
data
model
is
kirsten
will
talk
more
about
this.
This
is
a
in
a
nutshell,
picture
that
I
used.
Basically,
the
problem
we're
trying
to
address
is
that
there
are
several
standardized
data
models
and
but
there's
a
lack
of
input
in
probability
across
these
ecosystems
which
making
integration
a
hassle
to
address
that
we
tried
two
solutions:
one
was
to
select
one
ecosystem
and
everybody
joins
that
and
that,
of
course
did
not
work
out.
A
A
Then
we
have
work
on
tool
chains
that
translate
between
sdf
and
the
various
ecosystems
and,
of
course,
we're
also,
while
we're
at
it
we'll
be
developing
a
set
of
iot
device
models
or
iot
data
models.
That
can
be
widely
reused
and
if
you
want
to
know
more
about
onedatamodel.org,
there
is
the
link
there
at
the
bottom
1dm.org
nicely.
A
E
E
E
There
is
some
new
discussion
in
there,
so
the
the
image
that
niklas
showed
should
have
made
here
what
we
are
trying
to
do
here.
So
we
have
several
ecosystems,
specific
sdos,
standard
development
organizations
in
iot
these
days,
and
they
usually
do
their
own
data
models.
They
don't
often
actually
call
them
data
models,
but
that
is
changing
anyway.
E
They
standardize
the
the
data
that
their
iot
devices
are
thinking
and
they
have
their
own
way
to
document
them
as
well,
and
given
that
applications
may
need
to
work
with
things
that
are
standardized
in
in
several
of
these
eco
systems,
we
we
are
in
a
position
where
we
actually
need
to
translate
model
information
between
the
ecosystems
and
well.
One-To-One
translators
are
hard
to
do
because
really,
there
are
hundreds
of
these
data
models,
so
at
some
point
in
2019
people
decided
to
to
start
liaisons
liaison
work
between
the
different
sdos.
E
These
interactions
are
defined
by
affordances.
This
is
a
gemstone
from
from
interface
design,
where
you
have
a
device
with
a
button
and
a
knob
and
so
on.
These
are
affordances
and
we
use
them
for
the
different
kinds
of
inaction
that
a
device
can
have
like
reading
the
temperature
and
setting
a
set
point,
and
things
like
that.
E
So
these
performances
are
not
completely
random
that
we
found
that
we
have
three
major
interaction
patterns,
property,
action
and
event.
This
will
probably
refined
at
some
point
in
time,
but
right
now
it's
a
good
way
to
start
and
what
sdf
essentially
does
is
is
naming
these
patterns
and
providing
models
about
the
data
that
these
interaction
patterns
exchange.
E
So
when
you
read
the
temperature,
you
probably
get
something
that
looks
like
a
number
and
then
you
need
to
know
what
unit
that
number
is
in,
and
maybe
other
information
as
well
like
when
was
the
sensor
last
calibrated
and
so
on.
So
this
is
the
kind
of
data
we
want
to
define
in
the
simple
definition
form.
So
it's
not
a
general
data
modeling
tool,
it's
a
tool
for
modeling
the
data
that
are
interchanged
as
part
of
performing
an
interaction
pattern.
E
E
Sdf
1.0
contains
everything
that's
needed
for
that,
but
we
haven't
actually
started
exercising
that.
So
I
would
say
that
the
mechanism
that
is
in
sdf
1.0
is
untested
and
we
really
have
to
start
making
use
of
that
to
to
be
able
to
say.
Okay,
that's
really
it.
We
can
live
with
that
and
we
probably
will
come
up
with
a
few
tweaks
for
stf
1.1.
E
E
So
let's
talk
about
those
interaction
patterns
and-
and
I
said
there
are
properties,
actions
and
events,
and
these
actually
come
in
in
some
variations
so
that
there
are
readable,
read-only
properties.
There
are
writable
properties
and
if
you
are
used
to
thinking
of
devices
in
terms
of
rest,
then
this
slide
is
useful
for
you.
Otherwise
it's
maybe
not
that
useful.
E
So
a
property
has
something
like
a
get
operation
where
the
client,
which
is
not
not
in
dm
term,
not
an
sdf
term.
But
it's
a
rest
term
where
the
client
can
take
the
initiative
and
and
read
some
data
and
a
property
can
sometimes
be
put.
For
instance,
if
it's
a
set
point
or
something
that
it's
not
just
a
measurement,
there
are
actions.
E
So,
for
instance,
there
there
might
be
an
action
to
switch
to
a
different
scene
in
the
lighting
system,
or
actions
are
modeled
as
post
interactions
and
they
have
input
data
and
they
also
have
output
data.
And
finally,
there
are
events
which
don't
directly
exist
in
rest,
there
various
hacks
to
add
events
to
rest
and
there
the
initiative
is
on
this
thing
side.
Something
has
happened
and
the
the
thing
wants
to
let
you
know-
and
this
is
essentially
providing
some
output
data.
E
So
we
see
we
have
mostly
about
multiplications
and
we
have
a
little
bit
of
interaction
specification
as
well,
so
yeah,
how
you
exactly
do
this,
maybe
a
little
bit
different
in
different
applications.
So
in
the
rest,
application
an
action
might
have
something
created
that
will
provide
event
like
things
while
this
event
action
is
going
on
and
so
on.
E
E
E
So
is
it
a
single
number
or
is
it
maybe
an
array
of
numbers,
or
is
it
a
string
and
these
these
data
definitions
can
be
made
in
an
affordance
definition
or
they
can
be
made
separately
in
particular,
if
you
want
to
use
a
common
data
type,
you
would
do
that
and
for
the
data
definitions.
We
currently
use
a
subset
of
json
schema,
org
terms,
augmented
by
sdf
specific
terms
such
as
content
format,
nullable
scale
whatever,
and
what
we
haven't
really
done.
E
We
have
talked
about,
and
and
probably
a
few
ecosystems
have
prototypes
for-
that
mapping
information
that
provides
a
way
to
bind
these
data
definitions
into
the
ecosystem,
specific
formats
and
encoding.
So
it's
not
the
point
of
the
data
definitions
to
tell
you
that
there
are
five
bits
and
the
third
bit
from
left
does
that
the
the
data
division
would
would
stop
at
the
fact
that
there
are
five
boolean
values.
E
So
this
is
an
example
of
the
more
general
observation
that
really
sdf
is
about
information
models.
So
we
don't
want
to
tie
a
harmonized
data
model
down
to
one
specific
representation,
so
whether
you
use
an
integer
that
goes
from
zero
to
sixty
five
thousand
and
thirty
two
thousand
means
zero
or
you
use
a
floating
point
value.
This
is
really
not
important
for
the
information
model
level,
but
it's
important
for
the
bindings.
E
E
On
this
slide,
you
see
the
enum
that
the
ocf
battery
material
model
uses
to
describe
the
chemistry
and
the
construction
of
of
the
battery,
and
this
is
just
a
set
of
strings.
These
are
the
strings
you
can
use
and
if
you
have
a
potato
battery
on
your
iot
device,
which
you
might
have
because
it
might
be
a
toy,
then
you
only
have
lemon
potato
there.
E
Even
though
you
do
not
employ
lemons
so
yeah,
it's
somewhat
difficult
to
define
these
enums
and
they
kind
of
get
arbitrary
after
a
while
there
might
be
spelling
errors,
so
the
pulver
macha's
chain,
the
guy,
is
actually
called
pulva
maha
and
there
should
be
an
apostrophe
here
to
say
it's
private's
chain
and
also
it's
150
years
obsolete.
So
nobody
uses
these
anymore
at
this
point
in
time,
so
it's
not
even
clear
they
that
they
should
be
in
there.
E
So
these
enums
are
difficult
and
it
would
probably
be
nice
to
be
able
to
point
to
something
that
that
has
done
the
work
of
enumerating
the
cases.
So
if
we
were
talking
about
cheese
firmness,
for
instance,
cheese
feminist
actually
has
a
definition
somewhere.
I
forget
where,
and
we
would
not
get
the
idea
of
defining
our
own
kind
of
cheese
from
this
enum,
but
we
would
like
to
point
to
that,
but
that
may
not
take
the
form
of
an
enum
of
strings
and
on
the
other
side,
on
the
data
model
side
yeah.
E
So
maybe
somebody
uses
the
number
34
for
lead
acid,
gel
batteries
and
there's
nothing
wrong
with
that.
That
would
be
the
job
of
the
binding
to
say
that
what's
lead
acid
gel
in
the
model
is
actually
34
in
the
representation
yeah.
So
in
sdf
1.0
we
only
have
the
the
possibilities
that
json
schema
or
gives
us
here,
and
that
leads
to
some
pretty
questionable
definitions.
E
How
do
we
provide
expensive
extensibility?
Do
we
use
something
like
ayana
for
registering
code
points?
Do
we
use
uri,
so
everybody
can
define
an
extension?
Do
we
do
both
and
that's
clearly
something
that
that
sdf
1.1
needs
to
address,
because
we
are
getting
more
and
more
of
these
enums
and
need
a
good
way
to
handle
them
in
an
evolvable
way.
E
So
from
from
these
basic
components,
property,
action
and
event
and
and
the
data
definitions
that
are
referenced
from
these,
we
can
build
objects
and
things
and
that's
our
composition
mechanism
at
the
moment,
and
that's
probably
also
something
that
needs
more
testing
at
this
point
in
time
we
have
a
few
sdf
things,
but
mostly
we
have
been
defining
sdf
objects
and
yeah.
So
if
you
have
an
outlet
with,
if
you
have
a
extension
strip
with
four
outlets
and
one
fuse
and
and
one
metal
oxide
oxide
varista
in
there,
how?
E
How
do
you
build
the
that
composition?
And
how
do
you
handle
the
the
repetition
that
is
in
that
composition,
with
the
four
outlets
that
are
otherwise
equal?
So
we
haven't
really
done
that
a
lot
and
when
we
did
sdf
1.0,
we
deliberately
decided
not
to
include
the
json
schema
object,
type,
which
really
leaves
a
big
hole
in
sdf10,
because
we
cannot
really
describe
the
composition
at
the
data
model
level
at
all.
E
But
the
question
we
first
have
to
answer
is:
do
we
really
want
to
handle
it
at
the
data
model
level,
or
is
there
something
in
sdf
that
describes
how
this
composition
is
done
so
simply
providing
several
properties
also
is
a
form
of
composition,
but
it's
not
always
the
right
way
to
to
handle
it.
So
some
of
the
composition
will
be
above
the
property
level.
Some
will
be
below
the
property
level
and
we
have
to
clear
that
one
out.
E
Yeah
we
specify
sdf
specifications
and
since
the
specifications
are
json
documents,
we
also
can
specify
them
in
the
data
definition
language,
and
in
this
case
we
actually
want
to
use
the
full
power
of
a
data
definition
language.
So
the
the
current
draft
has
a
cdl
based
specification,
and
that
is
also
translated
into
two
json
schema.
Org
format,
definitions,
one
that
is.
E
Very
open
so
the
framework
one,
so
all
extension
points
are
open,
but
that
also
means
that
a
typo
that
you
make
might
be
mistaken
for
for
an
extension
and
we
have
the
the
validation
schema
that
is
limited
to
to
what
is
defined
now.
So
cddl
has
recently
grown
a
feature
called
feature
and
can
can
handle
that
in
one
specification
and
on
the
in
the
json
schema
or
translation.
E
E
We
have
been
focusing
a
bit
on
getting
the
work
group
established
in
the
last
few
months,
but
also
on
defining
one
data
model
processes
that
really
aren't
the
the
domain
of
the
asdf
working
group.
That
is
focusing
on
the
sdf
specification,
but
of
course
one
dm
itself
needs
to
have
ways
of
doing
things,
in
particular
during
the
harmonization.
E
So,
given
that
the
asdf
working
group
is
almost
existing
now
we
can
put
the
focus
back
on
on
evolving
sdf,
and
so
we
should
define
objectives
for
sdf,
1.1,
look
at
solutions
and
then
start
deciding
and
all
that
shouldn't
be
done
on
on
yeah
on
a
piece
of
paper.
It
should
really
be
tested
and
one
way
to
test
this
will
be
next
month
before
ietf109,
the
the
hackathon
that
comes
with
every
recent
ietf
and
I
have
put
in
a
hackathon
project
called
asdf,
getting
ready
for
stf
1.1.
E
E
F
B
E
Yes,
so
I
I
actually
had
a
slide
at
the
buff
that
I
would
probably
like
to
show
at
this
point.
So
yang
is
supposed
to
be
the
data
model
that
people
generate
code
from
so
it's
very,
very
implementation
oriented
it's
not
designed
to
bring
data
models
from
different
organizations
together
in
some
form.
E
So
it's
a
very
specific
data
model,
a
lot
of
a
lot
of
representation
questions
are
simply
nailed
down
in
a
young
model.
You
don't
don't
get
to
write
an
information
model
in
yang,
it's
always
a
data
model.
So
it's
not
really
set
up
to
to
do
this
harmonization
kind
of
work.
This
doesn't
mean
it
could
not
be
done
with
yang,
but
I
think
it
just
wouldn't
work,
because
it
would
be
too
much
too
much
effort.
A
A
A
So,
hopefully,
everybody
is
now
totally
clear
on
what
sdf
is
today
and
with
that.
The
the
the
second
main
topic
of
today
was
to
discuss
about
this
sdf
one
one.
What
that
would
be,
what
that
will
contain,
and
to
do
that
michael
koster,
put
together
some
slides
and
where
he
well
describes
a
bit
of
the
the
outstanding
issues
elaborates
a
bit
more
on
on
what
kirsten
mentioned
as
problems
going
forward
that
we
would
try
to
address.
G
D
D
So
very
specifically,
as
carsten
said,
we've
been
focusing
more
on
the
object
definitions
which
are
the
the
reusable
of
the
most
reusable
elements.
You're
supposed
to
be
able
to
take
an
object
like
on
off
power
control
and
use
it
in
any
kind
of
device,
because
it's
very,
very
generic,
and
it's
going
up
the
stack
to
thing,
definitions
and
composing
them.
D
So
it's
enumerations
as
carson
mentioned,
there's
something
about
reusing,
sdf
property,
that
with
oma
lightweight
mtm,
it's
fairly
simple,
but
it
needs
an
extension
there's
also
composing
sdf
data,
sdf
property,
which
carson
mentioned
as
well,
and
then
there's
a
specific
issue
with
the
way
that
values
are
used.
That
seems
to
bubble
up
to
the
information
model
and
isn't
just
an
encoding
issue,
but
to
the
extent
that
we
should
figure
out
how
to
how
to
abstract
things
in
sdfs,
so
that
they
are
just
encoding
issues
whenever
possible.
D
So
these
are
the
four
things
that
that
kind
of
need
to
be
addressed
in
order
to
create
good
models
of
of
things
that
can
represent
all
all
the
different
contributors
to
1dm,
as
well
as
they're
they're
useful
for
other
kinds
of
organizations
like
digital
twins,
and
things
like
that
that
that
we've
been
looking
at
so
any
questions
here.
If
no
questions
I'll
just
jump
right
into
the
four
and
give
you
an
outline
of
each
there's
a
github
issue
for
each
of
these
for
the
detailed
discussion.
D
You
know
uris,
but
even
that
would
would
not
be
very
reusable
within
sdf,
because
it's
kind
of
too
opaque.
So
what
we're
looking
at
is
something
that
is
a
little
less
opaque.
But
let's,
let's
figure
out
the
balance
here.
So
we
want.
As
karsten
said,
we
don't
want
to
nail
it
down
whether
it's
a
string
or
an
integer
or
whatever.
We
want
that
to
be
kind
of
a
mapping
to
a
a
runtime
or
a
you
know
really
for
interact
for
interoperability
on
networks.
D
What
the
point
is,
so
the
the
proposal
is
a
new
class
in
sdf
called
sdf
enum.
That
has
it's
its
own
thing
and
allows
you
to
type
a
data
as
an
sdf
enum,
where
each
selection
is
its
own
sdf
node.
If
you
will
or
a
thing
you
can
point
out
with
a
json
pointer
and
it
it
has
a
string
and
then
other
what
we
call
qualities
in
sdf.
I've
only
shown
a
description
here,
but
you
could
add,
you
know
default
and
constant,
and
you
could
sort
of
cast
things.
D
A
lot
of
the
sdf
constructs
could
be
used
in
what
we
call
mapping
files
as
well.
So
if
you
had
json
schema
constraints,
you
wanted
to
add,
you
could
do
that
in
a
mapping
file
and
not
in
the
in
the
basic
model.
So
what
I'm
showing
here
is
just
the
minimum
of
the
basic
model,
which
would
be
each
selection
of
the
enum
has
a
semantic
anchor,
which
is
that
I've
shown
with
the
json
pointer
here
sdf
data
on
upstate
enum
off.
D
That
is
fully
descriptive.
And
if
you
know
what
sdf
data
and
enum
classes
are,
you
can
pretty
much
decompose
this
path
into
a
position
in
the
model.
And
so,
as
you
have
a
more
complex
model,
you
can
do
things
like
de-reference
the
the
links,
and
we
want
to
be
able
to
have
the
enum
elements.
Part
of
that
processing.
D
So
that's
that's
kind
of
the
idea
with
enums
and
what
or
I
think
is
going
with
that
and
basically
what
what
happens
is
and
the
reason
it
kind
of
needs
to
be
this
way.
The
use
case
justification
for
it
is
that
different
ecosystems
represent
the
actual
on
off
values
that
go
over
the
wire
as
booleans
or
ones
and
zeros
or
text
strings,
and
so
we
needed.
We
couldn't
really
even
harmonize
models.
D
If
we
had
to
pick
one
of
these
representations
up
front,
what
we
want
to
do
is
be
able
to
have
different
models
represented
with
the
same
sdf
and
then
have
bindings
and
then
eventually
we're
going
to
have
to
choose
a
single
binding
for
for
some
small,
smaller
scope
network
interoperability
like
if
I
want
to
certify
devices
and
in
zigbee
I
have
to
kind
of
choose
a
wire
format,
but
but
that's
not
really
what
we're
doing
with
sdf
we're
at
a
level
above
that.
So
that's
that's
why
this
is
needed
all
right.
D
Any
questions
comments
on
enums,
let
me
know
if
I'm
going
too
slow
or
you
just
speed
up
a
little
bit,
I'm
kind
of
conscious
of
the
time
here
so
the
other.
This
is
an
easy
one.
Really
it's
reusable
sdf
properties,
so
in
ipso
smart
objects.
They
have
these
reusable
properties,
so
I
can
say:
ipso
smart
object,
sensors
all
have
a
current
value,
and
sometimes
you
know
it's
a
different
type
or
whatever
data
type.
D
We
wanted
to
be
able
to
have
the
property
to
be
a
stand-alone
definition
and
also
to
be
reusable
within
other
property
definitions,
and
I
think
we
would
probably
already
provide
a
way
of
reusing
it
in
other
property
definitions
that
we
don't
disallow
in
the
schema.
But
we
wanted
to
add
it
to
the
to
the
spec,
and
this
is
mostly
for
to
handle
what
ipso
smart
objects
is
doing.
But
it's
also
a
design
pattern
or
useful
design
pattern.
D
Yes,
what
is
do
we
need,
I
think.
Well,
we
need
sdf
property
to
be
able
to
be
just
well.
Actually
that
may
not
be
an
sdf.
This
may
be
more
of
a
one
data
model
constraint
with
the
way
we
organize
our
database.
There
may
not
be
any
issue,
but
an
sdf
file
should
be
able
to
consist
of
a
valid
sdf
file
should
be
able
to
consist
of
only
sdf
property
definition
and
shouldn't
be
required
to
contain
an
object,
and
I'm
not
sure
what
the
schema
looks
like.
E
Yeah,
I
think
we
need
to
to
actually
generate
examples
that
use
this
and
make
sure
that
our
various
tools
can
actually
act
on
specifications
that
have
this.
So
I
think
that
there's
work
to
be
done,
but
it
may
not
be
specification
work
or
it
may
only
be
specification
work
after
we
learn
about
what
doesn't
work
so
well
with
what
we
have
defined
now.
D
That's
good,
yeah,
okay,
okay,
so
moving
on
composite
property
is
the
thing
that's
probably
the
most
interesting,
because
when
we
look
at
the
way
a
lot
of
well,
there
are
a
few
different
use
cases.
One
obvious
one
is
the
multiple
sensors
that
are
offered
by
bluetooth,
low
energy
and
other
another
specifications
where
data
from
multiple
sensing
elements
can
be
combined
and
returned
together
in
a
in
a
you
know,
complex
format.
D
So
generally,
I
think,
as
kirsten
mentioned
earlier.
What
we'd
like
to
do
here
is
stick
to
the
semantics
and
not
not
be
too
constraining
on
formats
and
representations,
and
that
didn't
even
include
schemas,
where
it
might
be
a
json
schema
or
an
xml
schema
where
tag
names
are
part
of
the
schema
that
aren't
really
part
of
the
data
model.
The
data
model
semantics
anyway,
where
tag
tag
names,
are
something
that
you've
sort
of
put
on
over
the
wire
and
have
the
endpoints
be
able
to
recognize.
D
But
you
know
to
build
them
into
the
data
model,
is
is
kind
of
getting
into
what
we
were
calling
mapping
and
protocol
binding.
So
what
we'd
like
to
do
is
be
able
to
compose
properties,
I
think,
without
more
freely,
without
constraining
the
structure
of
what
the
composite
property
looks
like
when
it
goes
over
the
wire
or
over
the
air.
So
it's
it's
kind
of
like
what
we
already
do
for
actions
and
events
where
we
say
an
action
might
have
multiple
input
properties
where
you
could
send
it.
D
But
what
what
what
happens
is
a
lot
of
the
data
models
and
iot
devices
and
interactions
out
there
are
sort
of
complex,
but
probably
the
easiest
one
to
think
of
as
rgb
as
those
person
mentioned
earlier.
The
rgb
data
is
one
that
we
use,
but
it
goes
both
ways.
Rgb
is
sort
of
like
where
you'd
like
to
treat
it
as
a
property,
but
it
has
internal
elements.
D
So
in
both
of
those
cases,
though,
the
requirement
is
similar
in
that
you,
you
want
a
sort
of
it's
sort
of
starting
to
look
like
the
enum.
Only
it's
for
multiple
elements
where
you
want
a
semantic
anchor
for
each
element
and
have
be
able
to
have
a
description
and
be
able
to
have
it
to
be
its
own
extension
point
for
adding
more
qualities
and
constraints
and
schemas,
and
things
like
that
in
the
mapping.
D
D
But
the
data
scheme
is
really
should
be
part
of
the
the
protocol
bindings
and
the
mapping
files
and
sdf
is
not.
It
doesn't
really
say
that
you
can't
make
a
data
scheme
a
part
of
your
sdf
model.
In
fact,
there
may
be
a
lot
of
cases
where
we
do
want
to
do
that,
but
it
shouldn't
be
required
either.
It
shouldn't
be
just
assumed
that
there's
a
data
schema
where
you
have
data
elements.
It
should
be
that
the
the
data
element
in
sdf
should
base
in
the
in
the
core
file.
C
D
Yeah
the
idea
is,
but
this
is
just
an
abstract
example:
it
isn't
even
rgb
or
anything
but
a
simple
property
just
just
to
show
kind
of
what
we're
talking
about.
Okay.
So
the
simple
property
is
just
like
I
say:
here's
a
property,
it's
type
string,
here's
a
compound
property
and
it
has
a
data
declaration,
that's
similar
to
other
sdf
data
declarations
that
we
use
in
actions
and
events,
and
it
says
that
the
interaction
with
this
property,
this
compound
property,
has
separate
elements
that
we
can.
D
You
know
compose
differently,
and
some
of
them
are
required
and
some
of
them
aren't
and
there
may
be
different
types.
I
might
be
sending
a
number
and
a
string
together-
and
I
want
to
treat
this-
I
I
don't
want
to
have
to
wrap
this
up
in
actions
and
events
in
order
to
send
the
the
compound
data.
I
want
to
be
able
to
just
do
pub,
sub
or
read,
write
on
it
and
that's
why
it
needs
to
be
defined
as
a
kind
of
compound
data
like
this.
D
D
Obviously
the
the
other
thing
is
unsaid
is
you
could
have
multiple
layers
of
this
and
you
could
have
obviously
some
some
folks
are
saying.
Well,
maybe
in
sdf
we
should
have
only
one
layer.
We
should
say
you
could.
You
could
have
collections
of
simple
properties,
but
not
collections
of
collections,
and
so
that's
a
further
discussion
that
we
need
to
to
have.
But
to
me
I
have
seen
cases
where
there
are
already
things
that
we
would
want
to
represent
with
more
than
one
layer,
but
we'd
have
to
have
specific
examples.
D
You
know
opposition
to
just
having
it
be
unlimited,
okay,
the
last
one,
is
just
a
pattern
that
comes
up
that
is
interesting
to
think
about
how
to
model
it,
and
so
it's
basically
they
it
seems
like
they
do
it
to
save
space
and
all
of
that
and
really
like
to
use
a
byte
for
multiple
things.
But
it's
not
like
a
bitmap
where
you
use
a
byte
to
have
multiple
separate
elements.
We
we
kind
of
have
a
good
pattern
for
that.
D
D
If
I,
if
I
have
a
power
failure
and
the
I
want
my
lights
to
come
on,
you
know
if
it's,
if
it's
a
legitimate
emergency,
so
there's
some
compromises
there,
and
these
are
this,
but
basically
it
also
has
a
value
that
you
could
set.
So
oh
when
when,
when
the
light
starts
up,
set
it
at
50,
so
they've
encoded
all
this
in
a
single
parameter,
which
makes
sense
a
single
property
in
sdf.
D
D
D
D
There
are
others
too.
There
are
other
folks
that
have
some
other
things
that
they'd
like
to
see
in
1.1.
So
this
is
just
from
my
perspective,
based
on
the
things
that
are
basically
blocking
issues
for
being
able
to
use
sdf
in
these
other
ecosystems
like
zigbee
and
bluetooth,
where
maybe
not
completely
blocking,
but
what
it
would
take
to
make
them
really
want
to
use
sdf
and
happy
with
it,
and
would
you
know,
create
more
ease
of
use
for
for
them
and
and
really
in
a
lot
of
other
cases.
D
C
So,
michael,
can
you
so
this
is
this
this
business,
where,
of
course,
we
have
a
different
different
different
values
or
different,
I'm
going
to
say
ages.
Maybe
is
the
my
physics
background
term
right
to
to
these
things
for
these?
For
this,
these
things
like
this
is
that
the
50
value
is
is,
is
not
a
value
in
the
in
the
normal
set
of
brightnesses
or
the
last
value
is
not
enough.
Is
outside
of
that
completely
so.
C
That
that
that
there
are
different
kinds
of
things,
so
what
about
the
issue
of
so
so
we
would.
We
can
adapt
sdf
to
deal
with
these
things,
but
what
about
the
issue
of
okay?
So
you
want
to
be
able
to
round
trip
this,
this
data
model
into
which
came
from
zigbee.
Now
you
want
to
be
able
to
round
trip
it
into.
C
D
Within
reason,
right
I
mean
there
may
maybe
this
is
an
example
of
the
first
time
you
look
at
this.
You
say:
oh
that's,
ugly,
I
would
never
that's
that's
that's
bad
design,
but
then
you
think
about
it
and
you
think
well,
actually,
it
kind
of
makes
sense.
The
way
it's
encoded
is
efficient.
You
know,
but
actually
as
a
design
pattern.
I
wouldn't
want
to
prohibit
it
right,
but
there
might
be
others
that
you
could
say.
Well,
that's
that's
really
something
that
we
have
to
model
around.
D
C
I'm
trying
to
say
yeah,
that's
what
I'm
trying
to
say
if
you
go
from
one
ecosystem
into
sdf
into
another
ecosystem,
and
then
you
expect
to
go
back
again
right,
the
the
the
you
know,
the
ecosystem
that
doesn't
have
way
of
of
representing
something
we're
going
to
lose
that
data.
You
can't
trans,
you
can't
you
can't
translate
into
that
and
without
losing
the
data.
If
I'm
not
mistaken,
right.
D
D
Well,
if
you
wanted
to
have
yeah,
I
mean
so,
the
logic
of
devices
might
be
extended
to
to
add
that
and
then
you
know
when
you
did,
that
you
would
have
to
change
the
encoding
in
this
case,
because
I
you
know,
I'm
specifying
the
encoding
here,
but
but
basically
a
more
abstract
pattern
would
just
say,
type
number
sdf.
In
fact,
I
think
the
example
that's
in
the
github
issue
doesn't
have
the
the
value
constraint,
it
just
says
type
number
and
it
says
sdfv
num,
minimum
device
set
to
previous
value.
D
D
D
Well,
you
know
here
is
real
where,
where
it
comes
down
to
in
the
run
time,
you
could
have
two
different
run
times.
You
could
have
a
run
time
where
it's
important,
that
everyone
agree
on
the
same
set
of
mappings
and
constraints
so
that
you
can
do
code
generation
on
constrained
devices
and
have
them
all
plug
and
play
on
those
on
the
network.
But
you
can
also
say
well.
D
I
want
to
do
my
runtime
such
that
it's
adaptable,
and
I
want
to
be
able
to
take
my
mapping
files
and
generate
a
mapping
bridge
that
has
two
different
endpoints.
It
has
one
endpoint
that
that
takes
one
set
of
constraints
and
it
has
another
endpoint
that
takes
a
different
set
of
constraints
and
it
adapts
one
ecosystem
to
another,
and
it
does
that
dynamically
and
we're
building.
D
You
know
examples
of
both
of
those
in
terms
of
demos
and
what
have
you,
but
in
any
case,
it
still
seems
to
be
that
the
more
abstract
the
base
model
is
with
with
the
constraints
and
schemas
and
formats
as
part
of
mappings
that
that's
much
better,
and
I
think
that
the
the
meta
thing
here
and
I
don't
have
a
slide
on
it.
But
I
I'm
looking
at
how
do
you
then
standardize
the
mapping
so
that
I
can?
I
can
really
trade
mapping
files
around
even
though
they're
this
is
where
the
extension
points
are.
D
So
we're
not
really
looking
at
standardizing
all
the
vocabulary.
But
how
do
we?
How
do
we
do
this?
You
know
if
I
apply
a
set
of
id
numbers
that
were
zigbee
and
a
different
set
of
id
numbers
for
bluetooth,
but
it's
the
same
models
shouldn't
the
mapping
files
be
at
least
sort
of
similar
and
be
used,
similar,
syntax
and
processing.
D
D
C
F
F
D
D
You
know
spot
regulation
that
they
did
to
to
limit
interaction
with
the
huawei.
That's
since
been
lifted
and
we
can
go
back
and
we
can.
We
can
now
work
with
well
two
things:
all
of
our
work
is
in
the
open,
so
we
don't
really
function
as
a
liaison
organization
anymore,
strictly
under
undercover,
so
we
can
work
with
any
other
organization
now.
D
So
when
we
come
back,
we
would
definitely
welcome
one
mtm
to
be
back
in
our
group
discussing
and
harmonizing
with
sdt
it's
unfortunate
we
weren't
able
to
have
them
as
part
of
the
process
all
along,
but
I
think
we
got
enough
interaction
through
alan's
participation
that
we're
able
to
you
know
more
or
less
more
or
less
stay
keep
up,
but
but
yeah.
I
think
it's
it's!
It's
there's
an
opportunity
now
going
forward
to
to
work
more
closely
with
one
mtm
and
we'd
like
to
do
that.
F
D
D
We
also
have
similar
outreach
with
the
digital
twin,
there's
a
group
in
microsoft.
It
isn't
really
an
open
standard,
but
a
group
in
microsoft,
that's
well.
They
do
publish
everything
as
open
source,
that's
working
on
a
digital
twin
language
that
has
a
lot
of
the
same
parallel
constructions
that
we
want
to
harmonize
at
the
language
level
as
well.
So
it's
beyond
just
the
models,
but
it's
more
also
harmonizing
at
the
language
level.
Yeah
thanks
for
bringing
that
up.
A
A
A
D
H
D
Oh,
I
can't
it
says:
I'm
sharing
my
web
browser,
but
I'm
not
seeing
oh
there.
It
is.
Oh,
that's
weird!
I
get
another
paint,
okay
cool!
So
that's
not
yet
there.
It
is
okay.
So
currently,
in
the
sdf
repo
on
one
data
model
github,
we
have
four
open
issues
that
roughly
correspond
to
the
four
categories
and
their
enum
type,
reusable
property
types.
First,
this
is
a
good
size
for
everyone.
Everyone
can
see.
Fine,
no
one's
complaining.
D
C
C
D
C
D
I've
been
on
the
other
end
of
that
now
now
that
you
mention
it
okay,
so
here
we
are
anyway,
and
we
have
four
open
issues
and
everyone
will
have
to
use
their
own
magnifiers.
I
guess
so.
I
don't
know
what
there's
some
discussion
on
each
one.
Do
you
want
to
like
sort
of
like
just
trip
through
them?
Briefly
start.
C
D
Okay,
so
we've
been
talking
about
enum
for
a
while
and
and
I'll
just
sort
of
lay
out
the
discussion
here,
as
I
see
it,
and
water
water
has
an
ad
because
alan's
not
on,
but
water
can
chime
in
so
currently,
as
carson
said,
sds
or
enum
is
currently
just
a
json
schema.org
feature
that
allows
you
to
specify
an
array
of
values
and
that's
all
all
it
is.
They
don't
even
have
to
be
the
same
value
type.
D
We
might
want
to
expand
it
out
more
and
have
some
etf
or
sorry
ayanna
registration
in
the
namespace
and
things
like
that.
So
here's
here's
the
discussion.
Basically,
you
know
alan
is
asking
for
a
mapping.
So
it's
it's
mainly
around
the
abstraction
so
and-
and
wilder's
point
is.
I
think
what
we
all
agree
on
is
that
we
really
need
to
represent
semantic
values
and
shouldn't
have
the
mapping
in
the
enum,
but
where
we,
when
we
haven't
really
agreed.
D
D
H
D
Okay,
so
it
sounds
like
where
we
are
now
with
five
minutes
left
in
the
in
the
agenda
today
is
that
we
need
to
look
at
so.
I
have
provided
an
example
here
of
a
thing
that
uses
sdf
enum,
so
it
sounds
like
you're
proposing
a
pattern
that
uses
jsonschema.org
enum
with
some
additional
annotation,
and
I
can
think
of
a
few
different
ways
that
might
work
so
like.
I
think
we
need
an
example
of
that.
H
Well,
frankly,
the
only
difference
that
I
can
see
is
that
the
sdf
enum
value
on,
I
think
I
see
that
correctly
on
that
has
been
used
as
a
standard
value
somewhere
as
a
normal,
json
enum,
and
I
think
that
would
work.
And
then
you
can
even
say
it
has
the
scope
of
the
same
document.
But
what
would
you
do
if
there
are
two
enum
values
called
all
in
the
same
file?
Are
they
the
same
or
are
they
different?
H
But
I
frankly
I
think
if
we
define
all
that
it
always
will
be
the
same.
So
yes,
I
think
there
would
be
additional
things
that
we
can
do
that
we
can
list
those
enum
values
out,
maybe
in
iana
or
whatever,
but
start
standardizing
them
in
a
larger
scope
than
just
the
scope
of
the
model
itself,
and
I
think
that's
the
the
the
real
problem
with
enum
values
do:
are
they
scoped
to
the
model
or
is
that
scope
to
the
domain
or
even
larger
than
a
domain.
D
So
the
but
that's
okay,
that's
that's
really
part
of
the
discussion.
Also.
So,
if
there's
scope
to
the
model,
so
we
always
provide
a
way,
an
sdf
to
have
a
standalone
data
definition.
So
certainly
they
could
be
scoped
within,
say
one
dm
by
having
an
sdf
file.
That
is
for
the
domain,
if
you
will
or
for
for
one
dm.
Even
so
you
could
have
a
standalone
sdf
data
definition
with
the
enum
and
and-
and
I
think
what
you
point
out.
C
Too
far
into
the
detail,
because,
as
you
said,
we
were
at
the
end
of
the
thing-
this
is
actually
a
really
good
thing
to
to
wet
our
appetite
for
the
next
meeting.
Exactly
so
is
is
if
we
could
describe
the
question
well
enough,
such
that
we
can
put
it
in
it
could
literally,
it
can
be
literally
the
first
agenda
item
next
time,
and
and
is
there
a
second
item?
Let
you
an
issue
that
you'd
like
to
bring
up
right
now.
H
Yeah,
the
the
the
second
problem
that
I
was
hinting
at,
and
it
was
already
mentioned
by
michael
as
well
in
at
this
moment
we
model
things
very,
very,
very
flat,
which
is
not
a
bad
thing.
But
if
you
want
to
do
more
complex
things
with
media,
then
it
would
be
good
to
have
more
compound
statements
like
that.
You
have
data
within
json
data,
basically
json
support
of
json
nested
json
objects
to
describe
how
that
is
on
the
wire.
D
And
I
think
this
is
another
great
example
of
where,
where
I'm
I'm
proposing
some
kind
of
abstract
way
of
doing
that,
that
doesn't
actually
use
the
jsonschema.org,
and
I
think
wilder
is
looking
for
some
solution.
That's
closer
to
just
looking
at
like
a
json
object,
but
you
know
again.
I
think
we
need
to
look
at
some
concrete
examples,
because
sometimes
it
makes
sense
to
have
you
know
anything.
Carson
brings
up.
How
do
you,
how
does
the
naming
work,
and
so
maybe
as
another
for
another
second
issue?
H
D
I
I'm
not
sure
it's
sufficient
either
because
in
the
examples
I've
looked
at
it's
important
to
say
that
you
in
at
the
even
at
the
abstract
level,
it's
important
to
say
that
you're,
providing
an
interaction
that
gives
you
this
data
as
part
of
the
interaction
that's
more
than
one
data
element
and
even
having
to
do
that.
I
think,
is
where
you
start
introducing
the
grouping
issue
and
whether
whether
you
want
to
add
structure
or
keep
it
structure
neutral.
Those
are
some
of
the
fine
points,
but
I
think
once
you've
gone
down
that
path.
D
C
C
Exactly
it
just
startled
me
for
a
moment
that
that
didn't
work
so
so
that's
what
I
would
propose
as
a
structure
is
that
we
we
get
into
some
some
issues.
We
we
want
to
probably
give
a
high-level
notion
of
what
the
conflict
is
or
the
the
the
there
and
you
know
if
they
get
resolved
in
the
the
github.
That's
great.
If
they
don't,
then
you
know
that's
the
topic
of
discussion
now.
A
C
C
C
D
B
D
C
C
H
D
You
know
if
we
think
that
that's
a
problem
we
can
shift
it
later
and
it
also
lines
up
with
the
1dm
slot,
with
a
lot
of
the
people
already
doing
this,
but
we're
thinking
for
the
model
convergence
stuff
we're
going
to
need
a
new
slot,
that's
more
friendly
to
other
folks
anyway.
So
this
is.
This
is
turns
out
to
be
a
slot
that
people
already
have
on
their
calendars.
D
C
So
nicholas-
and
I
are
going
to
organize
another
meeting,
probably
for
two
weeks
from
today,
and
then
we
have
a
meeting
scheduled
for
ietf
109
and
the
the
process
of
running
things
through
with
the
on
github.
We
may
want
to
transition
this
this
repo
from
one
data
model
to
asdf,
but
I
think
that's
something
we
can
discuss
offline
yeah.
We
were.
We
were
planning.