►
From YouTube: ASDF WG Interim Meeting, 2021-04-21
Description
ASDF WG Interim Meeting, 2021-04-21
A
Okay,
so
welcome
everybody.
This
is
enough
well
to
asdf
interim
on
the
21st
of
april
2021..
This
is
the
noteworld
you
are
recorded
now
and
so
remember,
being
an
isp
professional
and
the
usual
ipr
guidelines
apply
next
slide.
Please.
A
And
if
you
forgot
what
they
are,
they
are
here
and
you
can
read
them
at
your
own
lecture
next
slide.
Yes,
this
is
a
meeting.
We
had
all
kinds
of
confusion
ahead
of
this
meeting
so
but
this
should
be
reasonably
okay.
The
plan
is
to
we
have
we
use
kodi,
md
and
the
link.
Is
there
note
that
it's
a
different
link
from
the
one
that
was
shown
on
the
original
agenda,
because
we
got
a
new
one
from
the
secretariat?
A
A
Next
slide
again
start
again
I'll
just
copy
the
other
ones
so
status
update.
We
were
chartered
in
october
last
year,
michael
myself,
for
sharing
progress.
So
far,
we've
survived
two
itfs
with
hackathons
we've
had
two
previous
virtual
interims
and
we
managed
to
produce
one
implementation
draft
which
is
under
that
link,
which
is
the
o5
version
of
the
sdf
specification,
and
so
I
think
we
are
moving
along
at
the
good
pace
and
looking
forward.
I
think
we
we
we
are.
We
talked
about
this
interim
at
the
last
idea.
A
Some
more
of
the
outreach
not
really
much
updates.
I
can
provide
you
some
updates
on
the
progress
on
these
things.
A
The
news
is
that
somehow
somebody
in
this
process
of
of
managing
the
contribution
managed
managed
to
mess
up
the
contribution
sort
of
I
mean
they
failed
in
translating
it
from
word
to
pdf
or
something
so
we
went
out
in
a
garbled,
some
kind
of
messed
up
way
and
the
result
of
that
that
it
couldn't
be
voted
on
in
at
the
march
meeting
and
now
so
it's
it's
up
actually
up
for
friday,
I
think
sort
of
if
it
was
next
week
or
something
like
that
so
this
week,
so
they
actually
got
some
extra
time
to
spend
on
it
and
they
have
been
talking
a
bit
with
with
us
and
the
others
on
what
to
do.
A
He
is
very
positive
about
this.
I've
had
some.
We
had
a
good
discussion
yesterday
with
folks
from
iec
from
the
61
850,
the
the
folks
who
build.
A
No,
that's
the
stop
that's
group
with
so
so.
The
sdf
is
part
of
a
new
work
item
proposal
to
this
sc-41,
and
there
was
some
discussions
about
this
new
worker
proposal
with
folks
from
iec
61850,
which
is
the
utilities
company's
specification
work
about
potential,
but
that
was
very
much,
but
the
the
concrete
thing
coming
out
of
that
was
that
they
maybe
felt
that
sdf
is
a
bit
wet
behind
the
ears
when
it
comes
to
buildings,
sort
of
normatively
mandating
in
iso
specifications
right
away.
A
So
but
we'll
see
what
happens
with
that
so
unfortunate,
a
bit
long
answer
there
hasn't
been
any
voting
yet
as
we
understand
it,
we'll
see
what
happens
I'll.
Let
you
know,
of
course,
thank
you.
A
C
He
I
did
hear
back
from
them,
but
they're
they
were
like
we're.
We're
really
busy
doing
a
thing
for
a
release.
So,
okay.
C
It's
really
been
quiet
from
everybody
so
far.
I
guess
we
could
do
some
more
outreach
again,
I'm
I
could
follow
up
with
them
again.
I
know
they've
they've
just
been
busy
sort
of
getting
their
own
stuff
together,
though,
and
they're
still
interested.
D
C
C
A
Good,
so
that's
where
we
are
today
and
I
think
we
don't
need
to
really
have
to
say
much
more
here,
so
I
think
can
move
to
the
next
lab.
A
Because
we
already
spent
15
minutes
on
this,
I
think
we
need
to
get
going
on
the
concrete
stuff.
So
this
is
the
the
kind
of
agenda
for
today
which
are
the
the
relevant
open
issues,
and
so
I
guess
torsten
or
do
you
want
to
go
through
this
or
or
true?
E
It's
easiest,
if,
if
you
do
that,
so
I
I
just
listed
the
issues
and
prs
that
are
out
there
plus
one
thing
that
that
hasn't
generated
an
issue
yet
but
is
being
discussed
in
some
detail
in
one
dm
and
four
of
these
things
actually
have
links
on
them.
So
you
can
click
those
and-
and
we
can
look
at
the
issue
or
pr-
and
I
think
the
other
ones
are
kind
of
boring.
E
So
we
don't
need
to
look
at
those,
so
the
the
first
one
on
on
the
list
on
the
slides.
If
you
can
go
back
to
that,
thank
you
is
multi-instancing.
E
Sdf
things
we
had
some
discussions
in
one
dm
that
we
really
need
to
be
able
to
have
an
outlet
strip
with
four
outlets
and
the
the
outlets
can
be
described
as
sdf
objects
or
sdf
things.
So
we
essentially
need
a
way
to
say
in
an
sdf
thing
that
there
are
multiple
multiple
instances
of
some
things
in
this
thing,
and
the
discussion
in
1dm
is
pretty
clear
that
we
want
to
make
this
look
almost
like
json
schema,
org
and
the
the
pr
for
that
still
has
to
be
written.
D
Do
you
want
to
have
comments
right
away
or
yes
should
we
do
so?
Actually,
one
more
thing
just
recently
came
up
on
that.
Do
we
have
a
way
to
indicate
there
is
no
upper
bound.
D
E
Now,
if
you
actually
use
the
items
quality,
then
you
are
invoking
this
whole
mechanism
and
then
it's
from
zero
to
infinite.
D
D
E
D
Okay,
so
so
let
then
let
let's
go,
go
through
it
once
more.
So
if
you
don't
put
anything,
you
don't
put
items
and
you
don't
mean
max,
then
it's
well
depending
if
you
have
sdf
required
it's.
If
you
have
sdf
required
link
to
that
and
it's
then
it's
one.
If
you
don't
have
it
it's
zero
or
one
right,
that's
the
basic
case,
and
if
you
put
items
there,
then
it's
undefined
amount
up
to
infinite,
and
if
you
put
min
or
max
items,
then
you
can
define
explicitly
which
are
the
min
and
max
limits.
E
D
E
F
Yeah,
I
got
a
fan.
Sorry.
F
D
F
D
E
Okay,
so
let's
move
to
issue
number
12.,
that's
pretty
old
and
for
a
while,
we
didn't
quite
know
when
we
actually
wanted
to
use
the
the
idea.
So
right
now,
units
in
sdf
are
always
cinnamon,
always
units
from
the
cinema
registry,
and
we
had
a
hunch
that
we
would
need
to
be
able
to
put
in
your
eyes
there
and
can
you
scroll
down
so
in
in
the
1dm
discussion.
E
There
finally
came
up
an
example:
there
is
a
rather
obscure
unit
called
slug,
which
you
may
want
to
look
up,
because
it's
really
funny
because
it
also
has
glugs
and
blobs
and
other
things
anyway.
E
So
that
would
be
the
use
case.
We
were
looking
for
and,
of
course,
the
the
the
question
really
is,
which
of
the
two
dangers
is
the
the
worst
one.
If
we
don't
have
a
way
to
reference
uis,
then,
essentially,
anyone
who
wants
to
do
anything
in
sdf
and
has
a
unit
that
is
not
yet
in
there
needs
to
register
it
in
there
and
that
would
increase
the
kitchen
sink
factor
of
of
that
registry.
E
E
So
that's
the
one
danger
and
the
other
danger,
of
course,
is:
if
you
just
open
it
up
to
your
eyes,
then
people
will
be
lazy
and
and
not
registering
anything
and
just
using
an
ecosystem,
a
specific
ui
to
to
point
to
things
and
that
that's
certainly
something
that
we
don't
want
to
encourage
the
the
problem
we
have
with
your
eyes.
Is
it's
not
clear
how
to
find
them?
E
So
how
do
I
find
what
let's
say
we
we
have
a
bluetooth
model
or
we
want
to
write
down
the
bluetooth
model
and
bluetooth
has
this
particular
woodruff
model
has
some
unit
that
is
not
in
the
cinema
registry
and
that
we
don't
want
to
register.
How
do
I
find
the
right
uri
to
describe
this
unit,
and
we
essentially
would
need
to
ask
every
ecosystem
to
to
give
us
a
rule
for
specifying
this
uri?
So
this
is
a
bit
of
a
complication
if
we
want
to
reduce
fragmentation
in
this
space.
F
Everyone
wants
to
put
their
thing
in,
and
so
why
not
have
a
registration
that
accepts
your
eyes?
So
it's
not
really
in
this
same
sense
an
iana
process.
It's
just
you!
It's
a
first
come
first
serve
put
your
uri
here
and
you're
done,
and
at
least
you
then
know
how
to
go
through
and
find
something
that
someone's
already
done.
F
Sounds
to
me
like
it's
not
worse
than
the
first
come
first
serve
tag
registry
in
seabor.
E
Yeah,
but
that
namespace
is
humongous
and
it's
also
meaningless,
while
the
the
senate
namespace
is,
is
strings,
shots
rings
and
if
somebody
has
registered
ws
before
you
and
it's
not
what
second,
then
you
will
lose
hair.
F
But
you
are
going
to
open
it
up
to
your
eyes.
I'm
saying
put
your
eyes
in
the
registry:
oh,
so
you
you
don't
even
give
them
a
name.
You
just
allow
okay,
you're
gonna!
You
were
gonna,
allow
uris
in
the
the
sdl
sdf
right,
so
you
didn't
need
a
registry.
I'm
saying
create
the
registry
and
accept
uris,
which
means
they
don't
have
to
put
them
in
it.
D
So
maybe
something
in
in
between
that,
if
them,
you
could
register
a
uri
that
points
to
some
sort
of
information
that
has
these
unit
identifiers.
You
could
actually
just
register
the
uri
that
points
to
let's
say
for
pull.org
to
decide
their
own
uri
and
put
it
there
and
then
have
a
consistent
way
of
on
that,
let's
say
resulting
page
to
map
to
their
units
and
that
will
become
the
fragment
identifier.
D
E
Well,
practically,
when
you
use
these
things
in
an
sdf
spec,
you
would
have
to
give
the
thing
a
prefix
anyway,
so
that
actually
fits
pretty
well
with
the
way
you
would
use
would
be
using
them.
E
F
Twin
data
definition,
language,
or
something
like
that,
and
I
guess
it
is
what
description
language
right.
C
F
C
E
A
C
Interesting
question
is
sort
of
like
says
they
faced
with
other
so
or
even
a
language,
but
like
schema.org,
do
we
collect
units?
Are
we
are
we
in
the
position
to
sort
of
create
a
collection
of
these
because
that's
kind
of
what
we'd
be
doing
by
not
all,
but
by
not
allowing
just
external
references
we
would
end
up
essentially
collecting
them
all
which
has
good
points
and
bad
points.
C
I
suppose
good
points
being
you
know
it's
like
a
one-stop
place
that
the
the
potential
downside
being
that
it
gets
big
and
and
it
has
to
have
a-
but
you
know
we're
kind
of
already
in
the
business
of
doing
that.
So
I
guess
just
as
as
long
as
we
decide
that's
what
we're
doing.
F
So
so
I
I
understand
this
problem
to
be.
We
need
an
out
for
for
modelers
who
are
have
something
which
is
in
a
unit
that
send
ml
does
not
already
deal
with
right,
because
nml
has
a
registry
already.
F
Did
I
get
that
right?
Yes,
okay,
so
the
situation
and
and
and
if
it
was
a
common
unit
that
sent
ml
had
somehow
missed
lumens
or
something
was
you
know,
I
don't
know
if
that's
in
cinema
or
not,
but
I
know
I
noticed
it
was
in
the
the
digital
twin
document.
So
what
I
would
imagine
that
that
those
units
would
be
would
be
some
kind
of
uncalibrated
unit.
F
So
some
sensor,
you
know
you
need
to
multiply
it
by
4.73
and
blah
blah
blah,
and
then
you
get
lumens,
but
they
don't
want
to
do
that
in
the
in
the
unit.
They
want
to
return
the
uncalibrated
value
because
they
want
you
know
to
keep.
They
want
to
to
keep
track
of
systematic,
you
know
stuff
or
whatever,
and
so
they
want
their
own
unit.
That
is,
you
know,
uncalibrated,
lumens
or
slugs
or
whatever,
and
I
just
can't
imagine
that
unit
being
terribly
standardizable,
and
so
actually
the
uri
is
just
perfect
to
me.
F
E
One
of
the
nice
things
about
cinema
units
is
that
you
can
write
code
that
can
handle
any
unit
because
the
secondary
units
refer
to
the
primary
ones
in
in
a
mathematically
defined
way,
so
you
can
handle
any
secondary
unit
as
long
as
you
have
a
recent
copy
of
the
registry
and
the
primary
units
are
supposed
to
move
very
slowly,
so
you
should
be
able
to
keep
up
with
your
implementation
to
to
the
primary
units
and
of
course
that
will
not
be
the
case
with
your
eyes
and
maybe
that's
something.
D
I
think
that's
kind
of
the
key
thing
here
to
write
down
the
considerations
like
if
you
go
down
this
path,
you
know
notice
that
this
is
what
you
lose
that
then
the
engineers
in
in
charge
can
do
right
right
decisions
well.
C
Yeah,
that
makes
sense
it
would
seem
like
it
would
be
biased
toward
updating.
As
michael
said,
you
know,
you
really
really
want
to
point
people
to
update
the
senate
registry,
and
that's
really
our
that's
really
what
we
want
to
have
happen
so
just
to
have
like
a
fallback,
maybe
but
not
expected,
to
be
used.
A
lot
makes.
A
E
Okay,
so
to
me
it
seems
that
that
was
a
good
discussion
and
I'm
now
unable
to
write
a
pull
request,
and
I
I
go
with
michael's
proposal
for
the
moment
that
we
have
our
own
registry
for
uis.
D
And
do
you
mean
like
the
full
uris
like
one
per
each
a
unit
or
the
one
with
the
namespace?
So
here's
the.
E
I
would
probably
go
for
the
namespace
thing.
The
example
you
gave
with
the
dtdlv2
kind
of
discouraged
me
again,
because
that
link
actually
already
has
a
fragment
identifier.
E
So
that's
yeah,
but
anyway
I
I
propose
that
we
have
a
way
to
to
register.
Essentially
namespace
prefixes
and
people
can
use
that
in
our
standard
curie
construct
to
construct
their
own
weird
units.
E
E
D
E
E
E
A
There
is
something
called
spdx
which
somehow
relates
to
this:
have
something
understandable
to
how
to
associate
associate
live
software
licenses
with
particular
pieces
of
code
and
so
on.
I
think
they're
proposing
it
an
iso.
F
Oh
yeah,
so
so
I
know
a
lot
about
this.
This
is
in
the
s-bomb
space
and
there's
also
cypher
cyber
dx
and
there's
and
then
also
the
desktop
management
group
has
potentially
another
one
coming,
but
I
don't
think
it'll
go
anywhere
so.
F
I
haven't
read
the
I
haven't,
read
the
the
the
the
issue,
but
so,
as
I
understand
it,
you're
basically
you
don't
want
to
you
want
to
make
sure
the
licenses
are
compatible
when
you
combine
them
and
I'm
not
sure
that
spdx
is
going
is
terribly
useful
for
you
directly,
but.
E
Yeah,
I
think
that
the
people
who
are
writing
code
that
combines
sdf
models
into
larger
models
that
those
people
actually
should
come
up
with
with
some
strawmen.
D
Well,
thinking
out
loud
now,
I
guess
the
simplest
thing
is
that
you
know,
instead
of
single
value,
those
things
become
an
array,
and
you
put
everything
in
the
array.
F
Okay
and
other
works
are
have
various
other
kind
of
restrictions
on
the
derivative
works.
So
I
I
I
think
that
I
think
that
that
all
the
licenses
are
probably
going
to
have
to
be
special
case.
They're
just
going
to
have
a
bit
that
says,
can
be
combined
or
can't
be
combined
and
if
it
says
can't
be
combined,
then
human
will
have
to
figure
out
whether
a
human
lawyer
will
have
to
figure
out
whether
this
is
allowed
and
probably
that'll,
probably
kill
models
that
or
definitions
that
have
non-combining
licenses.
F
F
F
D
F
Well,
I
I
think,
that's
possible,
but
I
think
that
that,
for
instance,
if
if
I
gave
you
something
under
a
bsd,
two
clause
license
and
you
want
it
and
you
want
to
combine
it
with
an
apache
license.
The
the
result
of
combining
those
two
licenses,
an
apache
license.
D
Yeah,
I
can,
I
guess
I
would
do
a
a
simple
thing
that
that
my
combiner
barfs,
if
it
finds
that
those
are
not
equal
the
licenses,
but
for
the
other
fields.
It
could
do
something
something
sensible
so
that
there's
the
description
field,
that
the
version
field
and
the
the
copyright
field
absolutely-
and
I
guess
those
since
there's
no
legal
implications
there
we
can.
We
can
be
more.
A
A
Maybe
we
shouldn't
spend
too
much
time
on
it
here.
We
only
have
14
minutes
left
yep,
so
so
carson,
which
one
do
you
think
is
most
most
important.
There
are
many
actions
or
remaining
issues
here,
which
ones
are
the
most.
E
There's
three
bold
ones,
so
let's
do
them
in
reverse
order.
So
number
30
actually
is
a
pull
request,
and
this
essentially
clarifies
that
the
way
you
combine
an
sdf
ref
with
overrides
is
applying
the
json
merge
patch
algorithm,
which
is
documented
in
an
rfc.
E
So
maybe
that's
something
that
requires
a
little
bit
more
thinking
and
if,
if
we
could
initiate
that
thinking,
we
could
maybe
get
this
per
request
to
a
state
where
we
can
merge
it.
E
C
C
D
E
D
D
D
D
Good,
but
I
think
I
mean
overall,
I
think
the
mechanism
is
is
a
good
choice
here.
I
I
sent
a
few
editorial
needs
that
I,
in
my
humble
opinion,
might
improve
the
readability,
but
otherwise
I
think
it
is
a
right
way
forward.
E
F
E
So
29
is
is
about
addressing
all
the
various
things
that
we
seem
to
have
in
mind
when
we
talk
about
the
version
field.
So
right
now,
the
version
field
in
the
playground
models
is
the
date
which
is
needed
because
we
don't
have
a
date
field.
E
So
we
keep
the
date
in
the
version
field
and
if
you
click
on
the
email
down
there
on
the
mail
archive
link,
there
are
essentially
four
things
that
we
want
to
keep
in
the
version
field
and
that's
the
semantic
version.
The
1.2.3
thing,
maybe
something
like
a
token
holder,
so
who's
actually
incrementing.
That
version
is
that
1dm
or
is
it
a
contributing
organization
date?
E
I
talked
about
and
finally,
there's
probably
a
reason
to
have
feature
tags,
so
we
know
which
features
are
addressed
by
by
a
particular
instance,
a
particular
variant
of
of
the
model
and
yeah.
All
these,
of
course,
need
to
be
defined
in
in
some
more
detail,
but
the
the
message
is
out
there.
So
if
you
have
an
opinion
on
on
this,
please
reply
to
this
message.
B
E
Okay,
that
was
an
issue
that
came
up
when
you
combine
models
you,
you
suddenly
run
into
the
problem
that
one
model
contributes
to
a
different
namespace
than
another
model,
and
how
you
do
you
actually
represent
the
combined
model
so
right
now,
we
cannot
do
this.
Models
currently
contribute
only
to
whatever
they
define
as
the
default
game
space
and
so
far,
the
the
best
idea
we
have
had
is
to
actually
define
a
form,
a
variant
of
sdf,
which
is
an
array
at
the
top
level
and
allows
you
to
simply
have
multiple
models
in
a
single
file.
C
E
C
So
you
could
say
sdf
thing
and
you
could
say
you
know
vcl
colon,
whatever
you're
defining
and
this
one's
going
into
that
namespace
like
specifically
override
the
default
namespace
by
putting
the
prefix
onto
the
the
thing
you're
defining,
but
I
don't
think
the
syntax
we
have
is
or
there's
going
to
be
problems
with
that.
I
think
possibly.
C
E
Well,
on
the
side
where
you
referenced,
you
can
do
lots
of
things,
but
on
the
side
where
you,
where
you
export
jsonpointer,
has
a
very
very
simple
mind,
I
mean
it
just
uses
the
json
file
and
and
goes
through
the
map
members
and
then
through
the
array,
elements
and
that's
it.
It
cannot
do
any
processing
on
that.
D
D
I'm
thinking
out
loud
here
yeah.
Well,
maybe
the
solution
is
to
have
a
look
at
how
how
hacky
it
would
get.
E
The
interesting
thing
about
the
the
hackiness
of
the
result
is
that
the
the
way
our
json
files
are
structured.
The
first
part
of
the
fragment
identifier
is
always
a
keyword.
Sdf
object,
sdf
type
and
something,
and
only
the
second
part,
would
then
be
available
for
putting
in
a
prefix
so
that
that
gets
interesting.
D
Yeah
but
anyway,
I
guess
that
can't
be
for
v
next,
it's
not
that's,
not
a
critical
thing
for
the
upcoming
rfc,
so
we
have
time
to
play
around.
D
F
Yeah,
let's,
let's,
let's
ari,
let's
post,
don't
post
the
details
of
your
of
your
hack,
but
rather
what
the
elements
of
I
think
you
think
you
what
pieces
of
information
you
think
you
need
to
put
somewhere
to
the
list.
F
F
Okay,
so
are
we
having
another
virtual
interim
prior
to
1
11?
I
think
so
I
hope
so.
Okay
are
sure,
then
about
at
the
end
of
may
or
the
beginning
of
june.