►
From YouTube: IETF110-ASDF-20210311-1200
Description
ASDF meeting session at IETF110
2021/03/11 1200
https://datatracker.ietf.org/meeting/110/proceedings/
B
B
Think
we
are
actually
it's
time
to
get
going.
B
B
Yeah
yeah
yeah
yeah,
it
has
ethernet
or
and
things
but
honestly
I
haven't.
I
haven't
hooked
it
up
to
anything,
yet
it
was
recently
purchased
by
the
family
or
for
my
youngest.
B
Anyway,
so
it's
now
one
o'clock
in
in
europe
here
and
12
utc,
so
I
think
we
should
get
going
and
we
will
let
people
trickle
in
as
we
go
along
welcome
to
the
asdf
working
group
meeting
at
iitf
110,
it's
nicholas
adele
here
and
my
co-chair
is
michael
richardson,
who
you
see
in
the
other
picture.
B
Can
you
change
slides
next
slide?
Please,
okay!
This
is
an
itf
meeting.
Here
is
the
short
note.
Well,
the
long
one
is
coming
on
next
page
briefly,
you
can
go
back
to
the
previous
one.
I
think
it
has
the
you.
F
B
Recorded
remember
to
be
nice
and
be
professional
and
remember
that
ipr,
the
itf
ipr
guidelines
are
in
in
effect
and
there
you
have
links
to
our
github
repo,
where
you
can
file
all
agendas
and
so
on,
and
also
the
notes
for
this
particular
meeting,
and
those
notes
will
of
course
also
end
up
in
the
repo
eventually
good
next
slide.
Please,
and
so
here,
is
the
full
note.
Well,
I
hope
you've
read
it
if
not
read
it
at
your
convenience.
B
This
is
the
agenda
for
today
we
start
out
with
an
introduction
admin,
stuff
agenda,
bashing
and
so
on.
We
will
say
a
few
words
about
who
we
have
been
talking
to
with
this
working
group.
Since
this
this
is
largely
about
building
things
from
the
wider
community.
B
We
will
say
a
few
words
about
the
hackathon
outcome
that
we
had
last
week
and
then
we
will
move
on
to
the
actual
specification
work
and
this
the
update
there
and
the
consensus
call
for
sdf-11
we'll
do
a
bit
of
planning
for
upcoming
virtual
interims
and
then
we'll
move
on
to
the
next
features.
So
what
will
be
in
future
versions
of
sdf-
and
there
are
a
couple
of
lists
there,
so
these
the
agenda
was
updated
just
before
here,
as
we
had
some
minor
or
some
changes
in
in
the
last
minute.
B
But
this
this
is
also
a
data
tracker
now
yeah
next
slide,
please
the
administrative
stuff.
There's
a
code
md,
there's
the
meet
echo
jabber,
all
notes
at
the
point
there
we
have
so
michael
is
jab
prescribing
and
taking
some
notes.
Ari
is
also
helping
out
with
the
notes
in
kodi
md,
and
I
saw
that
michael
sent
in
the
in
the
chat.
B
Please,
if
you
want
to
speak
up
from
jabber,
add
mick
colon
at
the
start
of
your
sort
of
point,
so
we
don't
miss
it
trying
to
navigate
all
these
windows
on
our
screens
simultaneous
windows
anyway.
Next
slide,
please.
B
So
this
is,
these
are
just
the
the
working
procedures
for
asdf
working
group.
We
are
using
the
same
from
since
the
start.
We
keep
our
decisions
on
the
mailing
list
and
we,
but
we
do
the
most
of
the
work
on
github.
There's
the
link
there
and
we
use
an
issue
tracker
on
github
to
actually
track
issues
which
includes
new
features
and
fixes.
B
So
to
follow
this
work,
you
need
to
both
register
for
the
mailing
list,
as
well
as
join
our
community
on
github
and
in
addition
to
holding
meetings
at
the
sort
of
the
face-to-face
virtual
face-to-face
meetings.
We
also
do
a
couple
of
virtual
interims
between
the
virtual
physical
meetings
and
for
these
we
we
notify
people
on
the
mailing
list,
and
then
we
typically
do
a
doodle
to
ensure
that
we
get
have
find
times
that
people
are
that
fit
people's
schedules
next
slide.
Please.
B
B
Obviously
this
is
not
from
the
future,
so
we
were
chartered
last
october
and
we
had
our
first
meeting
at
at
first
virtual
physical
meeting
at
the
109
with
a
hackathon,
and
we
had
one
interim
before
that
and
one
in
trim
after
that
and
where
we
are
now
is
that
we
have
a
reasonably
stable
specification,
the
what
we
will
call
the
sdf11,
which
is
on
call
of
consensus,
and
I
will
come
to
why
we
call
this
sdf
one
one
in
in
a
couple
of
slides.
B
In
addition
to
that,
we
had
a
there
was
a
hackathon
event
last
week,
together
with
the
wishy
folks.
I
will
also
say
a
few
words
about
that
later
and
where
we
basically
talked
about
new
features
for
asdf
meeting
plans
yeah,
we
will
obviously
meet
today
here
and
then
we
will
plan
new
meetings
and
to
be
there
were
some.
Unfortunately,
there
was
a
scheduling
complexity
around
this
meeting.
I
shouldn't
say
unfortunately,
but
we
we
had
requested
a
one-hour
meeting.
B
Now
we
have
a
two-hour
meeting
and
we
are,
of
course
very
grateful
for
that,
because
we
can
have
longer
discussions,
but
that
was
the
outcome
of
sort
of
deconflicting
other
meetings
anyway.
Next
slide,
please.
B
So,
let's
say
a
few
words
about
the
asdf
outreach
and
the
purpose
of
doing
the
asdf
work,
which
is
basically
developing
the
sdf
specification,
it's
of
course
to
to
enable
this,
this
vehicle
of
of
interoperability
between
data
and
information
models
coming
from
different
organizations,
and
we
have
been
doing
some
outreach.
I
realized
now
that
I
even
missed
a
couple
of
things
there
has
been.
We
have
talked
to
the
the
light
with
m2m
group.
You
know
most
backworks,
we
have
part
of
sd.
B
Sdf
is
actually
part
of
an
iso
proposal,
even
if
the
specification
is
not
even
done
yet
for
jtc
one
sc41
on
it
iot.
We
have
an
ongoing
collaboration
with
web
of
things.
We
have
talked
about
other
use
cases
where
the
setup
of
sdf
can
be
useful,
like
electronic
data
sheets,
textile
manufacturing
and
so
on.
B
The
end
message
for
this
is,
of
course,
that
if
you
are
part
of
an
iot
organization
that
works
with
data
models,
we
are
happy
to
work
with
you
and
reach
out
to
you
and
discuss
where
we
can
cooperate,
because
the
value
of
sdf
will
be
dependent
on
how
many,
of
course
implement
it
or
cooperate
with
it.
B
Yes,
next
slide,
please
yeah,
so
the
ietf
hackathon
that
was
last
week
and,
as
I
said,
this
was
a
collaboration
with
between
folks
in
the
asdf
working
group
and
the
folks
in
the
wishy
activity
of
things
to
things
research
group
and
we
had
a
it,
looks
like
we
worked
all
week
last
week,
but
we
had
actually
daily
one-hour.
Think
meetings
during
the
week
where
people
discussed
various
topics,
we
had
seven
people
contributing,
including
two
newcomers,
one
of
which
was
a
student,
and
the
outcome
was
quite
interesting.
B
B
Next
slide,
please,
I
can
so
here
is
a
bit
more
details
on
the
the
discussions
that
were
had
on
validating
stf11
work
on
the
semantic
proxy,
these
tools,
the
thing
maker
and
so
on,
and
then
the
mapping
file
concept
and
kirsten
will
talk
to
this
slide,
a
lot
more
in
the
things
to
things
research
group
tomorrow,
but
it's
here
for
completeness
this
is
the
kind
of
more
concrete
stuff
they
put
into
it.
B
B
Yeah,
sorry,
I'm
a
beast.
I
wasn't
looking
at
my
schedule.
D2Trg
is
this
afternoon,
so
you
just
have
to
wait
like
a
couple
of
hours
for
this
to
four
hours
from
now.
You
will
hear
this
slide
again.
B
Yes,
next
slide,
please.
B
So
when
we
started
this
work
in
a
in
in
asdf
last
year,
we
already
came
with
a
reasonably
mature
specification,
which
was
marked
as
sdf-10,
and
the
first
objective
of
this
working
group
was
to
develop
to
take
specification,
do
as
much
quality
improvement.
We
could
on
that
and
then
add
the
some
features
needed
and
then
it
calls
something
in
sdf11
and
we
did
that
work
and
we
did
some.
B
There
are
some
number
of
major
changes
on
cross-referencing
and
reusing
various
other
specifications
from
an
stf
file,
support
for
composite
data
types
and
then
a
longer
long
discussion
on
on
enumeration
choice
and
so
on,
and
with
that
we
we
thought
we
had
something
that
we
were
happy
with
to
to
call
sdf101
and
mark
as
an
implementation.
Draft
implementation
draft
is
not
sort
of
a
formal
isdf
status.
It
should
be
noted.
B
It's
just
a
way
to
indicate
that
the
particular
specification
is
stable
enough
to
serve
as
a
basis
of
intermediate
basis
until
the
final
specification
is
done
so,
and
the
reason
for
that
is
that
we
really
need
that
in
the
one
data
model
work
where
we
need
to
have
a
common
specification
to
work
against
anyway.
So
we
called
for
a
call
for
consensus
a
couple
of
weeks
ago,
february
23rd
it
concluded
two
days
ago,
and
there
were
no
objections
raised.
So
we
all
must
have
an
sdf-101.
B
However,
during
since
we
made
this
last
call,
there
have
been
a
couple
of
minor
issues
raised
and,
and
so
they're
not
objections
per
se,
but
they
are
minor
issues
or-
or
some
of
us
call
comments
that
we
would
like
to
address.
So
with
that
you
can
go
to
the
next
slide.
A
Yes,
so
we
had
a
pretty
intensive
a
couple
of
weeks
working
on
sdf
and
obviously
a
few
things
popped
up,
so
that
there
are
three
pull
requests
now
that
that
I'm
proposing
we
put
into
the
the
document
before
we,
we
publish
it
as
1.1,
and
the
first
thing
is
that
there
are
some
some
editorial
things
id
needs
and
so
on,
but
most
importantly,
the
id
net,
that
is
a
gaping
hole,
is
the
ayanna
consideration
section
for
applications,
sdf
plus
json,
and
because
this
implementation
draft
is
probably
what
should
be
referenced
from
the
media
type
registry,
it
would
be
really
good
to
have
that
ayanna
considerations
section
in
there
now,
so
you
we
can
go
through
all
the
generations
of
getting
an
earlier
location
and
so
on.
A
I
propose
that
that
we
apply
this
pull
request.
The
second
pull
request
came
out
of
an
observation
last
week
in
in
the
hackathon
that
that
is,
if
you
actually
compose
sdf
from
from
various
pieces,
which
is
something
that
that
people
in
the
tool
space
want
to
do.
It's
really
onerous
that
the
the
info
block
is
required.
A
You
actually
have
to
write
code
to
discard
the
dummy
info
blocks
and
even
though
the
policy
to
have
an
info
block
is
certainly
something
that
we
want
to
have
in
in
in
1dm
and
other
places.
The
the
mechanism
really
gets
in
the
way
when,
when
you
are
building
sdf
files
from
pieces,
so
pull
request.
24
makes
the
info
blog
optional
and
adds
some
text
there.
A
That
explains
this
is
not
meant
to
to
make
it
optional
in
in
the
sense
of
a
policy,
but
it's
just
a
change
in
the
mechanism
to
to
simplify
writing
to
it,
and
we
have
had
a
side
discussion
on
on
whether
the
just
making
the
whole
info
block
optional
is
enough,
and
we
we
want
to
maybe
make
individual
entries
in
the
infobox
optional.
I
don't
think
that's
needed,
but
we
we
certainly
can
can
discuss
that.
A
We
just
should
come
to
a
conclusion
really
quickly
on
this
one
and
the
the
third
pull
request
came
out
of
a
desire
to
finally
define
a
scale
minimum
and
scale
maximum,
which
has
been
in
the
sdf
spec
since
may
2020,
but
never
was
really
defined,
so
it
existed
as
as
an
idea
in
in
michael
costa's
head,
but-
and
maybe
he
had
told
a
few
people
so
that
they
had
something
in
their
heads
as
well,
but
we
didn't
actually
write
this
down,
so
we
actually
did
this
and
this
led
to
pull
request
22,
but
then,
with
with
further
work
on
on
these
qualities,
it
actually
turns
out
these
things.
A
Don't
work
the
way
they
should
so
at
the
time
when,
when
scale
minsky
max
were
invented
at
the
beginning
of
last
year,
we
hadn't
really
thought
about
combining
models
and
mapping
files.
So
the
the
compositional
aspect
of
these
qualities
wasn't
really
in
in
the
focus.
A
So
there
was
a
lot
of
design
space
and,
and
this
gaming
scale
max
used
one
one
corner
of
the
design
space.
That
actually
is
not
the
the
right
way
to
support
combining
models
and
mappings.
So
I
have
some
some
detailed
slides
on
on
that
later.
If
there
are
questions,
I
can
explain
those
slides
beforehand,
but
I
think
that
the
main
observation
here
is
we.
A
A
A
A
So
that's
a
summary
of
the
three
pull
requests.
So
none
of
these
actually
change
the
the
format
in
the
sense
that
the
tools
that
are
creating
and
and
consuming
sdf
have
to
change.
Well,
okay,
they
may
have
to
cope
with
an
optional
info
section,
but
that's
probably
not
very
onerous,
but
otherwise
there
is
no
change
in
in
the
format
and
that's
why
we
actually
can
merge
this
before
publishing
or
for
without
creating
instability,
and
I
think
this
would
be
a
good
point
to
have
a
little
bit
of.
B
Sorry,
sorry,
I
was
on
you
to
keep
you
from
hearing
my
drinking.
A
B
G
Are
you
okay?
So
maybe
a
quick
comment
on
all
this?
I
guess
the
first
one
is
rather
obvious.
Let's
just
do
it
and
just
the
following
two
are
the
one,
maybe
a
bit
more
discussion
and
on
the
on
on
the
info
block
yeah
I
mean,
as
carson
pointed
out,
I
mean
it's
it's
currently
it's
there.
G
You
always
need
to
have
it
it's
a
bit
onerous
when
you're
doing
these
models
and
then
especially
if
it's
full
of
dvds
handling
those
knowing
when
it
when
it
actually
is
something
you
should
be
consuming
and
when
it's
not,
it
seems
to
be
that
the
reasonable
thing
to
be
is
to
have
it
optional
and
then,
when
it
is
actually
properly
needed,
you
know
you
can
have
your
schema,
require
it,
for
example,
when
you're
contributing
to
the
models
to
the
to
the
world
to
be
to
be
used.
G
So
I
think
they're
making
it
optional
makes
sense,
but
I
don't
have
a
strong
opinion
on
that
and
the
scale
mean
max.
Maybe
it's
good
to
discuss
with
the
with
the.
G
A
So
one
observation
is
that
there
is
an
sdf
linter
that
that
we
use
to
run
the
the
playground
through
and
so
on,
and
that
would
be
a
tool
that
actually
makes
this
required,
because
we
don't
want
to
have
what
is
in
the
playground
where
we
don't
know
the
license
or
who
made
that
which
version
it
is
so
the
the
linter
doesn't
necessarily
have
to
do
exactly
the
same
thing
that
the
grammar
does.
F
Michael,
oh
michael,
I'm
unmuted,
okay,
but
I'm
still
in
the
cube.
Okay,
I
can
think
of
something
there.
We
go
so
a
couple
of
comments.
On
the
I
mean
I
have
more
comments
on
the
scale
stuff,
but
we'll
get
into
that
later
on
the
info
block,
it
seems
like
it
might
there's
one
useful
feature.
That
is
a
version
which
sort
of
advances
with
the
date,
which
is
a
pretty
simple
thing
that
might
be
useful
in
the
tool.
F
But
the
main
thing
I
wanted
to
point
out
was
that
during
the
early
work
in
1dm,
we
wanted
a
way
to
track
everybody's
contribution
as
we
merged
models,
so
the
copyright
would
contain
some
sort
of
list
of
all
the
contributors,
and
so
there's
a
there's
a
bit
of
the
process
in
the
playground
that
we
haven't
really
worked
out
about
copyright,
tracking
and
and
for
the
license.
But
since
it's
gpl
I
mean
so
sorry
since
it's
bsd
three
clause,
it's
not
super
important.
F
Well,
I
guess
it
is
because
that
it
says
that
copyrights
would
be
tracked.
So
there
is
a
question
about
you
know
who
owns
the
copyright
of
the
merged
model
and
and
how
that
gets
tracked
through
the
one
dm
process.
But
what
we
need
extensive
support
in
sdf,
for
that
or
not
it
seems
like
still.
An
optional
info
block
doesn't
really
get
in
the
way
of
that.
B
I
I
think,
that's
a
good
point,
and
I
agree
that
maybe
we
don't
I
mean,
I
think
this
is
probably.
I
guess
the
problem
here
is
that
if
we
keep
it
the
way
as
this,
I
I
guess
that
there
is
not
really
spec
support
to
actually
do
the
kind
of
merging
of
copyrights
and
and
merging
of
licenses
and
so
on,
and
how
to
actually
process
that,
and
that
is
probably
something
that
takes
a
bit
of
investigation
to
get
that
right
to
make
it
useful.
B
I
mean,
and
because
probably
one
interesting
thing
here
would,
of
course
be
this
kind
of
machine,
readable,
license
and
terms
of
use
mechanism,
but
that
that
sounds
like
that
requires
a
bit
more
work.
Actually,
so
the
question
here
is
really
do
we
I
mean
we
can
either
we
can
either.
So
if
we
keep
take
it
from
the
top
here
right,
the
first
one
is
is
reasonably
simple.
The
second
one
obviously
has
some
aspects
to
it.
B
There
was
a
reason
why
this
was
made
mandatory
from
the
starts,
but
maybe
for
now
it's
not
so
doesn't
really
break
anything.
The
third
one
is
is
technically
more
complicated,
but
so
it's
more
of
a
time,
but
it's
not
not
unsolvable,
but
it
takes
more
time
to
spec
it
out.
B
I
we
can
take
the
discussion
now
or
I,
or
I
think
I
would
rather
say
that
we
we
postpone
that
discussion
until
sdf
next
and
sort
it
out
in
the
next
major
version,
since
this
is
not
needed
right
now,
and
then
we
get
it
right
in
sdf
next.
B
But
that's
my
proposed
way
of
handling
this.
So
so
we
can
basically
finish
this
sdf
one
one
now
wrap
it
up
and
have
have
something
robust
there,
because
otherwise,
I
think
we'll
be
stuck
in
this
cycle
of
finding
problems
and
solving
them
and
finding
problem
new
problems
and
never
get
anything
wrapped
up.
B
But
of
course,
I'm
open
to
two
opinions
here.
So.
D
I'm
just
looking
at
the
polar
request
itself
and
it's
rather
sweet
it
just
you
know,
makes
it
optional
and
I
think
winter
I
think
said
it
right,
although
not
a
syntax
error,
a
warning
should
be
given
that
this
block
is
missing.
That
sounds
like
I
think
what
what
what
carson
was
saying
about
the
lint
versus
the
validity.
So
it
sounds
to
me
that
the
copyright
issue
is
a
bigger
issue
and
that
actually,
what
we
need
is
some
rules
about
combining
infoblox
if
they
are
and
present
felt
like
sdf
next
to
upper
issue.
B
D
We're
not
making
optional
doesn't
doesn't,
doesn't
eliminate
our
how
if
it's
present,
how
do
you
merge
merge
it,
which
I
think
part
of
the
discussion
was
about
and
so
whether
it's
in
whether
it's
optional
or
not,
you
still
have
to
solve
that
as
a
separate
problem
and
that's
what
I'm
hearing
is.
People
are
concerned
that,
if
it's
optional,
that
we
would
lose
the
copyright
information
and
the
contribute
contributor
information.
But
if
someone
has
put
that
info
block
there,
then
it's
not
it's
it's
it's
there.
D
G
Michael
made
a
good
point
about
the
we
would
deal
with
the
deal
with
merging
the
contents
if
they
are
there,
but
maybe
how
we
could
look
at
it
if
it's
optional.
Now,
you
have
a
way
to
indicate.
I
don't
have
anything
to
say
here,
but
if
it's
required,
you
don't
have
this
mechanism,
you
would
have
to
put
the
dvds
and
then
the
code
would
have
to
figure
out.
If
that's
that,
what
should
be
there
or
not?
A
F
Yeah,
so
I
did
want
to
point
out
that
when
we
did
have
a
few
discussions
about
how
the
merging
would
be
done-
and
we
didn't
really-
this
was
probably
even
maybe
2019,
because
it
was
a
face-to-face
meeting
and
we
never
really
came
up
with
a
pattern
other
than
what
we
thought
that
when,
when
a
composite
definition
was
created,
it
would
carry
all
of
the
copyrights
and
when
a
thing
was
created,
it
could
indicate
which
piece
was
going
to
which.
F
So
it's
not
a
simple
answer
at
all,
and
I
think
that
the
approach
is
correct,
and
I
agree
with
all
of
this-
that
we
don't
really
have
to
consider
how
it's
done
right
now
and
I
think
to
make
it
a
sdf.next
is
fine
and
we
we
do
have
that
more
work
to
do
and
for
now,
if
you
keep
the
copyright
on
an
original
source
somewhere,
it
can
always
be
tracked
back.
So
we
can
have
the
tools
be
a
little
more
loose
about
that
and
still
have
that
original
contribution.
F
Especially
if
we
have
the
contributor
repos,
we
can
keep
that
copyright
information
and
we
can.
We
can
think
about
doing
the
tracking.
We
haven't
done
it
yet,
so
we
haven't
made
any
mistakes,
and
maybe
there
are
more
comments
on
this,
but
I
wanted
to
make
a
comment
on
the
scale
min
and
max
first
that
models
that
use
those
will
still
validate
as
1.0,
which
doesn't
really
mean
they
validate,
but
it
means
that
they
have
a
way
of
being
present
without
breaking
things
and
still
getting
flagged
as
not
being
up
to
date.
F
They
can
also
be
experimented
with
as
a
protocol
as
a
mapping
file
entry,
and
we
can
talk
a
little
bit
more.
I
have
one
slide
about
the
scaling
as
mapping
files,
so
we
can
experiment
with
some
of
the
patterns
having
them
in
as
extensions
without,
as,
as
you
know,
custom
extensions
without
having
to
you
know
change
the
validation,
because
I
think,
with
custom
extensions
and
one.next
we're
looking
at
things
like
having
extension
schemas
that
can
validate
just
a
piece
of
something
that's
an
extension.
H
B
B
So
I
guess
what
we
really
need
to
have
have
have
a
disguise.
Have
a
decision
on
here
is:
if
you
want
to
do
something
before
marking
o4
with
these
changes
as
implementation
draft
and
on
what?
Basically,
we
need
to
wrap
up
the
call
for
consensus.
B
So
there's
a
last
call
on
this,
and
what
I
hear
is
that,
while
two
and
three
here
they
are
not,
there
are
side
effects
by
doing
things
and
and
lots
of
additional
work
is
needed,
but
maybe
where
we
are
now
in
this
process,
it
would
work
to
to
actually
these
changes,
making
info
block
optional
and
removing
the
scale
max
bin
and
that
would
not
and
then
sort
of
get
going
at
solving
those
problems
in
the
next
cycle
is
a
good
way
forward.
B
G
Maybe
one
comment
on
the
on
the
third
one:
carson
did
you
have
more
detailed,
slides
coming
on
that
aspect.
I
G
So
maybe
we
could
have
that
after
the
ball
on
that
one
after
that
part
and
then
do
the
one
one
and
two,
I
guess
we
don't
have
more
more
details
because
they
are
quite
straightforward.
B
B
B
A
A
Thank
you.
This
is
a
few
slides
that
that
actually
describe
what
what
we
should
be
doing
for
one
point
next,
but
of
course
they
also
contain
information
about
1.1.
A
So
basically,
the
the
the
important
thing
to
keep
in
mind
is
that
that
sdf
describes
an
information
model.
So
it's
it's
not
meant
to
to
give
you
a
way
to
directly
derive
instances
on
the
wire.
A
Just
from
the
information
model,
you
may
have
to
add
a
mapping
file
or
a
protocol
binding
file,
or
I
think
there
are
other
words
for
these
things,
so
that
that's
something
that
we
want
to
understand
how
to
do
in
one
point
next,
but
sdf
itself
is,
is
meant
to
to
be
the
the
converged
combined
information
and
different
ecosystems,
or
even
different
different
implementations.
A
Different
instances
may
have
different
digital
representations
for
the
same
information,
so
the
information
model
doesn't
change,
but
whether
your
temperature
sensor
goes
to
800,
kevin
or
1100
kevin,
maybe
a
difference
from
instance
to
instance,
so
the
the
the
problem
we
we
were
having
while
we
we
discussed
this
during
the
last
two
weeks,
was
that
there
is
kind
of
a
perception
all
these
jason
schema,
all
derived
qualities
describe
the
digital
side,
so
the
actual
interchange
what's
on
the
wire,
but
that's
actually
not
what
we
are
doing.
A
We
are
borrowing
those
those
qualities
from
json
schema.org,
but
they
are
not
meant
to
describe
the
the
actual
underwire
bits.
They
are
meant
to
describe
the
information
model
and
that's
generally
a
likely
thing.
You
will
find
that
because
there
are
a
few
good
languages
for
describing
information
models,
that
people
are
using
ab
using
misusing
data
model
specification
techniques
for
information
models,
and
we
are
guilty
of
that
too.
But
I
think
it's
not
a
problem
as
long
as
we
stay
conscious.
A
So
summary
of
this
slide,
the
the
information
model
is
about
the
physical
side
and
the
the
actual
quantities,
the
the
physics
quantities
and
not
about
the
the
bits
on
the
y
next
slide.
A
So
when
we
add
the
scale
minimum
side
to
the
picture,
we
get
this
really
weird
situation
where
the
scale
minimum
pushes
out
minimum
and
maximum
from
the
physical
side
to
the
digital
side.
A
So
either
these
things
change
their
semantics
based
on
the
presence
or
the
the
absence
or
yeah.
Something
is
weird
here
and
the
sdf
model
really
should
be
about
the
physical
side.
I'm
sorry,
if
I'm
repeating
myself
and
the
digital
side
should
be
described
if
it's
really
common.
A
So,
for
instance,
if
we
had
an
sdf
model
for
standard
definition,
tv
we
could
say
the
the
scale
minimum
is
excuse
me.
The
minimum
is
that
the
digital
minimum
is
16
and
the
digital
maximum
is
239
and-
and
everybody
would
agree
on
that,
because
that's
a
common
characteristic
of
all
senator
definition,
tv
formats,
but
in
in
many
cases
that's
not
the
case.
There
is
no
single
standard,
digital
representation
of
of
temperature
reading
so
that
that
doesn't
make
sense
on
in
the
converged
the
model.
A
So
normally
we
will
leave
the
digital
side
to
the
mapping
file
to
the
protocol
binding.
So
this
picture
is
is
wrong.
It
hurts
when
you
start
putting
together
mapping,
information
and
and
information
from
the
conversion
model.
Next
slide,
please
so
just
to
give
an
example.
If
we
have
a
temperature
sensor
that
goes
from
minus
50
to
plus
150
degrees
celsius,
then
maybe,
oh,
the
text
is
wrong.
A
So
then,
maybe
if
the
sensor
actually
has
one
more
digital
one,
more
digit
after
the
the
floating
point,
comma
right,
it
says
centicare
and
then
should
should
say
deci
carrots,
then
the
digital
number
might
go
from
-500
to
plus
1500
or
might
be
offset
from
that.
But
this
is
just
just
the
example.
A
A
So
the
the
digital
numbers
really
should
be
supplied
by
the
mapping
info.
So
you
would
yeah
it's
just
difficult
to
to
get
all
the
the
cases
right
and
really.
The
question
is
which
side
the
digital
or
the
physical
side
gets.
The
json
schema
org
keywords,
minimum
and
maximum
next
slide.
A
So
we
looked
a
little
bit
through
the
the
playground
and,
as
I
said,
there
is
currently
no
scale
minimum
scale
maximum
in
there,
and
people
are
actually
using
minimum
maximum
for
the
physical
quantities,
so
in
particular
the
ocf
models
clearly
are
thinking
about
these
as
describing
the
the
physical
quantities.
A
So
we
didn't
complete
the
survey
for
all
200
something
models,
but
the
the
conclusion
from
a
survey
of
the
playground
was
people
are
already
using
minimum
maximum
for
the
physical
side.
So
the
the
perception
that
they
can
be
on
the
digital
side
actually
is
wrong.
A
There's
one
minor
issue
here,
which
is
that
the
json
schema
og
stuff
probably
wants
to
stay
within
the
range
of
things
are
that
are
I
json
you
don't
have
to
take
it
this
way,
but
people
with
people's
implementations
will
will
want
to
do
that,
but
actually
actually
754
has
been
designed
so
that
that
for
the
physical
quantities
we
care
about.
A
D
Carson
just
before
we
go
to
the
next
slide,
so
I
think
that
the
adjacent
schema
or
part
has
to
do
with,
for
instance,
if
you
are
trying
to
set
filters
or
other
kind
of
constraints,
you
now
have
to
set
them
on
the
physical
values
rather
than
the
digital
values.
Is
that
that
the
point.
A
Well,
the
the
the
point
is
that
people
have
been
using
them
for
the
physical
side
so
that
that's
what
we
find
in
in
models,
so
the
the
perception
that
they
are
actually
meant
for
the
digital
side
that
only
came
in
when
we
tried
adding
scale
minimum
scale
maximum
because
they
are
on
the
physical
side.
So
those
gaming
scale
max
are
trying
to
push
out
minimum
maximum
from
from
their
physical
position
into
the
digital
position
and
that
that's
the
dissonance
that
we
have
here
right.
Okay,
so
yeah!
Thank
you.
A
So
the
the
picture
that
I
think
we
should
have
for
1.1
is
having
a
big
hole
in
in
the
the
part
that
might
that's
marked,
yellow
here
or
orange,
and
the
the
things
that
are
defined
in
in
sdf
1.1
are
interpreted
as
as
being
on
the
physical
side
and
we
attack
the
whole
problem
of
digital
mappings
in
one
point:
next,
maybe
by
adding
digital
minimum
digital
maximum
or
scale
offset,
or
both
we
scale
offset,
are
defined
in
rfc8798.
A
So
sometimes
the
the
one
thing
is
the
right
thing.
Sometimes
the
other
thing
is
the
right
thing.
So
probably
we
will
add
both,
but
we
we
can
just
cuss
this
in
in
the
development
of
one
point
next,
so
that
that's
essentially
my
my
summary
slide
here
and
this
this
makes
clear
what
we
should
do.
A
If
you
just
jump
quickly
through
the
next
three
slides,
I
actually
created
some
some
slides
for
what
we
have
to
do
to
do
the
other
thing,
and
it's
not
something
I
want
to
do
before
1.1
and
if
you
go
back
to
slide
27.
A
F
Thanks
my
my
comment
was
that
in
thinking
through
this
a
little
bit
more
and
looking
at
some
of
the
examples,
I
think
we
have
more
discussion
to
do,
but
I
think
a
hint,
a
flavor
of
what
I'm
thinking
is
now
in
sdf.
We
have
this
description
of
the
physical
quantity,
so
that's
really
scale
minimum
and
scale
maximum.
I
mean
in
an
ideal
world.
F
I
think
what
we'd
have
would
be
not
not
even
confusing
things
again
with
the
json
schema,
because
we
we
pretty
much
have
a
bit
different
concept
on
on
both
ends.
We're
separating
that
the
number
and
in
an
actual
system
we
might
have
the
sdf
file
having,
let's
just
say,
quantity,
minimum
quantity,
maximum
and
then
the
protocol
binding
might
have
a
data
schema
element
that
would
have
json
schema,
minimum
and
maximum,
which
would
be
digital,
minimum
and
maximum.
F
But
if
I
want
to
use
it
in
a
jso
validator,
I'm
going
to
actually
have
to
feed
it,
the
string,
minimum
and
maximum.
So
at
some
point
it
gets
converted
into
that.
So
anyway,
that's
I
don't
really
want
to.
I
don't
really
have
a
conclusion
there.
It's
just
that!
Maybe
even
reusing
jso
for
the
physical
is.
Maybe
we
wouldn't
really
need
to
do
that
and
we
can
invent
some
new
terms
for
that,
but
I
think
that's
all
sdf.next.
C
B
Yeah
I
mean
I,
I
I
still
think
that
we
should
do
the
would
really
like
to
have
sdf
one
one
done
right
and
and
carsten
do
you
think
that
with
the
change
you're
proposing
or
when
you
and
michael
propose,
we
are
kind
of?
We
can
postpone
this
problem
on
the
sdf
one
next
and
then
everybody
can
be
happy
with
that.
B
B
We
can,
of
course,
do
a
poll
on
this,
but
it
seems
like
there
has
been
no
objections
so
far
making
this
complex.
I
don't
think
we
will
get
any
substantial
results
or
is
there
anyone
who
wants
to
object
to
to
just
folding
in
what
kirsten
originally
proposed
on
number
three
here
on
on
the
scale
max
min
and.
B
B
E
B
Good,
then,
I
think
we
are
okay
with
the
the
three
items
here
to
to
merge
those
with
o3
publish,
o4
and
then
o4
will
be
the
implementation
draft.
B
A
E
B
Great
thank
you,
but
then
I
think
we
are
done
with
this.
We
have
way
forward
for
sdf
one
one
and-
and
we
are
very
close
to
wrapping
it
up-
that's
really
good!
When
kirsten
and
michael,
when
do
you
think
you
can
have
a
04
under
when
you
think
we
can
implement
all
these
things
around
dish?
Well,.
B
Perfect,
thank
you
very
much.
Thank
you
for
doing
all
this
with
that.
The
next
thing
for
us
is
actually
to
discuss
where
we
go
next,
wasn't
there
one
thing
on
next?
B
We
can
take
the
next
entrance
later
wait
yeah,
so
we,
as
we
said
all
the
time
here
and
we
said
in
the
consensus,
call
for
one
one-
was
that
we
definitely
are
looking
to
add
new
features
to
and
sort
of
to
make
it
really
fully
baked
when
we
have
a
an
rfc
in
the
not
too
far
future,
and
as
part
of
that,
we
have
had
discussions
on
what
new
features
that
would
be
relevant
and
what
kind
of
issues-
and
I
think
we
just
came
up
with
this
discussion
on
the
info
block-
that
is
definitely
something
to
include
and
the
sdf
max
and
so
on.
B
It's
a
scale
max
gallium
scale
mean,
but
in
addition
to
that
there
were
a
number
of
things
that
we
had
discussions
on
last
week
in
the
that
have
been
cooking
a
bit
in
the
background
for
some
time,
and
so
what
we
have
here
that
we
go
through
today
are
basically
three
topics
that
should
be
probably
be
included
in
a
later
version
of
sdf
clarification
of
properties,
actions
and
events,
and
michael
will
talk
about.
Oh
sorry,
carson
we'll
talk
about
that.
B
We
will
say
if
you,
michael
cluster,
will
say
if
he
was
about
mapping
files
and
then
we
have
a
compact
format,
which
is
another
representation
of
sdf.
With
that,
I
think
we
can
continue.
We
have
over
an
hour
left,
but
maybe
I
mean,
since
we
have
a
bunch
of
slides,
save
some
time
at
the
end
for
actually,
I
think
we
should
take
discussions
after
each
topic
for
a
limited
amount
of
time.
B
So,
let's
get
going,
I
think,
and
then
maybe
we
should
discuss
the
virtual
bin
actual
the
very
end
of
our
meeting
here.
So
I
will
yeah
as
we
get
close
to
the
end.
We
will
get
back
to
talking
about
when
we
will
have
our
next
interview.
A
Right,
thank
you
so,
as
as
I
said,
we
had
a
lot
of
discussions
in
in
the
last
two
weeks,
starting
from
from
the
hackathon,
and
I
would
like
to
go
through
two
issues
here.
Next
slide,
please
two
areas
of
development:
these
are
not
issues.
These
are
just
things.
A
We
need
to
keep
in
mind
that
we
need
some
active
attention
on
on
them,
both
in
in
the
way
that
that
we
we
interpret
what
we
have
in
in
1.1
and
in
the
way
that
we
further
develop
this
in
in
one
point
next,
so
this
is
not
about
any
further
text
changes.
This
is
about
understanding
what
we
have
and
and
developing
from
from
there.
So
we
already
talked
about
data
items
versus
physical
quantities.
I
don't
have
to
repeat
that.
So
let
me
just
talk
about
number
one.
The
properties
actions.
A
Events
next
slide,
please
so
the
the
summary
information-
and
it's
really
the
whole
thing
in
one
slide.
You
don't
really
need
to
know
much
more
about
them.
A
Is
that
that
the
property
is
is
an
affordance
that
has,
if
writeable,
the
ability
to
put
in
a
data
value
and
if
readable
and
observable,
has
the
ability
to
obtain
to
obtain
a
data
value
and
the
the
types
for
putting
in
things
and
for
for
pulling
out
things
are
the
same
well
at
least
right
now
they
are,
I
think
we
all
have
experienced
the
the
situation
where
we
actually
would
have
wanted
to
to
have
a
different
type
on
a
put
than
on
a
get,
because
there
is
some
information
in
the
structure
that
actually
is
only
readable
and
and
only
parts
are
written
and
that's
maybe
something
we
need
to
look
at
in
in
the
next
version.
A
But
that's
fundamentally
what
a
property
is
so
how
this
reading
and
writing
is
done,
whether
that's
done
in
a
rest
protocol
or
in
a
message,
queue
and
so
on.
That's
not
really
the
the
the
interesting
thing.
The
interesting
thing
is:
we
have
a
state
that
is
associated
with
that,
a
property
that
typically
maps
to
a
physical
state
in
in
some
form
and
that
that
is
writable
and
or
readable,
and
we
have
these
three
bits.
The
I
call
them
rwo
bits
that
we
can
use
to
say
what
what
exactly
we
have
here.
A
So
some
people
think
about
this
as
an
rpc
that
that's
certainly
an
abstraction
that
that
comes
to
mind,
but
I
think
it's
a
little
bit
different
from
an
rpc,
but
that's
a
detail.
We
maybe
don't
have
to
discuss
today,
but
in
in
any
case
it's
not
a
state
that
that
you,
for
instance,
can
cache
in
in
a
proxy
cache
or
that
that
you
you
would
want
to
would
want
a
broker
to
supply
as
a
last
wish
element
or
something
like
that,
it's
really
something
you
can
do
so.
A
A
It's
no
longer
something
that
that's
in
there
and
the
third
thing
we
have
is
the
event
and
that's
interesting,
because
it's
something
that
that
puts
out
data
of
a
certain
type-
and
it
actually
is
not
that
much
different
from
a
property,
except
that
we
we
don't
say
whether
getting
that
object
needs
to
be
solicited,
which
would
be
the
readable
part
of
a
property
or
actually
is
autonomously
decided
by
the
the
thing
just
send
something
which
would
be
the
observable
bit.
So
that's
just
not
defined
about
events.
A
The
only
thing
we
have
defined
about
events
so
far
is
that
they
throw
some
data
at
you
and
that's
not
different
from
from
a
poverty.
So
that's
the
the
underlying
observation
next
slide
and
the
the
problem
that
the
industry
has
is
that
there
are
very
different
concepts
that
are
typically
meshed
together
under
events.
A
So
if,
if
you
think
about
events
in
in
the
way,
xmpp
or
mqtt
or
whatever
would
think
about
messages,
that's
certainly
one
way
to
think
about
it,
but
but
going
a
step
away
from
the
protocol.
A
If
you
look
at
the
physical
example
of
a
doorbell,
that's
actually
the
main
affordance
of
adobe
is
an
event.
A
A
So
that's
one
example
and
another
example
for
an
event:
that's
not
yeah!
That's
a
little
bit
more
on
on
the
business
side,
but
but
it's
still
quite
pertinent
is
a
sale.
A
So
sale
is
another
event
that
comes
with
data
for
sale.
You
want
to
know
where
to
ship
that
thing
and
and
how
many
of
them
and
and
so
on,
but
the
important
aspect
about
this
event
is
that
it
must
not
be
lost
so
some
other
properties.
If
a
temperature
sensor
give
you
some
readings
and-
and
you
are
missing
one-
that's
not
a
big
problem.
If
you
get
the
next
one
soon,
but
a
sale
is
is
important
on
its
own
and
it
comes
with
data
that
are
only
about
that
specific
event.
A
So
the
next
event
you
get
is
not
going
to
repeat
anything
about
the
previous
sale.
It's
it's
just
a
completely
new
event,
so
I
think
we
should
focus
our
discussion
on
on
events
on
what
I'm
calling
a
genuine
event
here
and
we
probably
have
to
to
evolve
some
terminology.
A
There's
nothing
wrong
with
with
1.1
as
it
is.
It
just
doesn't
tell
you
what
kind
of
event
we
expect
to
to
describe
with
the
sdf
event
afford
next
slide,
and
and
just
to
contrast
that
non-events,
so
so
things
that
are
really
more
on
the
property
side
are,
for
instance,
a
temperature
sensor
with
a
threshold
alarm.
A
So
the
temperature
sensor
has
a
current
value
and
that
can
be
red
and-
and
it
also
has
a
notification
function.
So
if
a
threshold
is
crossed,
you
get
a
notification
and
that's
exactly
what
the
the
r
and
o
bits
of
a
property
do.
So
it's
not
an
event
in
the
sense
of
an
sdf
event.
It's
certainly
an
event
in
the
sense
of
the
english
language,
meaning
off
of
event.
A
Now
the
the
interesting
thing
where,
where
we
have
a
crossover
here,
is
that
there
are
some
properties
that
actually
need
to
have
a
history
about
state
changes.
A
So
you
may
have
a
legal
obligation
to
record
the
the
instances
where
the
temperature
sensor
crossed
the
threshered
and
we
need
to
model
that,
and
that's
really
something
that
that
we
should
take
up
as
as
a
an
item
for
the
one.next
activity.
I
think
that
that's
a
problem
that's
solved
very
well
in
in
no
of
the
existing
environments
and
we
might
have
a
chance
to
actually
model
this
properly
next
slide.
A
A
Okay,
thank
you.
The
the
problem
here
is
that
some
of
us
are
pretty
yeah
imprinted
by
co-app
and
when
we
read
the
word
word
observe
we
think
about
a
get
request
with
an
observe
option,
but
that's
not
what
is
meant
here
by
observable,
so
the
the
observable
bit
does
not
imply
readable.
A
It
just
means
that
property
is,
is
going
to
send
you.
You,
notifications
and
yeah.
The
the
the
perception
that
that
observe
implies
readable
is
not
what's
in
the
document,
so
there's
no
need
for
a
change
here,
it's
already
in
there,
but
you
have
to
read
it
properly.
A
So,
given
that
three,
these
three
bits
are
independent.
This
means
that
actually,
a
a
property
that
is
dash,
dash,
o
or
or
no
read
no
right
but
observe,
is
possible.
It's
observable,
but
not
readable,
and
in
the
discussion
we
have
had
the
term
notifiable.
A
I
don't
know
if
we
need
another
term
here
or
not,
let's
find
that
out.
But
the
point
is
that
that
dash
dash
0
already
has
been
part
of
sdf
all
the
time
we
we
just
seem
to
have
forgotten
that
a
little
bit
so
many
of
the
pub
sub
style
affordances
actually
are
sdf
properties
in
in
that
sense,
so
we
can
model
this
today.
Next
slide.
A
Yeah,
and-
and
that
means
the
the
sdf
event
should
not
be
used
where
we
have
observed
an
observable
property
and
the
one
dot
next
work
is
about
preciousness
and
securing
issues
overload.
E
A
B
A
You
yeah.
We
have
some
interesting
dos
issues
right
now
here,
I'm
running
into
those
about
once
a
day:
okay,
okay,
30
seconds
back.
Can
you
go
back?
One
slide.
D
A
Thanks,
thank
you
yeah,
so
just
this
is
essentially
just
a
repetition
of
what
what
I
said,
but
but
distilled
to
a
program.
So
given
that
an
event
is
essentially
defined
with
the
same
signature
as
an
observable
property,
we
should
try
to
understand
when
an
event
is
a
genuine
event
and
when
it's
an
observer
property-
and
we
should
not
describe
events,
I
can
share
my
slides
if
that
helps.
B
Michael
is
reloading,
so
he
will
be
back
in
a
second
here.
So
okay
yeah
keep
talking
then
yeah.
A
So
the
we
have
a
program
of
work
for
the
wonder
next
cycle,
where
we
are
going
to
discuss
this
whole
aspect
of
preciousness
and
and
of
cueing
issues
overload.
So
not
all
of
that
needs
to
be
in
the
data
model,
but
I
think
it
would
be
good
to
be
able
to
identify
in
a
data
model
whether
events
are
kind
of
overtaken
by
new
events
or
whether
events
really
need
to
be
preserved
one
by
one.
A
So
the
the
sdf
action
actually
is
looks
fine.
A
Maybe
it
looks
fine
because
we
haven't
done
a
lot
of
pressure
testing
on
it,
yet
so
that
that's
also
something
we
should
do
in
in
the
next
round
and
make
sure
that
the
sdf
action
is
working
well
for
us.
A
A
So
when,
when
you
start
making
a
coffee,
maybe
you
have
an
affordance
to
to
stop
making
that
coffee,
but
it
doesn't
mean
that
you,
you
have
to
shut
down
the
machine
or
something
that
just
means
stop
making
that
coffee
and
another
guy
who
also
wants
to
make
a
coffee.
A
You
still
get
to
make
their
coffee,
so
this
is
typically
modeled
by
dynamic
affordances,
and
you
can
actually
see
an
attempt
to
approach
the
issue
of
dynamic
references
in
the
acaf
document
where
we
are
discussing
the
permissions
on
dynamic
affordances,
and
I
think
that
that
might
be
food
for
thought.
It's
not
solving
our
problem
here,
but
it
might
be
food
for
thought
how
to
handle
these
dynamic,
affordances
but
ignoring
dynamic
references.
I
think
no
clarifications
are
currently
required
and
we
are
fine
until
we
add
functionality
here.
D
A
So
so
you
would
get
the
an
sdf
event
that
tells
you
about
the
progress
or
an
sdf
property.
That
talks
tells
you
about
the
the
progress
that
progress
property
goes
away
when
you
are
done
when
my
coffee
is
done,
yeah,
okay,
now
the
the
example
is
not
so
great.
Actually
because
in
a
real
coffee
machine
you
cannot
start
parallel
instances
of
making
coffee,
so
I
probably
have
to
come
up
with
a
new
example.
H
The
example
we've
seen
is
cancelable
actions,
so
suppose
you
start
making
a
coffee.
You
want
to
cancel
it.
You
might
have
an
additional
set
of
interactions
on
that
action
to
cancel
it
and
on
some
devices,
not
a
coffee
machine.
You
could
have
several
parallel
actions
going
at
once.
You
need
to
figure
out
which
action
you're
talking
about
so
one
thing
we've
played
with
is
returning
a
new.
You
know
thing
description
in
what
so
you
could
imagine
having
a
new
sdf
description
just
for
that
action
and
then
somehow
you
know
dealing
with
that.
A
A
A
B
Yep,
thank
you
very
much
kirsten.
Let's,
let's
stop
here
for
a
minute
and
and
see
if
there
are
any
further
questions
on
this.
I
think
this
was
an
interesting
sort
of
exposition,
as
I
gather
from
it.
I
don't
think
there
is
any.
What
we
have
today
in
sdf
1011
is
is
underspecified
if
anything
and
not
very
sort
of
feature-rich
functionality-wise,
but
it's
not
broken,
so
we
don't
have
to
remove
it
right
away.
I
think
that
would
be
the
key
thing
here.
B
E
H
A
F
Yeah,
I
would
probably
have
just
said
the
same
thing
and
adding
that
subscribing
and
unsubscribing
might
since
they're,
not
really
part
of
the
application
workflow
in
terms
of
you
know,
responses
and
things
like
that
they
might
belong
in
a
protocol
binding
as
well.
So
there's
some,
I
think,
there's
some
interesting
discussion
around
that.
B
So
basically
maybe
you
have
a
quality
of
being
cancelable
or
something
like
that,
and
then
you
have.
I
mean
you
can
cast
on
a
coffee
machine,
but
you
can't
cancel
a
if
you
fire
the
missile.
Then
you
fire
the
missile
right,
so
different
actions
can
be.
Maybe
that's.
F
Done
the
subscription
is
a
thing
that
is
is
really
part
of
the
mechanism
for
for
getting
data,
so
it's
sort
of
like
canceling
and
observe.
Well,
you
know
we
don't
really
provide
for
that
as
part
of
the
data
model,
and
I
think
it's
there's
more
discussion
to
be
had,
though
I
it's
not
a
conclusion
on
my
part
at
all.
B
No
but
good,
but
thank
you
for
this
anyway,
any
other
questions.
B
B
F
Michael
koster,
please
go
ahead.
Okay,
good,
please
advance
to
the
first
okay.
So
the
problem
we're
trying
to
solve
here
is
that.
Well,
if
sdf
definitions
are
protocol
neutral,
you
know
they.
F
We
want
to
be
able
to
map
them
to
different
protocols
and
storage
schemes,
and-
and
what
have
you
you
know
so
the
best
practice
for
in
1dm
anyway
is
going
to
be
to
leave
it
up
to
the
implementation
to
decide
a
lot
of
things,
so
these
models
can
be
retargeted
to
different
stacks
and
what
have
you
without
without
overriding
things
or
breaking
things,
so
you
can
have
some
sort
of
syntactic
interoperability
between
elements
that
conform
to
the
same
set
of
bindings
and
then
semantic
interoperability
where
you
have
a
bridge
or
a
some
kind
of
gateway
or
other
kind
of
adaptation
across
these
ecosystems.
F
F
So
basically,
it's
a
mapping.
File
itself
is
external
information
that
augments
the
the
model.
Essentially
it's.
These
are
extensions
to
sdf
or
additional
pieces
of
sdf
that
get
added
on
to
further
customize
a
model.
So
the
kind
of
things
we
do,
our
ad
quality
is
like
defined
minimum
maximum
and
multiple.
F
We
change
abstract
number
to
a
type
number
like
we
have
say
this
has
to
be
a
float,
for
example,
reserving
space
it
turns
out
that
you
know
we
have
enough
pack
representations
is,
can
that
all
be
handled
in
the
binding,
or
is
that
part
of
a
data
type,
augmentation
or
constraint
that
we
need
to
add
so
that
the
application
can
can
unpack
things
at
the
application
layer?
And
sometimes
that's
what
happens?
F
I
found
that
out
with
modbus,
for
example,
so
we
also
want
to
be
able
to
have
a
big
enum
that
defines
all
the
fan
modes.
You
might
ever
want
in
a
fan,
but
this
fan
only
has
three
modes,
and
so
we
need
to.
We
have
a
way
to
say
that
defaults
for
values,
constants
for
values
that
are
left
open,
new
qualities
like
id
codes
that
are
shorthand
in
protocols
to
to
reduce
the
amount
of
space.
The
information
takes
up
in
the
protocol
custom
settings
for
things,
new
protocol
binding
or
protocol
binding
settings.
F
So
what
protocol
does
it
use
and
what?
What
parts
of
the
protocol
and
how
does
it
use
them
protocol
bindings?
And
then
we
might
want
to
override
things
and
obviously
with
if
you
make
your
model
saying
these
are
defaults,
you're
allowing
for
overriding
in
the
future,
but
also
we
might
be
able
to
say
you
know
this
is
an
integer
in
the
model,
but
I
want
to
overwrite
it
to
a
float.
F
Some
of
these
things
hurt
interoperability,
so
we
have
to
be
careful
about
the
overrides
and
there
are
other
things
you
could.
You
might
want
to
do
to
models
that
aren't
really
considered
here,
having
to
do
with
composition
and
stuff
that
I'll
I'll
talk
about
a
little
later
next
slide,
please
so
the
processing
model,
as
I
see
it
now.
This
is
where
we
sort
of
get
into
what's
the
proposal
and
what's
sort
of
being
worked
out,
is
that
there's
mapping
information
for
each
sdf
element?
F
So
be
it
a
thing,
an
object,
each
event,
each
action,
property
data,
and
even
each
each
category
instance
in
an
enum
each
enum
value
could
have
mapping.
So
I
have
if
I
have
an
enum,
for
you
know
up
down
and
center,
I
might
make
those
zero
one
and
two
and
one
ecosystem
and
it
might
have
strings
in
another.
So
so
those
need
to
be
mapped.
One
of
the
big
sorry
sdf
choice.
F
Oh
yeah,
we
used
to
call
it
spf
enum,
but
it's
called
sdf
choice.
Basically,
those
mapping
elements
should
be
processed
as
if
the
source
file
had
them.
You
know
right
there
in
line
and
in
fact,
some
of
the
work
I'm
doing
is
sort
of,
but
if
you
did
have
them
as
inline
extensions
that
you
could
easily
split
out
to
mapping
files
and
compose
back
in
also,
I
think
a
concept
is
that
there
could
be
extension
schemas,
basically,
a
validation
of
the
extension
as
as
an
extension
that
gets
validated
by
a
schema.
F
It's
really
easy,
if
you're
putting
in
a
new
block,
but
if
you're
just
adding
qualities
it's
harder
to
see
how
that
might
work,
but
it
seems
like
a
reasonable
direction,
also,
the
extension
vocabularies
and
what
you
do
with
extensions
and
and
in
mapping
files
should
be
able
to
use
what
we've
already
designed
in
sdf.
So
sdf
ref
required
concepts
like
that.
They
should
be.
You
know,
for
the
most
part,
be
sdf
files
also,
but
with
with
some
other
other
kinds
of
behaviors.
F
F
F
You
want
to
put
things
and
then
the
values
you
want
to
put
there
selectors,
currently
are
json
pointer
that
we
use,
so
it
should
be
the
same
as
you
use
with
sdf
required
or
sdf
ref
for
that
matter,
including
the
namespace,
so
you
should
be
able
to
in
your
mapping
files
say
these
are
my
namespaces
and
and
use
the
curie
format
for
that
as
an
example,
if
you
wanted
to
take
the
ipso
sensor,
value
and
target
it
to
ipso,
which
was
was
taken
out
in
the
model,
you
would
say
this
is
an
id
5700
and
it's
a
float
type
and
you
might
be
some
more
things
you
want
to
say
about
it,
but
that's
a
simple
example:
so
a
mapping
file
and
there
might
be
more
than
one
mapping
file,
there
might
be
one
mapping
file
that
adds
ids
and
another
one
that
adds
protocol
bindings
and
another
one
that
composes
things.
F
So
it
might
not
be
just
one
mapping
file
at
a
time.
Also
right
next
slide,
please
so
you
know
there
are
different
ways
to
do
it.
Obviously,
you
could
say
that
instead
of
a
map,
it's
an
array
of
objects
where
the
selector
is
an
element
in
each
object
and
process
them
in
array
order,
and
there
may
be
some
advantages
for
doing
that.
F
I
also
looked
at
some
design
patterns
that
were
looked
more
like
json,
merge
patch,
where
you
have
sort
of
a
template,
that
sort
of
mirrors
the
structure
of
the
thing
you're
patching
and-
and
you
plug
things
in
like
as
if
you
were
patching
a
json
and
that's
that's
it
sort
of
would
work,
but
the
there.
This
piles
look,
sort
of
sparsely
and
spacey
and
and
indenty,
and
it's
not
really
any
easier
to
read
than
a
mapping
file
of
the
other
form,
but
it's
also
a
possibility.
F
Also,
the
selectors
could
be
some
other
kind
of
thing
like
jsonpath,
so
you
could
say
if
I
don't
really
have
a
json
pointer
for
everything
I
want
to
build
a
mapping
file.
That's
a
little
more
generic
and-
and
you
know,
adds-
adds
things
or
collects.
Node
sets
from
the
from
the
sdf
file
to
annotate,
based
on
a
json
path.
Query,
so
that
could
be
happening.
F
Also,
as
I
mentioned
earlier,
beyond
just
augmentation
and
overriding
and
adding
qualities,
there
might
be
other
operations
we
want
to
do.
I
I
haven't
run
across
any
specific
examples,
but
people
talk
about
things
next
slide,
please
so
yeah
one
one
alternative
implementation
that
I
have
played
with
is
using
an
sdf
thing
as
the
mapping
file.
So
essentially,
what
this
is
is
an
sdf
thing,
definition
that
uses
sdf
ref
to
pull
in
a
bunch
of
objects,
and
it
also
has
the
extensions
in
line.
F
So
essentially,
I
want
to
aggregate
a
bunch
of
objects
and
stuff,
and
I
want
to
maybe
define
some
new
data
type
constraints
and
new
data
elements
to
use
to
reuse,
and
then
I
want
to
customize
everything
and
just
say:
well,
here's
my
here's,
my
thing:
here's
my
power
supply,
it
measures
voltage
and
current
and
it
has
some
settings
and
it
has
some
alarm
events
and
it's
all
described
in
one
in
one
place
and
that
tends
to
have
worked
out
pretty
good
for
for
small
things
at
least
and
of
course,
larger
things
you
you
might
want
to
break
them
up
still
into
multiple
files,
but
it
looks
like
a
good
pattern,
a
good
authoring
format
if
you're
just
sitting
down
and
writing
stuff
and
not
just
machine
generating
everything.
F
I
Michael
thanks
and
I
have
a
question
I'm
trying
to
to
figure
out
from
your
talk.
Let's
say
that
I
wanted
to
have
the
semantic
definition
of
binary
data
types
on
the
wire,
but
for
sensors,
using
a
binary
description.
Let's
say
five
bits
for
temperature
and
11
bits
four
times
so
so
not
buying
byte
align
but
binary
random
byte
number
of
bits.
Sorry
used
for
four
different
things.
How
do
you
picture
this?
This
mapping
being
worked
out.
F
For
the
types
we
have
a
few
examples
of
the
raw
models
that
do
that,
and
essentially
it's
easy
enough
to
say
a
packed
thing-
is
sort
of
an
array
with
unique
items
and
and
when
you
do
that,
you
can
then
size
each
item
by
using
a
numeric
range
or
string
constraints
so
that
they
fit
in
the
in
the
in
the
elements
you
want
to
pack
them
in.
So
that's
probably
the
first
thing
that
needs
to
be
done.
F
If
this
thing
is
for
packed
use,
then
you
might
want
to
define
it
as
having
a
range
of
only
zero
to
three,
for
example,
if
you're
using
two
bits,
so
the
the
bare
model
is,
is
already
covered.
The
way
the
mapping
is
done
is
kind
of
up
to
the
protocol
that
you're
mapping
to
so
this
is.
This
is
really
one
of
the
challenges
so
where
we
have
this
in
bluetooth
now
I
think
the
example.
F
What
we
have
is
a
an
additional
quality.
I
don't
believe
it's
in
the
vocabulary
anymore,
because
we,
we
didn't
really
have
it
fully
defined,
but
it
is
within
bits,
and
so
you
can
construct
an
array
of
these
items
in
the
binding,
and
you
can
say
the
width
and
bits
of
this.
One
within
bits
is
two:
this
one
within
bits
is
five,
and
this
within
bits
is
one
and
then
you
can
put
them
in
an
array
and
pretty
much
describes
the
full
the
full
packing,
and
I
don't
have
an
example
of
the
array
binding.
F
Data
so
that
it
fits
in
the
elements
you're
packing
it
into,
and
then
you
can
define
the
width
of
each
element
in
in
an
array
in
the
in
the
data
schema
part
of
the
binding
that
describes
what
goes
on
the
wire.
That
way,
if
you
decide
well,
this
is
just
I
want
to
expose
it
as
a
json
in
my
web
service
and
each
one
is
just
a
json
number
string
or
boolean,
then
you
can
always
map
it.
That
way,
and
and
and
the
system
will
know
how
to
how
to
repack
it
and
unpack
it.
F
F
I
think
we're
about
done
yeah
next
step,
so
we
have
to
figure
out
how
the
extension
schemas
would
work
and
and
how
we
actually
create
extensions
to
sdfs.
That
can
still
be
validated.
I
think
that's
a
good,
a
good
direction
to
try
to
pursue.
If
that
makes
sense,
we
need
to
really
do
some
broad
review
and
pressure
test
of
this.
So
where
we've
already
done
model
conversion,
we
need
to
look
at
where
people
would
incorporate
instance,
bindings
and
mapping
files,
and
these
extensions,
for
you
know
what
did
the
ocf
ones
look
like?
F
What
are
the
zigbee
ones?
Look
like,
for
example,
and
then
we
need
to
formalize
the
design
patterns
once
we
sort
of
figure
out
a
set
of
things
that
we
want
to
do
and
then
really
for
sdf.
Next,
we
could
introduce
a
couple
of
concepts
like
these
extension
schemas
and
maybe
formats
for
mapping
files
and
then
maybe
some
processing
model
definitions
as
well,
and
it
occurred
to
me
that
at
some
point
we
might
start
looking
at
making
separate
traps
for
some
of
this
stuff
as
well
like
we
did
with
coap.
F
I
don't
know
how
good
how
well
it
really
worked
out
with
co-op
to
have
observed,
be
a
separate
draft,
but
some
of
these,
like
mapping
files,
might
might
be
a
separate
draft,
just
a
question
that
occurred
to
me.
I
don't
know
if
it's
a
good
idea
or
not
right
next
slide.
I
think
we're
about
to
the
end
yeah.
Oh,
oh
yeah,
so
value
scaling.
F
We
talked
about
this
enough
already,
but
my
point
on
value
scaling
is
probably
most
of
that
is
going
to
be
done
at
one
time
so
carson
and
you
know
we
talked
about
layers
and
how
you
might
want
some
constraints
at
one
and
then
layer
on
more
constraints
when
you
do
another
thing,
but
for
the
value
scaling
it,
at
least
in
my
examples,
it's
worked
out
pretty
well
to
say:
well,
here's
my
basic
model.
It
has
a
number
that
represents
voltage
grade.
F
Here's
my
protocol
binding
the
voltage
is
between
0
and
30
in
increments
of
0.01,
and
it
has
a
digital
representation
of
of
an
integer
between
0
and
3
000,
and
it
has
a
you
know:
a
quantity
representation
of
0
to
30.00,
and
I
can
describe
all
of
that
in
the
binding
as
an
extension.
So
we
don't
really
need
you
know
sdf
to
to
fix
that
right
away.
E
B
Thank
you
michael
also,
very
interesting
stuff,
and
I
think,
having
worked
with
these
translation
bits,
I
think
it's
a
it's
a
good
good
part
to
try
to
align
a
bit
on
and
work
with,
because
there's
a
lot
of
hidden
stuff
here
that
makes
things
what
sounds
easy
turns
out
to
be
pretty
complicated
to
map
well,
but
very
good.
I,
as
we
said
in
the
chat.
I
think
it
also
makes
sense
to
have
this
as
a
separate
specification
from
the
sdf
spec
carson
yeah.
A
I
think
that
this
was
a
very
good
talk,
and
this
really
leads
to
the
the
question:
when
do
we?
How
do
we
pursue
this
kind
of
work?
And
I
think
this
would
be
a
good
time
to
actually
talk
about
the
next
virtual
interims,
because
I
I
really
wouldn't
want
this
to
sit
by
the
wayside
for
another
month
before
we
start
continuing
work
on
it.
B
The
compact
stuff
can
can
can
stick
at
the
end.
So
what
I
mean
one
of
the
things
here
going
into
the
mapping
files
is
that
I
think
we
need
to
have
good
understanding
of
the
requirements
what
the
various
ecosystems
want.
Basically
I
mean
you
had
example
with
ipso
here
and
the
mapping
to
numeric
ids.
We
have
router
and
the
meeting
here
as
well
so
mapping
to
ocf
and
so
on,
but
maybe
it
would
be
really
good
to
have
so
that
would
say
what
what
we
define
here
is
actually
maps
well
too.
B
D
So,
to
my
mind,
there's
there's
three
things
here:
that
we
need
to
figure
out
what
what
bit
of
fdf
next
do.
We
need
to
clarify
before
we
can
get,
we
can
deal
with
mappings
and
what
is
the
work
to
generate
to
to
build
this
mapping
specification
and
then
what
are
the
sample
example
mappings
there
and
it
sounds
like
we
need
to
do
some
of
this
work
before
we
can
have
a
virtual
interim
to
reasonably
discuss
it.
But
on
the
other
hand,
we
we
don't.
D
E
F
Michael
cluster
yeah
yeah,
one
quick
comment
that
in
in
my
work
and
examples
using
the
web
of
things,
thing
description
it.
It
could
be
as
simple
as
just
providing
the
data
schema
element
and
forms
element
from
thing
description,
because
thing
description
already
has
a
well-structured
protocol
binding.
So
I
kind
of
took
the
easy
way
out
there,
but
also
it's
a
good
good
starting
point
for
something
like
ocf.
F
You
probably
want
to
be
able
to
introduce
swagger
files
and
point
things
to
you
know
open
api
files,
so
I
think
nicholas
what
you
just
said
is
sorry,
but
what
michael
just
said
is
that
those
three
stages
yeah?
We
need
to
figure
out.
What
are
the
differences
between?
You
know
the
different
templates
that
we
use
for
the
mapping
and
then
really
what's
the
commonality?
What's
the
is
it?
F
Is
it
really
just
an
extension
mechanism
that
you
can
pass
arbitrary
stuff
through
that
we
that
we
don't
really
define
in
our
own
ontology,
or
is
there
going
to
be
some
kind
of
common
ontology
of
things
that
work
for
all
protocol
bindings?
And
I
don't
think
we
really
have
a
totally
clear
feeling
about
that.
Yet,
but
web
of
things
each
protocol
binding,
is
a
whole
separate
vocabulary
with
its
own
ontology
and
they're
all
already
developing
them.
So
again,
it's
an
easy
way.
It's
an
easy
way
out.
F
B
So
I
I
think
we
should
start
with
putting
together
some
reasonably
simple
examples
of
moving
from.
I
mean
what
is
so
so
we
don't
need
to
expand,
so
we
can
basically
use
sdf11
as
it
is,
and
don't
have
to
do
finish
sdf
next,
before
we
sort
of
find
the
last
things,
but
we
so
simple
example
using
gas
properties,
for
instance,
and
then
try
that
out
and
then
build
on
that.
B
So
maybe
actually
doing
some
kind
of
more
hackathon-oriented
meeting
would
be
make
a
lot
of
sense
here
from
the
perspective
of
people.
Try
this
out
and
and
and
sort
of
can
compare
notes
before
you
continue.
B
B
But
so
then,
the
question
of
becomes
that
right.
How
do
we?
How
do
we
should
we
just
because,
obviously,
the
mapping
files
is
an
er
to
make
sdf
useful
for
your
ecosystem?
You
really
need
to
have
this
in
place,
so
I
guess
we
need
to.
C
B
That
translates
to
week
of
april
12th.
C
Anyway,
so.
C
D
Say
that
he
didn't
want
to
leave
it
a
month,
and
that
is
a
month
from
now
so
so
I
thought
that
he
was
trying
to
go
for
for
this
week
here.
D
D
All
right,
so,
let's,
let's
put
up
a
so
you're
talking
about
like
two
or
three
calls
you
know
half
hour
calls
during
that
week.
Is
that
what
you're
talking
about?
What
is
that?
What
you
mean
by.
A
Now
week,
13
is
a
little
bit
difficult
because
it
has
the
easter
early
days
in
it.
B
B
The
eighth:
let's,
let's
do,
let's
do,
let's
do
a
doodle
for
that
right,
so
people
can't
they
can't
check
it
out,
but
we
have
directions:
okay,
yeah
all
right
and
then
do
we
need
to
do
so.
One
of
the
good
things,
perhaps
is
if,
if
because
michael
koster,
you
had
a
lot
of
sort.
E
B
Already
thought
a
bit
quite
a
bit
about
this.
If
you
want
to
throw
out
some
kind
of
straw,
man
proposal
or
putting
together
what
has
been
done
so
far,
I
mean
get
very
rough
or
we
can
or
maybe
take
some
dislikes
or
something,
and
then
we
can
have
that
as
a
starting
point
for
the
further
discussion.
F
Yeah
I
can,
I
can
wrap
up
what
I've
done.
I
don't
know
if
I'm
ready
to
start
an
internet
draft
yet,
but
that's
when.
F
How
I
would
wrap
this
up?
That's
when
I
thought
about
an
internet
draft.
So
if
I
get
really
crazy,
but
I
think
yeah,
the
next
step
would
be
to
sort
of
make
a
make
a
little
bit
more
of
a
document
out
of
what
we
have
and
also
look
at
what
other
people
have
done.
Other
folks
have
worked
on
the
mapping
files
and
have
things
to
contribute
that
I
have
it
wasn't
able
to
roll
up
into
my
talk
today.
But
for
for
this
I
would
do
that
also.
B
Great
thank
you.
Then.
We
have
both
the
way
forward
on
this
and
the
way
forward
on
meeting
time
and
we'll
have
the
topic
for
the
next
meeting
great
and
there
will
be
doodle
sent
out
soon
each
regards
to
next
week.
In
regards
to
this,
the
upcoming
interim
great
any
other
questions
on
this.
B
We
have
now
20
minutes
left
to
the
meeting.
We
have
only
one
at
the
end
of
point
left,
which
is
the
compact
format,
but
anything
any
final
thoughts
and
stuff
on
the
and
the
mapping.
If
not,
then
we
yeah
there's
a
bit
of
discussion
on
on
the
may
on
the
chat
there
as
well.
B
G
Yeah,
maybe
one
interesting
potential
aspect
for
the
mapping
that
we
haven't
really
discussed
yet
is
being
able
to
express
more
relationship
between
objects
and
and
things
so
right
now
we
have
only
the
hierarchical
way
of
expressing
that
object
is
part
of
the
thing,
but
if
you
want
to
say
hey
how
this
is
how
these
two
things
or
two
objects
relate
to
each
other.
That
could
also
be
something
that
we
could
be
experimenting
in
the
in
the
mapping
file.
B
Yeah
very
good
point,
even
though
I
is
that
really
a
mapping
file
pro.
I
think
that
feels
like
a
core
sdf
problem,
but
I
mean
obviously
with
the
implications
of
the
mapping
file,
but
I
think
that
the
much
of
this
happens
in
the
in
the
core
bit
michael
koster,.
F
B
Oh
yeah
yeah,
absolutely
absolutely
yeah.
There
were
some
pointers
to
crosslinks,
call
down
links
and
relationships
and
stuff.
So,
and
I
guess
we
can
look
at
other
modeling
languages
and
environments
to
get
even
further,
even
additional,
even
more
stuff
in
that
space.
B
A
Yeah,
thank
you.
I
wanted
to
have
this
at
the
end,
because
it's
really
I
mean
it's
more.
Like
the
the
dinner
talk
kind
of
thing,
it's
completely
optional:
it's
not
not
changing
anything.
What
we
are
doing,
it's
not
adding
semantics
and
so
on,
but
it
might
still
help
us
doing
our
work
next
slide.
A
On
the
other
hand,
humans
do
have
to
work
on
on
sdf
models
too,
and
a
format
that
is
optimized
for
tools
cannot
at
the
same
time
be
optimized
for
humans,
and
that,
of
course,
is
not
a
new
thing
that
that
has
happened
before,
and
one
example
that
is
pretty
dearly
to
my
heart
is
that
when
xml
got
got
a
reasonable
schema
language
after
the
w3c
schema
disaster
that
started
as
an
xml
based
format
and
yeah.
A
So
james
clark
actually
defined
something
called
relax:
energy
compact,
which
was
not
designed
for
interchange
but
but
was
designed
for
the
whiteboard,
so
it
has
less
noise
and
more
more
focus
on
on
the
substance,
and
that
facilitates
human
interaction.
A
So,
given
that
james
lark
has
shown
us
how
to
do
this,
the
question
came
up
during
the
hackathon
is:
is
there
something?
Maybe
that
can
be
done
with
sdf
that
points
in
the
same
direction?
Next
slide.
A
A
Actually,
the
cycle
frequency
of
pedal
on
on
a
bike
or
something
like
that,
so
that
it's
measured
in
one
per
minute
in
the
cinema
unit,
one
per
minute
and
it's
not
writable
and
so
on,
and
there
are
some
some
auxiliary
properties
here,
range
and
step,
which
are
what
you
would
expect
expect
them
to
be,
and
only
the
the
cadence
is
actually
required.
A
So
I
think
most
of
us
now
can
read
this.
Well,
maybe
it's
a
little
bit
small
for
for
good
eye.
It
requires
good
eyesight
but
yeah.
So
I
just
went
ahead
and
fantasized.
How
should
the
compact
form
of
this
looks?
Look
like
and
that's
the
next
slide,
which
will
be
familiar
to
people
who
wear
the
hackathon,
so
this
is.
This
is
exactly
the
same
information
as
you
can
see.
A
It
now
really
focuses
on
the
descriptions
that
most
of
the
lines
are
actually
description
lines
now,
which
is
good,
because
those
descriptions
descriptions
are
pretty
central
to
the
model,
but
the
the
most
of
the
the
actual
hard
information
is
in
the
colored
parts.
I
forgot
to
color
the
unit.
The
unit,
of
course,
is
also
hard
information.
A
So
well
we
have
an
info
block
at
the
start,
which
we
of
course
want
to
have
and
then
instead
of
having
sections,
sdf
object
and
sdf
property,
and
so
on,
we
just
put
the
the
kind
that
is
there
first,
so
it's
called
object
and
then
the
name
it's
called
and
actually,
in
this
case
the
sdf
object
and
the
sdf
property
have
the
same
name,
which
happens
a
lot.
So
that's
not
a
problem.
It's
just
a
property
of
that
model.
A
So
the
the
object
cadence
has
a
description
and
it
has
three
properties
which
belong
to
the
object
because
they
are
indented
like
this,
and
the
properties
actually
have
some
definitional
content.
That
is
essentially
on
one
line
each
because
there
actually
isn't
more
there.
A
That's
really
all
that
there
is,
and
the
cadence
actually
has
a
unit
as
well,
and
I
probably
should
have
added
units
to
the
other
things
as
well,
but
I
just
wanted
to
show
that
of
course,
qualities
that
are
not
in
that
shortcut
form
can
be
added
just
as
separate
properties.
So
what
does
it
say?
The
property
cadence
is
r-o,
so
it's
readable,
not
writable,
but
observable.
A
It
has
an
exclamation
mark,
which
means
it's
required
and
the
the
data
shape
is
integer,
integer,
equal
or
more
than
zero.
So
it's
a
non-negative
integer
and
the
range
is
readable,
observable
but
optional,
and
if
it's
there
it's
an
array
of
two
integers
and
the
property
is
optional
again
and
it's
an
integer.
A
So
this
is
really
the
substance
of
this
specification
and
yeah.
We
can,
you
can
add
back
all
the
other
things
that
that
we
want,
but
the
the
three
aspects-
readable,
writeable,
observable
optionality
and
data
shape
actually
all
fit
on
one
line
for
for
practically
all
meaningful
modules.
So
this
is
just
an
example.
I'm
not
saying
that
I
I
know
how
to
do
all
the
models
in
the
playground
or
even
the
the
entirety
of
sdf.
So
this
is
just
a
snapshot
next
slide.
A
So
the
the
design
here
really
is
to
do
to
be
lazy
as
good
programmers
should
be.
So
we
let
the
yaml
format
do
most
of
the
work.
A
For
those
who
don't
know
that
yaml
is
widely
used
as
a
humane
form
of
json,
but
it
goes
beyond
json,
so
we
are
not
stuck
with
jason's
limitations
it,
but
it's
not
just
translating
the
json
to
yaml,
that's
not
enough,
but
it
also
combines
section
names
and
item
names
into
this.
One
label
object,
cadence
or
property
cannons.
A
So
just
just
to
highlight
the
the
places
here
that
actually
are
changes
from
from
the
the
json
to
yemel
result
coming
from
the
original
model.
So
for
me,
this
works
and-
and
it
would
be
nice
if,
if
other
people
were
looking
at
this,
there
was
some
positive
feedback
during
the
hackathon.
But
of
course
I'm
I'm
really
interested
to
hear
about
other
feedback
next
slide
and
and
my
plan
is
to
actually
complete
the
implementation,
verify
it
against
the
playground
modded
model.
A
A
So
from
from
the
point
of
view
of
this
working
group,
what
I
think
we
should
do
once
it's
tried
out
a
little
bit
more
and-
and
we
decide
we
like
it
is.
This
could
be
an
informational
document
that
that
goes
along
with
the
sdf
spec,
which
is
the
the
normative
the
standard
track
document.
So
at
some
point
we
might
want
to
decide
to
adopt
it
as
as
a
a
working
group
document,
but
that's
not
the
situation
right
now.
D
From
me
so
yeah
I
was
like
going
to
like.
Oh
that
looks
like
yaml
and
I
guess
your
next
slide
answered
my
question.
It's
mostly
yaml,
but
it's
not
quite.
Is
it
your
intention
carsten
that
this
be
round
trippable
from
okay?
B
Yeah
yeah,
I
I
agree,
I
think
the
run
tripability
is
a
necessary
feature
here,
but
if
that
works
out,
I
think
this
is
a
really
cool
thing
or
really
useful
thing
actually
before
they
can,
as
exactly
as
you
said,
for
the
whiteboard
scenarios
and
so
on.
B
The
only
risk,
as
I
mentioned,
is
perhaps
that,
as
as
time
progresses,
this
will
overtake
the
json
based
format
as
the
the
kind
of
sort
of
normative
or
the
the.
What
do
you
say
for
the
adopted
models
in
one
dm
and
so
on?
As
the.
E
F
Yeah,
just
on
on
sdfc,
there
was
the
idea
of
maybe
building
a
a
visual
code
or
or
atom
handler
that
worked
sort
of
like
the
way,
the
markdown
or
or
ascii
dock
handlers
work.
So
you'd
have
split
windows,
and
if
you
wanted
to
actually
see
the
json,
you
could
look
at
it.
But
if
you,
if
people
use
that
it
would
it
wouldn't
really
be
much
of
an
issue
as
to
which,
which
was
a
canonical
form,
because
they
would,
they
would
always
be
sort
of
parallel
from
the
developer's
point
of
view.
F
You'd,
you
could
you
could
something
wasn't
working?
You
could
pull
it
in
and
work
on
it
in
this
dfc
and
then
just
spit
it
back
out
to
your
tool
chain.
That
would
be
the
way
I
would
want
to
use
it,
and
I
would
definitely
use
it.
I
played
around
with
some
other
sort
of
text-based,
simple
formats
that
were
not
round-trippable,
and
that
was
really
why
it
didn't
work
out.
F
So
this
this
is
definitely
an
interesting
direction.
G
A
I
use
things
like
that
is
when
I
open
an
sd.
Let's
take
an
example
that
I
already
do
today
when
I
open
the
sibo
file
that
get
gets
automatically
converted
to
yaml.
So
in
the
editor
I
see
the
yammer
for
the
zebra
file
and
when
I
write
back
that
gemini
file,
let's
convert
it
back
to
sieber,
so
it's
for
me
sibo
is
a
directly
editable
format.
I
I
don't
see
in
human
editor,
it's
actually
binary,
so
I
I
will
not
see
an
sdf.json
once
this
is
completed.
G
Yeah,
I
also
also
grant
this
useful
thing
to
do,
especially
for
you
know,
editors,
human
use,
but
I
think
that
normally
format
still
definitely
has
a
clear
role,
because
that
one
has
better
compatibility
with
variety
of
different
tools
out
there.
G
Actually,
it
has
been
very
convenient
to
work
with
the
json
format
for
building
a
lot
of
the
tooling
on
sdf,
which
might
might
be
harder
with
a
yellow
format,
but
in
a
sense,
if
we
look
at
the
yaml
format,
just
you
know
as
one
ecosystem
where
we
can
translate
to
and
from
it
actually
fits
nicely
with
the
other
set
of
tools
and
and
processes
that
we
are
building
here.
B
One
thing
also
perhaps
to
think
about
better
is,
is
the
this:
how
we
code,
what
you
say,
the
the
special
features
so
rewrite
the
observable
and
so
on,
and
if
I
mean
how
how
what
what
is
coded
to
very,
very
short
form
and
what
is
still
still
there,
but
still
I
like
this
anyway.
Any
other
final
comments
questions
on
this.
B
So
this
is,
I
guess
this
is
a
bit
of
a
I
shouldn't,
say
hobby
project,
but
still
very
useful
stuff,
but
maybe
not
the
core
focus
of
the
group.
But
please
don't
please
keep
working
on
it
anyway.
F
Michael
koster,
very
brief
comment
in
that.
I
think
we
it's
time
to
put
all
these
tools
in
one
place,
start
putting
all
these
tools
in
one
place,
so
everything
can
be
collected.
There's
really
a
lot
of
it
now
and
I
I'm
not
sure
where
that
belongs.
But
I
think
as
a
a
topic
for
between
now
and
the
interim,
where
do
we
put
tools,
and
maybe
just.
E
F
Of
pointers
is
really
all
it
would
take,
but
yeah
easy
thing
to
do.
D
We
are
allowed
to
include
tools
into
our
github
organization.
I
believe.
B
Yeah,
thank
you.
Everyone
for
staying
around
and
participating
and
contributing
today
and,
as
we
said,
there
will
be
a
call
for
a
doodle.
There
will
be
a
doodle
for
an
interim
in
the
near
future
and
with
that
I
think
we
conclude
for
today
on
on
the
exactly
yeah.