►
From YouTube: WG API Expression Bi-Weekly Meeting for 20200512
Description
WG API Expression Bi-Weekly Meeting for 20200512
A
B
B
A
C
D
F
D
H
E
D
E
F
Will
really
help?
Can
I
ask
you
a
question
so
I'm
reading
the
the
text
here
on
the
screen
container
port
protocol
is
not
a
required
field
in
the
sense
that
the
user
doesn't
have
to
set
it,
but
it
is
a
required
field
in
the
sense
that
it
has
to
be
set.
It's
just
that
it
gets
set
with
a
default.
Does
that
not
work
yeah
that
that's.
D
The
case,
the
problem
is
that
the
default
er
runs
after
service
satify,
so
service
I
apply
deliberately
sees
exactly
the
users
intent
and
not
the
default
aversion
of
the
object,
because
we've
make
a
strong
distinction
between
things
that
the
user
specifically
requested
and
things
that
the
system
has
added
on
to
make
the
requests
complete.
So
that.
D
Exactly,
and
only
when
the
default
field
is
part
of
a
key,
so
the
problem
here
is
really
that
container
port
a
the
the
key
isn't
sufficiently
unique
and
you
have
to
you
have
to
add
the
protocol
to
make
it
unique.
I,
see
and
server
side
apply,
remembers
the
key,
because
you
want
to
own
the
item
that
you've
that
you've
made
a
claim
about,
and
yours
first
document
right
so
I'm.
Sorry.
F
D
D
F
D
F
D
E
E
D
D
D
A
E
D
On
on
this
one,
there
was
some
confusion
in
the
comments
about
whether
the
status
code
was
a
cube,
control
status
code
or
an
API
server
status
code.
I
think
everybody
agreed
that
it
didn't
make
sense
to
have
Q
control
returned
a
different
status
code,
so
I
think
it
was
actually
about
the
API
server
status
code
and
I
think
we
all
agreed
that
we're
not
going
to
change
status
code,
but
we
might
add
a
header
yeah.
A
A
We
got
the
issue:
I
discussed
it
with
the
with
the
reporter
on
the
slack
I
think
and
the
result
was
a
cap
and
to
the
cat,
the
user,
the
reporter
said,
that's
exactly
what
he
wanted
and
then
the
cat
there's
no
mention
of
a
status
code
except
from
HCPCS
code,
which
wouldn't
work,
because
there
is
no
no
matching
one.
That's
my
my
state
he's
also
mentioning
a
header,
so
I
would
suspect,
he's
talking
about
HC
P
and
not
Q
CDL
with
the
status
code,
but
yeah.
That's
was
my
state
of
stages
on
that.
D
D
A
E
E
D
E
D
Well,
it
would
be
nice
to
users
if
they
at
least
got
a
warning
and
knew
that
they're
doing
something
that
is
being
ignored,
but
we
don't
for
all
of
our
API
calls.
Today
we
just
silently
drop
everything
that
you
tried
to
do
to
status
with
your
writing
to
the
spec
in
point,
yeah
I'm,
not
super
user-friendly.
Do
we
have
to
solve
that
problem
right
now,
though?
D
D
D
Possibly
I
mean
I
personally,
III
would
optimize
for
for
getting
the
just
the
solution,
and
so
that
we
have
something.
If
that
gets
in
rapidly,
then
we
can
iterate
on
the
user
implications
of
it.
Since
it
seems
like
we
have
a
little
extra
time
in
this
release
anyway,
but
I
I,
wouldn't
I,
wouldn't
block
on
figuring
out
the
user
stuff
like
let's
do
divide-and-conquer
to
solve
our
problem
separately.
Yeah
that
make
sense
if.
C
D
I'm
nervous
about
I'm
nervous
about
failing,
because
our
existing
none
of
our
existing
api's
work
that
way
people
might
be
depending
on
that.
Well,
you
know
like
what
happens
Labs,
if
you
do
it
in
in
client-side,
apply
we
just
silently
drop
it
right,
yeah
what
yeah
I'm
really
wrong.
In
my
opinion,
yeah,
it's
absolutely
definitely
really
wrong.
D
D
Yeah,
it's
basically
kind
of
unfinished
I
would
say
when
Jordan's
warning
feature
goes
in.
It
will
be
slightly
easier
to
change
this
behavior.
The
problem
is
this
kind
of
a
load
bearing
bug
like
like
clients
who
are
randomly
setting
things
in
their
status
or
whether
they
realize
it
or
not,
depending
on
that
being
ignored,
so
making
it
fail,
would
break
them
because
they're
not
expecting
these
failures
and
making
it
like
actually
carry
out
what
they
said.
D
D
A
Building
I
was
we
were
so
concerned
that
that's
the
way
I'm
doing
it
right
now
is
barely
testable
and
had
seem
to
be
dangerous
and
I,
don't
feel
too
safe,
adding
it,
but
we
have
to
fix
it
somehow
and
one
thing
I
looked
at
was:
can
we
define
those
features,
get
wiped
for
status
and
force
up
resources
somewhere
and
maybe
generate
the
code,
but
that
doesn't
seem
to
match
any
specification.
So
that's
why
I
thought
about
it's
weird
that
it's
defined,
no
we're
just
there
I.
D
A
D
Is
just
so
I
actually
consider
doing
it
a
slightly
different
way,
and
maybe
you
can
do
this
generally?
Is
we
have
some
fuzz
testing
right
now,
yeah
that,
like
generates
random
objects?
Basically,
so
if
you
couldn't
figure
out
a
way
to
call
the
existing
code
to
do
a
wipe
and
fuzz
an
object,
call
the
existing
code
to
clear
things.
A
D
A
H
D
D
D
D
A
Have
an
opinion
on
the
question
so
the
way
I
built
a
new
approach
know
was
that
I
could
expose
the
reset
fields
for
the
strategy,
both
for
the
create
strategy
and
the
update
strategy,
because
they
can
be
either
not
available
or
different.
So
there's
the
current
way.
I
started
to
do
it.
Yesterday's
I
could
have
two
different
sets
of
fields
for
create
an
update
and
we
were
discussing
if
they
actually
are
required
or
if
there's
situations
where
they
can
be
different
should
be
different
and.
D
A
D
A
D
D
So
so
namespaces
namespaces
have
these
extra
finalize
errs
because
we
added
them
to
the
interfaces
before
they
pre
regularize
them.
So
there's
final
answers
in
metadata
which
apply
to
everything
and
are
mutable
after
the
fact
there's
finalizer
zone
namespaces,
which
is
this
additional
field
in
spec.
D
That
means,
if
I
change
them
in
my
change
them
and
apply,
and
we
silently
drop
them,
then
it
appears
to
have
worked
even
though
I
change
didn't
do
anything
and
the
problem.
What
exactly
is
the
problem
that
right
like
if
it
gets
if
it
gets
reset
of
updates,
then
does
it
really
matter
if
we
track
as
a
manage
field
or
not.
G
A
H
D
So
the
system
basically
said
that
you
got
them,
even
though
you
didn't
actually
change
your
value.
It
just
can't
transfer
ownership
without
changing.
For
that
and
that's
someone
some
users
finalize
gets
a
conflict
because
they
have
the
current
value.
They
didn't
change
it,
but
it
thinks
that
they
don't
own.
The
field
yeah.
D
So
here's
the
question
for
you:
if
we
get
this
wrong
now,
can
we
change
it
without
breaking?
Can
we
change
it
in
the
future
without
breaking
users?
Think
the
answer
is
yes
like,
like
imagine
we
just
we
just
launched
the
way
it
is
today
with
this
problem.
I
I
would
initially
claim
that
this
is
gonna
affect
almost
nobody.
D
I
can't
imagine
somebody
using
your
ply
to
manage
the
namespace
finalized
errs
because
I,
because
basically
automatically
done
right
now,
so
that's
gonna
be
one
of
the
last
things
to
get
changed,
and
also
the
consequences
are
just
not
that
high,
because
someone
using
apply
to
manage
the
sub
resource.
The
finalized
errs
is
gonna
force
conflicts
all
the
time
all
the
time.
So
I
think
that
this
is
not
that
important.
So
it's
okay,
it's
not
the
end
of
the
world.
If
we
get
it
wrong.
A
So
if
we
there
is
no
nothing
to
go
live
with
now.
If
we
leave
the
problem
aside,
we
got
one
strategy
with
one
set
of
fields.
It
gets
reset
either
one
of
them.
We
make
the
problem
better
for
most
things
probably
status
and
we
leave
the
problems
we
currently
have
and
don't
know
about
on
the
table
to
fix
them
later
we
improve
the
state.
I
already
got
the
code
to
have
two
sets
of
fields
and
I
defined
them
for
update
and
create
I
could
get
rid
of
this,
but
the
question
is:
if
I
should.
D
Yeah,
it
does
seem
like
it
does
seem
like
the
most
natural
way
of
modeling.
This
is
that,
if
you
set
it
and
create,
then
you
own
the
field,
but
then
your
your
future
update,
which
also
includes
these
I,
mean
I,
mean
what
are
we
gonna
do
on
your
update,
like
cuz?
Really
you
can't
affect
those
fields
at
all,
so
so
does
it
make
sense
to
own
them?
You
can't
affect
those
fields,
but
all
through
a
normal
operation,
I
mean
I.
D
Gonna
apply
it
again,
and
basically
the
fact
that
the
field
is
treated
this
way
means
that
I
can't
use
the
same
document
for
both,
creates
and
updates,
because
part
of
it
will
be
honored
for
it
create,
but
not
honored,
for
an
update.
So
do
I
really
own
that
field
like
I
kind
of
I
I'm
responsible
for
it
being
the
way
it
is,
but
if
I
wanted
to
affect
that
field,
I'd
have
to
send
a
completely
different
kind
of
document
to
a
different
API
endpoint
to
the
finalized
finalized
endpoint.
D
D
A
Okay,
I
think
certificates
where
a
different
example,
but
they
seem
to
be
immutable
and
some
parts
can
be
accessed
through
sup
resources
but
I.
Suppose
you
shouldn't
own
them,
I
guess
the
same
argument.
You
just
need.
If
you
can't
change
the
field,
there's
no
reason
to
own
it.
Also
that
would
make
the
manage
field
smaller,
for
because
they
wouldn't
include
stuff
that
Jess
co-created
but
can
never
be
updated.
A
A
A
A
A
B
C
B
A
A
E
E
We
would
like
to
have
a
set
of
wheels
and
see
what
sort
of
behavior
we
expect
for
each
field
and
see
if
we
need
to
change
the
ground
policy.
Daniel
seems
to
think
that
it's
sort
of
confusing
to
the
atom
disagree
I
think
it's
confusing
today,
so
we're
trying
to
collect
some
fields
and
see
how
people
would
expect
the
behavior
to
be
depending
on
the
field.
D
D
It
also
I
mean
it
might
prevent
you
from
using
apply
if,
if
you
can't
like
you're
checking
something
into
source
control
and
you
need
to
switch
from
excuse
my
example
arguments
to
the
command
line
in
your
deployment.
You
switch
that
in
source
control,
but
when
your
CI
CV
pipeline
applies
that
it
doesn't
actually
remove
the
old
feel
like
how
are
you
gonna,
you
can't
use
apply
if
you
can't
remove
stuff
that
you
don't
want
anymore
yeah,
then.
D
That's
somewhat
related,
and
that
would
be
like
a
that
would
be
like
the
catch-all
solution
like
if
it
is
making
a
mistake,
then
it
would
be
good
to
be
able
to
specify
a
like
an
assertion
of
non-existence
to
make
sure
that
a
given
field
is
gone,
and
maybe
that's
maybe
that's.
The
solution
here
is
like
like
don't
guess
just
make
users
tell
us,
but
I
think
it
would
be
better
if
we
at
least
got
the
majority
of
obvious
cases
right.
D
So
I
think
the
action
item
here
is
Antoine
is
working
on
getting
a
list
of
examples
appeals
where
the
default
user
expectation
is,
you
know,
here's
a
field.
Dewey's
doesn't
user,
expect
this
to
stick
around
or
go
away
when
they
remove
it
I
think
there's
a
chance
that
we
can
come
up
with
a
simple
rule
that
solves
most
cases
and
but
maybe
we
can't,
but
we
need
the.
We
need
a
list
of
examples
to
know
for
sure.
I
Joy's
on
Nicole
Joe,
can
you
so
I
just
got
back
from
break
and
I
am
trying
to
get
caught
up
on
everything
going
on.
I
did
have
a
task
to
review
many
of
the
uses
of
built-in
validators
for
native
types
and
see
what
the
overlap
with
those
are
on
some
of
the
declarative
approaches
we
have
and
see
if
we
could
start
to
reduce
duplication,
use
the
declarative
stuff
instead
of
you
know,
custom
code
in
certain
places,
so
I've
started
that
and
there's
definitely
some
patterns
there.