►
From YouTube: ASDF WG Interim Meeting, 2020-12-14
Description
ASDF WG Interim Meeting, 2020-12-14
A
A
B
C
B
B
Here
is
the
agenda
for
today.
First
of
all
introduction
some
meeting
logistics
and
agenda
bashing.
We
will
give
you
a
brief
update
of
where
we
are
as
the
working
group
as
a
working
group,
and
then
we
will
have
two
main
topics
today.
One
is
on
sdf
sdi,
one
one
wrapping
that
up
trying
to
get
the
finalized
specification
and
the
second
major
topic
is
w3c
weber
things,
and
I
was
hoping
that
sebastian
would
be
joining
us
here.
B
He
acknowledged
before
that.
He
could
so,
let's,
let's
just
hope,
to
eat
sleep
and
that's
why
also,
we
have
a
group
of
people
from
the
w3c
working
group
weather
things
to
talk
with
her
and
and
they
have
a
so
sebastian
will
show
a
demo,
and
we
will
also
talk
a
bit
about
how
we
can
collaborate,
collaborate
going
forward
so
with
that.
Is
there
any
other
business
that
people
want
to
raise
here
in
the
call.
D
Yeah
so,
as
I
said
hi,
this
is
gaz
from
w3c
unless
yesterday,
on
the
merry
christmas,
the
diversity
side
yeah
at
some
point-
maybe
not
today.
So
we
would
like
to
talk
about
the
concrete
process
and
content
for
the
readon
procedure,
but
let's
see
the
sebastian's
description
and
the
demonstration
first.
B
A
B
Yeah,
thank
you
that
so
moving
along
yeah.
We
care
about
this
already,
there's
the
app
so
now
on
slide
six,
the
status
update
for
the
working
group.
We
were
charted
in
october,
as
I
hope
all
you
know
it's
myself
nicholas
and
michael
richardson,
who
are
charities,
group
and
progress.
So
far
we
have
had
three
meetings:
one
unofficial
hallway
meeting
where
there
is
a
link
there
to
tutorial,
and
that
link
is
also
in
the
in
the
agenda
for
this
meeting.
B
We
had
both
a
full
week,
hackathon
very
intense,
with
a
plus
actual
meeting
at
itf
109
to
further
work
on,
and
we
are
getting
close
to
completing
that.
So
the
key-
the
main
purpose
of
this
meeting
today
here,
is
to
actually
try
to
wrap
up
one
one
and
see
where
we
are
and
identify
the
missing
pieces.
If
there
are
things
we
need
to
have
some
kind
of
more.
B
B
The
reason
why
this
time
here
is
was
chosen
is
because
it's
overlaps
with
the
time
that
the
one
data
model
usually
meets,
and
the
final
point
here,
which
is
a
bit
relevant
today,
is
that
one
of
the
ways
of
working
here
we
have
in
the
asdf
group
is
that
we
tried
to
identify
reasonably
stable
drafts
as
implementation
drafts,
and
so
this,
what
we're
aiming
for
today
with
one
one,
is
one
of
those
implementation
drafts
that
we
can.
That
will
hopefully
be
reasonably
stable,
even
if
you're
not
at
final
rfc
stage.
B
Moving
along
this
is,
I
will
just
spend
one
minute
on
this
or
30
seconds
on
this.
I
guess
everybody
has
seen
it.
This
is
about
the
one
data
model
where
a
lot
of
the
parts
of
the
asdf
and
sdf
comes
from.
The
problem
was
that
there
were
several
standardized
iot
data
models
and
that
led
to
high
cost,
obviously,
integration.
B
Various
solutions
were
tried
out
to
to
sort
of
offset
this
problem.
It
ended
up
that
a
tool
that
could
translate
between
the
different
formats,
such
as
neutral,
had
a
lot
of
positive
aspects
to
it.
That
was
what
was
it?
What
what
was
developed
this
led
to
the
definition
of
the
semantic
definition
format,
which
is
now
in
itf
and
the
big
topic
of
the
sdf
working
group.
It
also
led
to
the
work
that
remains
in
the
one
data
mail
group
around
tool
chains
and
also
on
adopting
actual
specified
device
models
for
for
wider
reuse.
F
Of
sdf-1,
I
would
just
add
to
what
you
said:
there
was
quite
a
bit
of
external
input
into
one
data
model
last
year
and
we
had
folks
from
oma
and
lightweight
mtm
and
ocf
and
zigbee
organization
and
bluetooth,
sig,
and
a
couple
of
other
vertical
integrator
type
solutions
like
sunspec
for
off-grid,
solar
energy
systems
and
this
sort
of
thing.
So
the
requirements
we
collected
were
really
pretty
broad.
F
But
what
what
sort
of
is
happening
is
that
we
need
to
finish
the
language
before
we
can
get
the
we
need
to
finish
sdf
and
get
it
to
a
stable
point
before
we
can
ask
these
folks
to
come
back
and
start
contributing
models
from
these
this
broader
organization,
so
in
the
in
the
broader
framing
of
things,
what
we're?
What
we're
trying
to
do
is
get
an
initial
version
of
this
that
nailed
down
that's
stable,
that
people
can
say.
Oh
look,
it's
an
ietf
spec,
it's
stable!
It's
an
rfc!
F
F
B
G
G
So
that
was
the
model
that
we
had
in
mind
when
we
said
we
want
to
have
stable
implementation
drafts
and
sdf
1.1
actually
is
intended
as
as
one
such
stable
implementation
draft.
So
this
is
where
we
want
to
to
go
to
and
we
we
knew
that
1.0
had
a
few
construction
sites
and
the
idea
is
to
to
have
something
with
1.1
that
isn't
cast
in
concrete,
but
that
there
has
to
be
a
really
good
reason
to
to
change
it
yeah.
G
So
we
we
had
six
github
issues.
I
forget
what
happened
to
github
issue
number
one.
I
can't
find
that.
So
we
have
two
two
to
seven
and
issue.
Number
three
was
really
about
something
that
that
was
in
sdf
1.0,
but
we
hadn't
really
tested
yet
and
that
tested
testing
has
been
done
and
we
now
know
how
to
do
reuse
and
reference
naming,
and
we
also
clarified
the
naming
convention,
which
is
a
little
bit
different
from
how
things
are
usually
done
in
the
the
rdf
world.
G
So
that's
maybe
something
that
that
people
should
be
looking
at
again
and
see
whether
they
they
like
that.
I
mean
it's
a
convention,
so
it's
easier
to
change
a
convention
than
than
changing
a
hard
part
of
the
spec.
But
still
we
shouldn't
have
to
change
that
convention.
We
should
agree
on
it.
So
that's
number
three
number
four
was
about
the
introduction
of
composite
types
and
we
essentially
agreed
to
reuse
the
the
related
feature
of
json
schema
arc.
G
So
what
what
I
didn't
make
a
slide
of
site
for
is
sdf
is
a
data
and
intellectual
modeling
language
and
because
it's
not
very
bright
to
completely
reinvent
a
new
data.
Modeling
language
we
decided
to
to
reuse
as
much
as
possible
from
the
json
schema
org
specification,
which,
unfortunately,
is
not
completed,
but
there
are
some
parts
that
most
people
would
agree
are
unlikely
to
change
at
this
point,
so
we
can
easily
import
them.
G
G
These
are
the
the
interaction
references
that
allow
you
to
read
and
write
values,
so
we
are
sometimes
getting
a
little
bit
confused
and
we
are
calling
those
members
in
the
specification
qualities
now,
of
course,
there
are
also
members
in
the
data
types
that
we
are
talking
about,
so
it
can
get
a
bit
confusing
here
anyway.
That's
what
you
get
for
for
from
importing
something
else,
but
reinventing
things.
This
wouldn't
have
been
very
bright
either.
G
So
these
issues,
number
three
and
number
four-
have
been
closed
by
their
respective
originator
and
there
is
text
in
the
current
draft
and
yeah.
One
of
the
questions
that
we
will
have
to
answer
in
in
the
consensus
call
as
michael
richardson
pointed
out,
the
last
call
should
be
called.
One
of
the
questions
will
be.
Are
number
three
and
number
four
really
properly
addressed
now.
G
A
G
F
G
F
F
A
A
A
The
actions
work
I
mean
a
bit
differently
in
in
life
within
them
and
properties.
Luckily,
because
they're
they're
doesn't
detail
too
much,
I
mean
we
can
design
something
that
is
consistent.
I
I
think,
but
then,
when
it
comes
to
the
properties,
I
think,
as
long
as
we
have
enough
hints
on
the
sdf
side,
that
we
know
what
maps
where
and
how,
I
think
we're
good,
but
I
think
it's
yeah
that's
something
to
do
the
final
pressure
test.
Well,.
F
Let's
work
through
some
examples,
because
I
have
some
constructed
examples:
that
for
new
types
of
things
that
I'm
trying
to
do
that
that
I
have
some
some
ideas
or
actually
some
examples
that
I
worked
through
about
how
we
could
do
that,
and
we
can
see
if
these
generally
map
onto
some
some
of
the
other
things
that
might
need
to
be
done.
You
know,
for
example,
do
you
really
need
to
have
light
bulbs
with
all
of
the
different
color
control
affordances?
As
part
of
you
know,
the
next
thing
also
is
sort
of.
F
A
Questions
yeah,
I
think
that's
kind
of
three
levels
of
questions
here.
One
is
that
looking
like?
How
would
you
if
you
start
from
one
line
within
the
model?
How
would
you
do
it
that
it
maps
nicely
everywhere?
The
second
part
would
be
what
kind
of
style
we
choose
for
the
consolidated
models
that
they
are
easily
mappable
to
live
within
them
and
the
third
one
the
hardest.
One
is
probably
ecosystem,
specific
models
and
some
of
those
could
even
be
a
non-goal.
A
We
don't
even
try
to
map
all
the
ecosystem,
specific
tweaks
to
do
live
within
them,
but
at
least
the
consolidated
models
we
should
be
able
to
map,
so
that's
it
might
be.
In
that
phase,
we
have
to
look
in
more
detail
what
exact
structures
can
we
use
for
those
or
if
we
need
to
somehow
restrict
the
generic
language
when
it
comes
to
the
consolidated
models.
F
A
F
As
you
say,
if
we
can
come
up
with
the
hints
and
the
patterns
in
sdfs
that
make
it
easy,
you
know
the
conventions,
even
maybe
around
sdf,
that
say
here's
when
you
make
an
action
you
have
to.
You
should
make
it
this
way
or
have
to
make
it
this
way
so
that
it
can
be
converted
to
these
other
things
that
need
more
more
heavy
heavy-duty
mapping,
as
opposed
to
just
being
able
to
sort
of
translate
things
easily.
F
G
That
points
to
something
that
we
may
want
to
start
as
a
sub-activity
here,
getting
some
some
documents,
not
in
the
sense
of
an
internet
draft
or
something
not
just
a
wiki
page
or
something
that
explain
the
conventions
that
the
various
ecosystems
have
been
using
and
are
using
for
for
doing
the
conversion,
because
that
that
would
be
extremely
useful
for
new
ecosystems
coming
in
seeing.
How
did
the
other
ecosystems
solve
the
the
problems
that
they
still
have
to
solve?.
E
B
B
B
A
Is
proposing
kind
of
the
implementation
draft
approach
that,
yes,
here's
what
makes
sense,
let's
implement
it,
let's
press
and
test
it
and
see
if
we
find
some
issues,
I'm
thinking,
maybe
the
only
generic
concern
I
have
here
is
that
if
I
would
have
to
choose
a
method,
I
would
rather
choose
the
one
that
has
less
power.
I
know
we
can.
We
can
increase
for
in
the
further
versions
increase
the
how
powerful
the
mechanism
is,
but
it's
of
course
hard
to
take
the
power
away.
F
B
G
G
So
if,
if
you
have
a
rgb
value
type,
you
may
want
to
call
a
field
red
or
green
or
blue,
so
setting
labels
is
one
obvious
thing
that
you
may
want
to
do,
but
you
already
can
do
that
by
using
the
named
data
qualities
mechanism.
So
it's
not
strictly
necessary
to
do
that,
but
when
it
comes
to
default
values,
there
is
currently
no
way
for
doing
this,
and
maybe
it
would
be
nice
to
look
at
other
examples
and
see
whether
we
have
to
say
anything
more
and
when
I
started
looking
at.
G
F
F
You
couldn't
override
things
and
remove
things
because
you're
not
you're,
not
really
having
that
expectation,
and
there
are
some
corner
cases
where,
if
you
didn't,
if
you
couldn't
do
that,
you'd
just
make
another
definition
locally
and-
and
there
were
workarounds
but
going
back
to
the
use
cases.
There
are
there's
a
few
more
than
just
labeling
default.
Values
is
a
big
one,
also
a
minimum
and
maximum,
and
also
even
if
you
want
to
explain
something
different
with
description
and
label.
F
So
if
you
could
put
a
default
volume
in
the
model
and
use
a
constant
in
your
sdf
breath
of
it
to
override
it,
that
would
be
an
example
of
being
able
to
change
something
in
the
model
without
it
being
just
being
a
higher
level
of
restriction.
Basically,
so
you
know
that's
that's
kind
of
a
long
way
of
saying
I.
I
think
that
that
this
is
an
important
feature
to
have
in
1.1,
and
I
think
that
defining
it
in
a
way
that
maybe
only
allows
a
higher
level
or
a
backward
compatible.
E
E
But
well,
if
you
just
look
at
json
that
there
is
a
min
and
max
in
the
schema
which
are
the
absolute
min
and
max
that
can
occur.
So
that
is
the
model
the
mean
of
max
of
the
model.
That's
not
the
mean
and
the
max
of
the
instance
that
might
be
on
the
wire.
So
there
there
are
quite
a
lot
of
those
nitty-gritty
details
which
makes
it
a
little
bit
cumbersome
so
you're.
F
Sounds
like
we
generally
agree
and,
and
what
I've
noticed
is
that
we
have
this
concept
in
sdf
of
declaration
and
definition.
Where
definition
is
the
model
part
and
declaration
is
sort
of
where
you
use
it,
and
minimum
and
maximum
are
a
good
example
where
you
might
want
to
set
say
that
a
thing
is
limited
to
what
will
fit
in
an
8-bit
integer,
so
0-255
unsigned,
for
example,
but
then
in
your
model
you
might
want
to
further
restrict
it
and,
in
my
experience,
creating
those
as
properties
that,
as
you
say,
carry
can
be
carried
on.
F
The
wire
and
infected
by
applications
is,
in
general,
a
better,
a
better
way
to
do
things,
but
that's
not
always
the
way
people
will
want
to
do
it.
So
we
do
have
a
little
question
of
usage,
but
I
think
min
and
max
are
the
one
qualities
that
I
would
say
are
good
candidates
for
an
override
that
you
might
want
to
set
in
them
in
the
declaration
definition
and
then
override
in
the
declaration,
an
application
range.
But
but
then
again
you
can
also
do
that
by
by
having
additional
properties
that
set
those.
G
F
F
and
I
might
want
to
use
json
schema,
org,
minimum
or
sorry
maximum
in
both
of
those
cases,
both
in
the
definition
where
I
say
it's
zero
to
255
and
then
in
the
declaration
where
I
say
this,
this
one
use
of
this
rpm
for
the
wobble
for
the
wobble
motor
is
0
to
50
and
it's
slower
than
it
doesn't
go
as
fast
as
the
rotating
motor.
But
I
want
to
use
the
same
rpm.
F
G
Okay,
so
my
summary
would
be
that
we
agree
that
there
should
be
a
convention
that
overriding
is
only
used
for
subtyping,
and
so
so
the
the
newly
created
type
should
be
a
subset
off
of
the
existing
one.
And
of
course
there
are
things
like
description
where
you
cannot
entirely
apply
this
in
a
formal
way.
But
I
think
that
that's
okay,
because
that's
for
humans
anyway,
who
can
fill
in
the
blanks,
but
given
that
we
don't
need
to
set
qualities
to
another.
B
B
G
So
when
we
describe
data
shapes,
they
often
specify
a
selection
of
possible
values,
and
we
can
do
this
for
single
values.
Of
course,
we
can
do
this
for
ranges,
and
then
we
have
more
complicated
constructs
like
arrays
and
so
on,
which
then
have
number
of
items
and
so
on,
but
it's
not
currently
possible
to
construct
a
type
from
more
diverse
selections,
and
if
we
want
to
model
this
like
jason's
gamerock
does
there
are
two
constructs
there
that
are
popular.
G
So
what
we
typically
use
these
for
is
a
number
of
named
alternatives,
so,
for
instance,
we
might
have
something
that
that
has
five
values
in
the
enum
and
that's
talking
about
animals
of
course,
and
this
particular
idiom
can
talk
about
aunts,
bees,
cats,
dogs
and
elks,
and
these
are
the
the
five
cases
and
the
the
problem
we
really
have
with.
This
is
that
there
are
nice
strings
that
can
be
sent
over
the
wire,
but
nobody
really
knows
what
these
strings
mean.
G
G
G
So
it's
a
little
bit
more
of
a
bigger
gun
that
is
being
used
to
address
this,
but
it
sometimes
is
necessary,
and
also
if
you
want
to
combine
ranges,
then
any
of
is
the
the
only
tool
you
have.
So
if
you
have
something
that
that
can
go
from
0
to
10
and
and
from
100
to
110,
that's
the
the
only
way
to
express
this.
G
G
Right
and-
and
we
haven't
done
a
lot
of
work
in
integrated
integrating
zigbee
models
yet
so
I
would
expect
that
that
there
are
more
of
these
in
there
and
yeah.
So
we
have
our
catch-22
problem
here
again:
that
we
want
to
give
zigbee
a
stable
specification,
so
they
can
can
put
more
models
into
the
playground,
but
we
also
want
to
use
what
they
learned
from
this
activity
to
define
a
stable
specification.
So
there
is
no
no
way
to
solve
this
problem.
F
E
G
Okay
next
slide,
so
my
observation
here
would
be
that
the
the
problem
here
really
is
caused
by
reusing
syntax
from
the
the
data
modeling
world.
So
json
schema
org
really
has
to
say
something
about
what's
actually
going
on
on
the
wire.
So
it
has
to
do
to
be
very
specific
in
some
ways,
but
it
also
has
the
luxury
of
being
very
unspecific
in
another
way,
because
it
doesn't
have
to
tell
you
what
it
means
and
that's
convenient.
G
It's
convenient
to
use.
Json
schema
org
because
there
are
a
few
inform
pure
information
modeling
languages
around,
and
these
are
often
a
little
bit.
How
shall
I
put
it
too
theoretical
for
what
what
we
are
trying
to
do
here,
but,
on
the
other
hand,
reusing
data
modeling
concepts
for
information.
Modeling
also
is
a
dangerous
thing,
because
it
can
move
the
mindset
of
the
specifier
to
what
really
should
be
protocol
bindings.
G
So
it
takes
takes
your
focus
off
the
question.
What
what
is
it
really
that
we
are
modeling
here
to?
How
can
I
represent
this
in
in
jason
or
sibo
or
lightweight
m2mtlvs
or
whatever
my
my
representation
language?
My
representation
format
is
at
the
moment,
so
what
we
have
been
doing
is
we.
We
have
been
defining
additional
qualities.
G
The
qualities
again
are
those
members
of
specification.
Json
objects,
not
members
of
objects
that
are
being
interchanged,
but
members
of
the
specification
json
objects
to
to
capture
some
of
those
aspects.
For
instance,
units
is
one
thing
that
that
is
done
in
sdf,
and
the
question
really
is:
is
this
another
place
where,
where
sdf
needs
to
to
act,
needs
to
define
its
own
thing
next
slide,
and
one
answer
is
yes,
and
that
is
the
request
number
eight.
G
So
the
the
idea
is
not
to
distinguish
between
single
values
and
and
value
ranges
and
and
mixing
types
and
so
on,
and
have
a
single
new
keyword,
sdf
choice,
which
can
use
the
the
name,
data
qualities
mechanism
that
we
already
have
for
giving
these
choices
names
and
for
including
some
form
of
of
a
more
more
precise
data
model.
If
that
is
what
we
actually
need.
So
if
we
have
a
choice
between
ants
bees
and
cats,
then
we
might
have
human
language
descriptions.
G
So
that's
probably
not
just
for
wildlife,
but
my
examples
here
happen
to
be
wildlife
examples,
so
we
could
reference
a
particular
unit
or
a
measurement
principle,
or
the
difference
between
indoors
and
outdoors
and
so
on.
These
are
all
things
that
that
are
usually
somehow
encoded
in
in
labels
like
and
b
and
cat,
but
that
really
might
require
more
specific
species
for
specif.
G
There
is
one
range
in
here
that
goes
from
1
to
254,
and
we
want
to
put
all
these
things
into
a
choice,
and
the
good
thing
is
that
we
actually
can
give
them
names
and
could
even
actually
add
semantic
tags
in
there.
I
haven't
done
that
here
that
explain
what
what
these
choices
actually
mean,
because
in
in
the
zigbee
example
that
michael
had
these
numbers
means
something
very
different
from
the
preset
values.
G
So
we
would
have
a
single
mechanism
called
sdf
choice
and
that
could
be
next
slide
could
be
used
to
describe
both
enum
and
any
of
of
json
schema
org,
and
it
would
give
us
full
data
shaping
capability
in
in
either
case.
It
would
give
us
a
discriminated
union
structure.
Any
of
office
is
a
anonymous
type
union
and
we
have
all
kinds
of
problems
with
anonymous
type
units
type
unions
in
a
lot
of
places.
G
G
G
G
G
So
the
the
question
really
is:
how
important
is
it
that
the
the
sdf
specification,
mimics
json,
schema
algae
and
I'm
not
asking
that
as
a
general
question,
I
think
as
a
general
approach,
we
have
agreed
when
in
doubt
use
use.
Json
schema
org,
because
that's
there
and
and
people
know
that,
and
there
are
tools
out
there
and
so
on.
G
But
how
important
is
mimicking
json
schema
on
here
and
the
the
pro,
of
course
is
that
people
who
don't
know
sdf
will
recognize
that
that
email
enum
on
on
the
on
slide
20
and
recognize
so
the
their
epi.
There
is
some
kind
of
choice
that
looks
like
the
choice
that
jason
schema
expresses
using
the
keyword
enum
and
then
they
know
what's
going
on
the
disadvantages.
G
So
if,
if
the
enum
says
on
off
and
the
the
sdf
anything
says
powered
unpowered
or
what
whatever
alternatives
they
are,
then
then
this
bug
needs
to
be
detected
and-
and
you
need
to
have
some
code
to
handle
that
and
so
on.
So
it's
not
without
costs
to
to
put
some
some
structure
in
there
that
that
is
more
complex
than
needed,
and
with
that
I
would
be
interested
to
hear
a
discussion
of
the
number
two
number
five
issue.
B
Before
we
start
that
can
as
a
time
check
issue,
we
have
24
minutes
left
to
this
meeting.
I'd
like
us
to
give
us
at
least
15
minutes
to
discuss,
discuss
the
web
of
things
at
the
end.
So
I
think
we
need
to
close
this
within
the
coming
nine
minutes
or
we
need
to
postpone
it
somehow
or
have
some
way
forward.
F
E
I
really
don't
understand
why
the
the
cons
are
being
written
here
as
cons.
You
can
also
see
that
as
a
prey.
So
frankly,
I
don't
know
why
we
are
doing
something
new
for
just
annotating
integers,
because
if
you
are,
if
you
have
an
idiom
of
strings
and
that
enum
value
is
not
yeah,
conveying
what
it
should
should
explain,
then
you
only
need
a
description.
E
E
F
I
can
show
a
few
more
things
that
you
might
want
to
do
like
remapping
to
other
values
and
providing
other
other
schema
extensions
for
those
points.
But
I
think
carson's
example
already
is
something
that
we
need
to
do,
which
is
to
provide
semantic
connectors,
which
is
what
I
call
semantic
anchor
for
these.
F
So
I
I
took
your
suggestion
from
last
week
and
said:
okay,
what
if
we
had
just
a
jsonschema.org
enum
with
strings
and
we
mapped
them
elsewhere,
and
so
we
looked
at
mapping
files
and
the
things
that
we
were
talking
about
with
mapping
files
and
everything
just
sort
of
converged
on
saying.
Well,
you
know,
really
what
would
be
handy
is
if
we
could
say
if
you
just
need
something
like
a
set
of
values,
you
can
use
json,
schema
or
enum.
F
It
looks
decent
as
an
annotation
if
you're
going
to
have
that
annotation
somewhere
else,
it's
just
harder
to
manage,
so
you
know
putting
it
in
line,
seemed
to
make
a
lot
of
sense.
So
that's
the
sort
of
the
background
of
how
I
arrived
at
this
idea.
Like
carson
says
you
could
always
do
something
different,
but
the
idea
is
that
if
you
just
need
an
enum,
you
can
just
put
in
an
enum
if
you
need
the
more
extensive
range
selections
and
things
like
that,
you
can
use
sdf
union.
F
E
E
F
E
E
E
E
What
you
want
to
do
with
the
preset
value,
then
we
need
to
have
a
lot
more
discussion
on
what
we
want
to
model
there,
because
this
is
now
a
little
bit
of
is
yeah.
Strangely
done
because,
frankly,
for
the
mean
range
at
constant
zero,
I
like
to
say
what
the
zero
means
and
not
what
what
the
mean
range
means
that
it
is
zero,
because
that's.
F
What
the
pattern
here
does
convey
the
meaning
of
the
different
elements
in
the
union
and
discriminated
union
is
a
really
good
way
to
describe
it.
That
the
whole
reason
for
having
each
element
have
its
own
schema,
and
so
you
can
add
those
descriptions
and
add
those
pointers
and
connectors
and
make
a
json
pointer
to
it.
And
then
you
know
even
the
ability
to
make
a
json
pointer
to
it
is
needed
to
add
additional
additional
qualities
elsewhere
and
using
an
enum.
You
can't
really
do
that.
F
You
have
to
know
the
position
of
the
element
and
you'd
suggested.
We
extend
jsonpointer
to
allow
you
to
put
in
the
string
name
of
the
enum
element
as
the
last
element
in
the
pointer
that
that's,
not
json
pointer,
that's
an
extension
that
is
non-standard,
that
we
would
have
to
build
in
as
part
of
sdf.
F
E
Well,
I
don't
like
sdf
any
anyway,
so
that's
that's!
That's
the
other
thing
any
is
such
a
nasty
thing
to
work
out
with
code
that
you
have
to
make
case
statements
or
if,
if
then
else,
statements
which
is
not
funny
to
do
if
you
want
to
write
code
for
that
automatically,
so
that's
something
that
you
want
to
avoid
in
models,
and
here
it's
just
an
enum
and
the
default
is
true
and
default
is
off
false.
F
F
That's
what
this
is
doing,
because
it
gives
you
the
ability
to
remap
those
and
change
that
to
zero
and
one
or
some
other
json
json
values.
If
you
want
or
sebor
values
or,
however,
you
do
your
your
enums,
you
know
that's
the
whole
idea
of
having
the
model
be
an
abstraction
and
then
allowing
you
to
these.
These
extension
points,
which
is
here
the
json
point
over
you,
can
do
in
the
mapping
you
can
say.
Well,
I
want
to
use
zero
and
one
that
defaults
true
and
false.
F
So
if
I
just
want
to
pick
up
the
default
use
it
in
my
json,
I
can
do
that,
but
I
can
also
be
fancier
and
map
it
to
my
ecosystems,
compact,
integer,
values
or,
or
you
know,
sub
sub
bit
fields
or
whatever
I
need
to
do,
and
we
have
you
know
the
bluetooth
uses
the
sub
bit
fields
right.
So
that's
really
what
the
point
is
here
this
sdf
any
and
by
the
way
it
is
exactly
telling
you
to
make
a
case
statement
and
and
that's
we
need
to
model
that
that's
part
of
the
problem.
Space.
E
F
I
agree
there
are
two
end
up
to
end
code
target
environment,
sort
of
implementations.
If
you
have
a
straight
enum,
the
value
selection
doesn't
need
a
case
statement.
You
can
do
all
kinds
of
other
mapping
stuff
with
it.
If
you
have
a
generalized
thing
like
a
cfn,
esdf
union
sdf
choice,
I
don't
care
what
it's
named.
That's
a
case
statement
or
that's
a
different
kind
of
code.
I
agree
with
that
and
so
we're
not
okay.
E
Can
we
can
we
then
get
to
a
conclusion
that
we?
If,
if
you
just
do
a
regular
enumeration
of
values,
then
you
never
just
use
the
standard
json
stuff,
at
least
that
we
don't
deprecate
it,
and
I
think
we
definitely
need
more
time
to
talk
about
what
kind
of
modeling
you
want
to
do
with
sdf
annie
it's
for
me.
It's
still
not
clear
in
what
you
want
to
do.
H
F
Can
I
can
I
just
address
father's
first,
I
think
that
it'd
be
useful
to
look
at
some
broader
discussion,
but
I
I
don't
want
to
let
go
of
the
moment
right
yet
and
and
so
wilder.
I
think
that
there
may
be
that
what
you
say,
maybe
may
make
sense
and
that
we
allow
json
schema
org
enum,
where
you
just
want
a
simple
selection
of
values,
and
we
allow-
and
we
provide
this
other
pattern
for
the
other
examples
that
I
definitely
have
many
of
that
I'm
going
to
need
for
this.
F
E
E
E
I
B
Okay
yeah,
so
I
mean
unfortunately,
I
it
seems
like
we
are
not
really
getting
any
I
mean
we
have
to.
We
have
a
couple
of
different
solution:
families
with
various
aspects,
not
really
even
maybe
two
solutions
but
they're
different
in
a
way,
and
we
don't
really
seem
to
get
to
a
consensus
here.
The
question
is,
of
course,
that
this
really
was
one
of
the
things
that
we
wanted
to
have
in
sdf-101
and
unfortunately
we
have
been
discussing
this
problem
for
quite
some
time
and
I'm
not
really
so
either
we
either.
We.
F
F
C
E
E
C
E
F
F
E
E
So
I
don't
even
know
what
these
kind
of
things
are,
these
for
me.
It's
a
number.
It
can
be
a
min
range,
it
can
be
a
max
range,
it
can
be
pres,
preset
value
and
the
preset
value
is
again
a
range
this.
This
is
for
me.
This
is,
I
don't
know
how
to
apply
any
of
this
and
I
like
to
understand
what
I'm
getting
into
so
your
example
with
sdf
any
is
way
more,
concise
and
way
more
precise
in
what
it
can
do.
E
D
E
Being
used
to
describe
things,
then
I
don't
disagree
with
any
sdf
any
I'm
just
saying
that
a
switch
state
should
still
have
an
additional
type
here,
saying
it's
just.
It
is
a
string
or
an
or
a
number
or
an
integer,
because
that's
that's.
If
you're
looking
at
json,
that's
an
additional
qualifier
to
say
if
what
you're
trying
to
convey
is
correct.
C
G
B
G
So
my
plan
for
for
getting
sdf
one
one
out
this
year
was
to
to
write
this
text
for
number
seven
that
we
talked
about
agree
on
solutions
for
two
and
five
write,
the
pull
request
or
start
from
the
request
we
already
have
and
publish
dash
o2
this
week.
Do
a
last
call
of
that
in
the
working
group
and
publish
a
03
based
on
the
last
call
results,
and-
and
this
interesting
discussion
here
is-
is
slowing
us
down
from
that
plan.
G
B
F
Me
just
try
to
try
to
try
to
hit
the
target
here.
What
if
we
do,
what
if
we
meet
wilder's
need
and
not
deprecate,
json
schema,
org,
enum
and
but
not
say
a
lot
about
how
that's
used
or
how
it's
not
used
right,
and
we
also
meet
my
requirement
and
allow
an
sdf
any
and
not
really
say
a
lot,
how
about
how
it
might
be
used
with
or
without
an
enum?
And
let's,
let's
kick
that
down
to
the
next
stage.
B
B
Yeah
good
good
so
to
our
web
of
things.
Friends,
I'm
apologizing
here
for
running
over
time.
As
you
saw,
this
discussion
has
been
a
bit
intense.
If
people
have
a
couple
more
minutes,
it
would
be
really
nice
to
have
both
a
presentation
from
sebastian
and
some
discussion
with
you
guys.
Can
people
stay
around
for
10
minutes?
More,
perhaps.
G
I
H
You
well
so
it
was
quite
interesting
to
hear
about
your
discussion
about
this
choice
thing
as
I
already
shared
on
webex.
There
is
already
a
similar
discussion
going
on
on
on
github
in
the
thing
description
repository,
and
we
have
a
little
bit
advantage
that
we
have
json
ld
around,
so
that
there's
maybe
also
another
proposal
there
which
we
can
rely
on,
but
I
think
this
is
actually
also
topic
where
we
can
work
together
on
and
my
personal
opinion
is.
H
But
but
what
I
see
as
a
kind
of
danger
is,
if
you
say,
okay,
inaudible,
it's
maybe
not
perfect.
For
us.
We
don't
use
it
and
we
take
another
way.
Then
you
fill
or
will
go
in
a
direction
which
maybe
makes
more
complicated
to
to
compare
other
approaches
or
to
combine
other
approaches,
other
models
etc,
and
I
think
json
schema-
creates
a
good
basis
for
data
modeling,
and
this
is
actually
a
good
point
where
you
can
meet
each
other
right.
H
And
if
you
go
a
different
direction
with
different
concepts,
then
it
makes
more
complicated
yeah,
and
I
think
this
is
what
my
personal
opinion
would
be,
that
we
should
avoid
as
much
as
possible
yeah,
because
we
have
not
that
much
time.
Maybe
I
will
only
show
you
one
project
which
taking
care
of
yes,
yeah.
H
H
G
H
So
what
I
like
to
show
you
is
that
we
have
well
one
of
the
goal
of
the
next
or
the
current
charter,
which
you're
working
on
is
also
to
have
this
thing
model
concept
in
the
former
version
of
or
of
the
1.0
version
of
the
theme
description
we
had
already
this
concept
there.
There
was
a
different
name
for
that
that
it's
called
scene
description
template.
H
So
one
is
a
kind
of
self-contained
description
to
say:
okay,
I
just
want
to
describe
the
the
model
of
the
thing
and
which
can
be
used
for
digital
twin
use,
cases
in
cloud
use
cases
for
onboarding,
etc,
and
the
other
use
case
is
to
use
the
thing
model
as
a
template
for
things.
Script.
Operation
yeah
that
you
say:
okay,
you
have
all
the
data
in
there
and
also
some
already
basic
direction
regarding
the
communication
meter
data
there
and
you
can
use
this
for
creating
thing
description.
H
The
the
definitions
there,
which
are
provided
there
to
have
also
this
as
a
thing
model
representation,
and
I
would
like
to
share
you
sorry
this
this
project.
Here,
it's
quite
fresh
and
it's
a
student
of
mine.
He
just
started
its
thesis
and
I
asked
him:
hey
just
write
us
a
nice
tool
to
convert
sdf
definition
to
thing
models,
so
I
would
like
to
share
with
you
this
project
that
you
maybe
can
also
play
around
with
that
and
what
you
just
have
to
do.
H
You
have
to
just
to
point
you
sdf
definitions
in
somewhere.
You
can
then
simply
point
to
to
the
location,
and
then
it's
simple
transforming
this
to
to
to
a
thing
model
representation,
and
here
you
see
the
list.
What
is
supported
so
far,
so
my
student
also
checked
this
sdf
choice
already,
but
it's
as
you
can
see,
used
to
do
and
as
I
have
here
today,
you
are
currently
still
discussed
discussing
on
that.
H
H
B
H
H
What
is
with
our
theme,
model
approach
and
we're
doing
the
same,
also
for
the
oracle
model
and
for
the
eclipse
model,
so
that
we
have
a
very
cool
model
approach
here,
where
we
can
cover
all
the
existing
models
out
there,
and
I
can
also
invite
you
to
to
join
one
of
the
github
discussions.
We
have
sdf
discussion
here
as
well,
so
michael
costa
mainly
is
involved
in
that.
So
I
think
it's
mainly
here
right
yeah,
so.
F
I'm
looking
at
the
bigger
issue
of
workflow
and
how
sdf
models
can
how
we
can
use
web
of
things
as
to
apply
protocol
bindings
and
data
schemas,
and
all
that
to
the
abstract
models
that
we
have,
and
so
any
this
is
really
great
to
have
a
consumer
of
sdf
models.
That's
sort
of
doing
this,
this
remapping.
H
Yeah
we
can
do
that,
so
this
is
a
issue
which
taking
care
of
the
regular
device
model,
so
michael
legally
is
driving
this
mainly
and-
and
we
have
also
the
same
for
the
eclipse
water,
which
bosch
is
mainly
driving
this
yeah
right
here.
It
is
right
yeah.
So
if
this
is
just
you
to
make
you
aware
of
that
and
right
and
it
would
be
cool
always
to
exchange
with
you
and-
and
I
shared
you
with
the
link
which
we
had
actually
almost
the
same
discussion.
C
B
Yeah
yeah,
thank
you
very
much.
This
was
great,
very
interesting
stuff,
so
so
looks
good.
Now,
it's
really
interesting
to
hear
that
you
are
obviously
more
deriving
from
different
modeling
languages,
and
that
seems
to
work,
and
I
guess
it's
really
good
if,
of
course,
if
you,
if
you
or
your
student,
comes
up
with
interesting
problems
during
your
development,
it's
good
to
know
about
them,
so
we
can
address
them
in
sdf
yeah,
or
I
mean
that
that
includes
like,
if
the
specification
is
not
clear
and
so
on
so
great
thank
you
yeah.
B
So
that
was
that,
and
then
we
had
actually
the
final
point
here
for
the
last
minutes,
or
so
was
about
cooperation.
Now,
we've
seen
that
to
thinks
is
doing
some
interesting
and
relevant
stuff.
We
talked
a
bit.
I
had
a
male
discussion
with
with
cas
and
others
on
on
collaboration
here
so
cass.
Maybe
I
should
leave
it
to
you
and
sort
of
so
what
you
were
thinking
about.
D
B
D
I
B
I
mean
presumably
our
our
interest
here
is
reasonably
aligned
and
we
don't.
We
can
sort
of
agree
and
and
cooperate
between
without
too
much
problems.
But
absolutely
I
mean
we
can.
We
can
do
what
is
needed
to
the
formalities
right
yeah,
but
but
please
bring
it
to
the
mailing
list
and
feel
free
to
use
that
for
that.
B
B
Productive
meeting
we
did
manage
to
get
get
the
resolutions,
so
that
was
good,
but
thank
you,
and
also
we
will.
Let's
continue
on
the
web
of
things,
discussion
on
the
mailing
list
and
how
to
bring
that
forward,
and
I
think
we
had
a
substantial
input
from
that
viewpoint
as
well,
so
that
was
very
much
appreciated.