►
From YouTube: OpenActive W3C Community Group Meeting / 2018-04-11
Description
A public hangout for members of the OpenActive W3C Community Group.
Agenda: https://lists.w3.org/Archives/Public/public-openactive/2018Apr/0000.html
For more information visit: https://www.openactive.io/w3c-community-group.html
A
Thanks
for
coming
along
everybody
good
to
see
so
many
faces
on
the
call
this
week
as
usual,
I'll
share
some
slides
in
a
moment
just
to
structure
the
conversation.
Thank
you.
What
I
chose
to
look
at
the
agenda
there
are
I
think
there
might
be
a
few
people
on
the
heat
on
the
call
and
haven't
been
on
before,
or
at
least
some
faces.
I
don't
recognize.
If
this
is
your
first
of
these
calls.
Do
you
wanna
just
introduce
yourself,
say
hello
to
the
rest
of
the
group.
B
B
C
Hello
makes
right
here:
can
you
hear
me?
Yes,
we
can
Nick
cool
yeah,
so
we've
we're
booking
platform
and
we've
got
an
active
integration.
That's
now
working
with
I'm
in
for
a
pilot
with
badminton
England,
so
we
actually
have
version
0.3
with
some
urban
elements
of
point
four
actually
now
coded
and
working
and
tested
so
I'm,
just
interested
in
keeping
keeping
updated
with.
What's
going
on
with
point
for
this
week,.
A
Thanks
coming
along
okay,
I'm
going
to
show
my
screen,
okay,
so
the
the
agenda,
this
week's
call
there
are
a
few
things
to
cover
and
we're
going
to
focus
primarily
on
the
the
booking
specification
with
you.
But
there
were
a
couple
of
other
items
that
are
on
the
agenda
as
well,
so
Chris
asked
if
we
could
have
opportunity
just
to
talk
a
little
bit
about
virtual
activities.
A
I
think
this
is
likely
to
end
up
being
a
kind
of
bosal
for
extension
to
the
specification.
So
it
might
be
just
good
to
have
just
an
initial
conversation
about
what
theirs
are
what's
and
the
requirements
might
be.
Then
we'll
focus
on
the
the
booking
specification
overview,
so
Nick's
going
to
take
us
through
a
discussion
there
and
then
I
just
at
the
end.
I.
A
Just
very
briefly
wanted
to
touch
on
a
document
I
shared
who
the
group
earlier
about
improving
some
of
the
processes
around
posing
changes
to
the
specifications
and
then
getting
those
through
to
publication
and
again.
If
there's
anybody,
if
there's
anything
that
anyone
else
wants
to
cover,
then
appreciate
so
I'm
going
to
kick
things
off
with
the
the
discussion
around
and
virtual
activities
Chris
did
you
want
to
kind
of
give
us
a
bit
of
a
background
bit
of
an
overview
about
the
things
that
you've
been
talking
to
my
nation
and
you'll
work
yeah.
B
But
the
time
might
matter
you
could
say:
okay,
if
there's
nothing,
no
one
to
go
for
a
run
with
6
p.m.
in
Hackney.
Well,
another
option
would
be
do
a
virtual
environment
with
someone
anywhere
in
the
world
at
6
p.m.
and
here
are
the
people
that
have
flagged
that
they
won't
see
where
they're
available
to
run
with
you
or
they're.
B
D
E
Great
broadcast
event
is
a
schema.org
type
and
that
we
what
to
represent
that
information,
it's
online
classes,
Jade,
isn't
it
you
mainly
that's
the
kind
of
thing
yeah.
D
E
I,
don't
know
if
it's
it's
so
we're
using
well
at
the
moment,
the
plan,
at
least
with,
is
use
that
skimmed
or
broadcast
event
for
that
which
wouldn't
require
any
skip.
Spec
changes,
because
that's
just
using
schema,
although
may
require
an
addition
to
the
profile
active
profile
which
was
I,
guess
a
separate
conversation,
but
does
I,
don't
know.
E
B
D
Okay,
I
think
the
concert
I
think
we're
talking
about
the
same
thing
and
say
it.
We
haven't
actually
differentiated
between
the
two
and
it
could
be
an
event.
That's
happening
somewhere,
you
could
go
to,
but
the
user
in
this
case
wouldn't
be
going
there
or
it
could
be
something
that
you
couldn't
go
to
and
she
said
like
just
like
the
flakes
with
it's:
it's
just
out
there
in
the
ether
and
you
want
to
join
in.
B
Yes,
I
think
the
the
the
second
mode,
if
you
like,
is
the
self-serve
mode.
Where
hey
there
isn't
a
gym
class
near
you,
but
through
service
xed
you
can
grab
a
class
and
do
it
on
your
TV
or
in
in
the
race.
Felice
sense.
There
isn't
a
run
near
you,
but
his
his
is
one.
The
tech
runners
did
last
week.
You
can
grab
it
and
just
run
along
with
it.
So
you
kind
of
your
self-serving,
and
in
that
case
it
can
be
both
location
and
time.
B
Independent
right,
I
guess
I've
got
I
found
a
third
one
while
I
was
talking,
which
is
this
idea
that
there
is
a
kind
of
event
going
on
over
period
of
time.
You
can
participate
in
virtually
that's
more
like
the
virtual
race.
This
kind
of
idea,
where
you
know
just
do
a
10k
that
this
do
they
I,
don't
know
what
it
would
be.
The
Easter
10k
and
everybody
gets
an
Easter
Egg
medal
if
they
do
a
10k
this
month,
and
that's
that's
kind
of
that
reminds
me
of
video
on
time
out.
B
You
know
you
looking
at
what's
on
in
London,
there
are
some
things
they're
just
on
every
single
day.
You
know
it's
mousetrap
or
whatever
it
is,
there's
always
one
every
day
that
you
could
do
it
for
the
period
of
time
of
that
show
runs,
and
that
kind
of
idea
was
what
I
have
in
my
mind,
potentially
for
that
kind
of
a
time
period
based
approach.
E
Sound
different
to
broadcast
event
in
terms
of
the
semantic
meaning,
so
maybe
desert
either.
Well,
maybe
bed
broken
we
break
into
two
one
for
cost
event
where
it's
there's
a
TV
and
you
go
and
sit
in
front
of
it
and
do
do
your
thing
or
you
online
or
and
then
there's
the
one
where
you
literally
leave
the
house
and
you're
racing
someone
virtual
or
you're
participating
something
with
a
root.
E
A
What
I'd
like
to
do,
I
think,
is
to
move
this
forward
in
separate
proposal
kind
of
gather
together
some
of
this
discussion
that
we
can
document
as
an
issue
and
then
working
out
the
detail
of
what
might
need
to
be
changed
in
specification.
Whether
there's
some
things
that
we're
using
existing
things
like
broadcast
event
would
do
or
whether
those
other
things
that
we
need
to
put
into
so
Kristen
Jade.
B
A
Okay,
fantastic
I'd,
like
you
know,
I'd
like
to
use
these
calls
to
surface
this
kind
of
discussion
and
new
areas
where
we
need
to
be
doing
more
work,
I'm,
gonna
kind
of
touch
on
that
a
little
bit
at
the
end
of
the
course.
It
relates
to
some
of
the
the
governance
from
process
documentation
I
circulated
earlier,
but
for
the
purposes
of
agenda
I'm,
going
to
move
us
on
to
the
next
next
section
and
discussion
around
where
we're
at
with
the
booking
work,
so
I'm
just
crack
to
sharing
the
slides
to
use
them
so
Nick.
E
Sure,
and
so
I
don't
know
we
both
share
screens.
Does
that
happen
or
well?
Let
me
talk
through
this
first
and
then
we
can.
We
can
swap
screen
so
and
for
it.
I
think
most
people
may
well
have
seen
bit
of
this,
but
just
to
make
sure
that
one's
got
the
said
we're
on
the
same
page,
and
this
is
the
content.
This
is
a
list
of
content,
we've
kind
of
generated
today
relating
to
booking.
We
started
off
with
a
workshop.
E
F
E
Course,
Gladstone's
an
internal
yeah,
okay,
sure
so
sounds
like
good
Jim
and
then
and
then
Nick
and
makes
Pfotenhauer
box
are
on
the
journey
towards
that.
So
I
know
that
our
parks
are
holding
off
a
little
bit
in
anticipation
of
no
point
for
to
save
themselves
some
time
and
do
that
all
at
once,
and
and
so
there's
a
there's
that
yeah
so
that
we've
got
point
three
and
point
four
and
point
four
is
actually
in
swagger
as
well,
which
means
that
we
can
he's
a
different
face
to
look
through
those
documents.
E
So
that's
what
we've
got
will
be
quite
good
to
do
now.
In
time
we
have
is
just
quickly
run
through
of
a
diagram,
a
flow
diagram
of
how
this
all
works
and
then
link
it
back
to
the
actual
swagger
documentation
and
show
you
can
show
you
that
as
well.
So
this
is
the
flow.
It's
actually
quite
simple,
although
this
diagram
is
comprehensive.
E
So,
but
this
was
kind
of
show
you
what
you,
what
you'd
go
through
to
do
to
make
a
booking
and
like
a
point
of
the
the
swagger
inputs
in
a
sec
to
kind
of
match
this.
Basically,
the
idea
is
that
you
there's
this
feed
of
data
coming
through,
and
you
pick
a
session
out
that
you
want
a
book.
That's
what
the
first
thing
in
the
second
thing
you're
talking
about.
E
So
those
are
as
a
item
displayed
somewhere
on
our
web
page
and
then,
when
the
consumer
chooses
that
it's
a
book
the
session
is
then
there's
an
offering
that
session,
that's
being
selected.
So
that's
you
know
I'm
an
adult,
Lorraine
majr.
If
you
choose
an
adult,
then
that's
the
point
at
which
we
first
engaged
properly
with
the
booking
API.
E
First
thing
that
happens
as
we
check
the
availability
to
make
sure
that
there
are
and
leads
till
spaces
and
show
you
the
call
for
that
in
a
sec,
and
then,
when
we've
done
that
you
can
see
there's
a
little
as
they're
available
place.
Yes,
now,
the
next
thing
that
we
do
is
we
go
through
to
lease
spot,
so
that
means
just
reserve
some
spot
for
a
period
of
time.
120
seconds
I
think
is
the
amount
of
time
that's
in
a
spec
employment.
It's
not
designed
for
Interactive's
shopping
basket.
E
This
diagram
is
good
to
just
show
that
and
and
then
we're
going
to
talk
about
invoice
at
the
moment.
The
way
it
works
is
that
you
would.
The
first
thing
you
would
do
is
you
would
get
the
session
get
get
session?
Is
that
check
of
availability?
That
gives
you
back
a
number
of
offers
and
if
you
pick
one
of
those
offers
to
go
through
the
junior
adult
whatever
it
is,
you
then
send
saying
I
want
this
session
with
this
offer.
So
I
want
to
go
to
that
thing
at
7
p.m.
E
and
home
an
adult,
and
then
it
will
then
say
it
is
it
has
if
you,
if
you
post
saying
you
want
to
lease
that
it's
called
creating
new
order.
If
you
post
to
say
crane
you
order,
then,
when
you
get
a
response
back
saying:
yes
is
the
location
that
means
they
would
have
been
created.
You
then
have
to
do
a
separate.
This
is
a
new
thing
in
more
points.
All
you
have
to
do
it
and
I
get
on
the
order.
E
At
this
point,
you
want
to
log
the
status
of
the
order
or
any
detail
about
it.
So
there's
a
there's,
a
gap
fairway
you
might
choose
to
do
a
get
because
you're
just
getting
a
two
or
one
location,
header
back
and
there's
an
issue
around
that
potentially
just
creating
an
extra
call
and
then
and
then
there's
an
another
post
which
you
do
after
you've
made
the
payment
to
make
the
payment.
E
So
that's
how
band
so
strike
for
whatever
happens,
and
then,
when
that's
done,
you
say
great
I'm,
a
containment
10
pounds
of
which
2
pounds
went
to.
You
know
the
broker
the
intermediary
and
that's,
and
then
you
post,
that
and
say
payment
made
and
the
payments
made
you
get
this
to
one
created
and
although
it's
not
shown
on
this
diagram
that
to
one
created
again
has
a
location
header
with
the
order
in
it.
E
You
have
to
do
a
further
get
to
get
that
confirmation
number
which
is
at
the
end
and
so
yeah
and
then
I
think
there's
a,
although
this
is
correct.
Restfully,
in
terms
of
it
forces
you
to
do
that
the
extra
gates
it
does
increase
the
number
of
calls
necessary
to
make
the
booking
by
double,
because
instead
of
two
calls
you
before
and
so
there's
supposed
as
a
there's
a
question
there.
But
that's
something
that
we
should.
E
C
Jointed,
so
I
didn't
want
to
jump
in
so
I
just
message
yeah,
so
we've
got
use
cases
where
the
aggregator
has
the
authority
to
create
an
order.
Basically
they
can
do
what
they
want
with
a
session.
So
you've
got
a
use
case
where
you've
got
a
free
booking
that
can
be
created
immediately,
but
I
suppose
I'm
asking
for
a
a
flag
or
something
within
the
original
order.
Creation
which
is
basically
just
creating
the
order,
don't
even
necessarily
know
how
much
that
aggregator
is
paying
for
that
session
is.
C
C
E
E
Okay,
it's
good
to
know
that
something
we
should.
We
should
add
into
the
list
of
future
requirements.
This
spec
for
the
next
one
sounds
like
that's
a
bit
of
it,
so
so,
yes,
so
to
cover
the
free
use
case,
I
guess
as
part
of
that,
the
way
that
there's
currently
an
issue
which
I'll
show
my
screen
and
show
you
in
a
sec
which
is
open
around
how
we
handled
free
use
case,
there's
a
few
different
options
for
that,
in
fact,
to
you
is
the
next:
what's
your
next
slide,
Lee
did
better
things.
E
There's
a
currently
a
need
to
put
in
the
total
paid
to
provider
and
the
total
paid
to
customer
and
I
guess.
What
makes
saying
here
is
that
actually,
that's
not
necessarily
always
required
in
order
to
complete
payment
in
the
free
case,
as
well
as
in
some
cases
where
you
don't
need
to
put
that
in
I,
mean
I
truly
make
and
just
be
ignored.
If
it
was,
then
it's
not
necessary,
and
so
there's
a
few
options
here
and
please
do
comment
a
notice.
E
It's
already
had
a
comment
on
this
as
to
how
we
potentially
represent
a
simple
version
of
this
everything
from
just
including
0.
If
it
doesn't
need
to
be
there
to
just
not
including
anything
so
you
could
just
post
the
payments
to
say,
I'm
compelling
this
order,
although
that's
not
very
clear,
what's
happening,
and
so
yep
there's
something
in
them
and.
E
E
E
C
C
E
Sure
so
it's
really
gonna
be
a
question
of
whether
this
flow
that
we
just
talked
about
is
going
to
be
the
same
for
every
use
case
or
whether
we
want
to
allow
deviations
for
the
flow.
So
if
we
force
two
calls
and
the
same
Uli's
book,
if
it's
immediately
after
each
other
or
we
can
allow
some
variation,
I
guess,
there's
a
pros
and
cons
about
how
complicated
we
want
to
make
the
implantation
well.
C
E
E
When
you
get
your
session,
that's
getting
you
the
latest
version,
including
the
offers
and
all
the
detail,
know
when
you
get
that
you
then
can
make
that
the
post
two
orders
we
just
discussed
there
and
then
that
gives
you
the
accepted,
offer
the
order,
item
etc.
When
it's
been
created,
you
can
then
get
an
order.
You
want
to
then
follow
the
get
here
to
log
anything
that
you
want
to
about
the
status
of
it
or
what
it's
come
back
with
in
terms
of
the
amount
price
and
then
post
to
payments
to
complete
the
order.
C
C
C
E
And
then
I
thought
the
other
thing
that
might
be
worth
highlighting
here.
So
that's
that
there
are
the
steps,
just
a
few
of
the
of
the
kind
of
principles
of
the
way
that
this
is
constructed
just
to
check
your
feedback
on
this
as
well.
And
so
this
is
a
list
of
different
things
that
they're
kind
of
suggesting
as
part
of
this,
the
way
that
the
responses
are
constructed
so
is,
if
you
feel
free
to
jump
in
the
thoughts
as
we
just
run
through
these
quickly.
E
So
there's
that
and
there's
as
mentioned
here
when
you
reference
something
there
when
you're
passing
it
in.
You
then
use
that
same
ID
to
say,
yeah,
we're
gonna
use
that
we
want
to
use
that
particular
session.
There's
two
using
two,
your
ones
so
using
tier
ones,
is
what
I
mentioned
it
does
increase
the
number
of
calls
that
you
make
that
argument
more
restful,
and
so,
when
you
make
a
post,
you
don't
get
anything
back
from
that.
You
have
to
make
a
further
call
to
get
whatever
it
is,
that's
being
created.
E
If
you
want
to
check
the
status
of
it,
I
suggested
adopting
the
JSON
API
pagination
for
anything
that
doesn't
need
needs
pagination
that
doesn't
need
comic,
RPD,
real-time
pagination,
just
for
standard
kind
of
paging
and
such
as
search
results
and
Jason.
Api's
got
a
patent
for
this,
which
is
the
next
and
last
and
self
pages
has
links,
and
then
the
data
within
a
data
block
like
this,
also
in
the
same
way
for
anyone.
E
That's
returning
data
isn't
as
an
array
rather
than
just
return
the
raw
array,
including
a
data
property,
but
then
includes
the
array
which
then
allows
you
to
extend
later.
If
you
want
to
around
the
data
property
a
lot
of
the
things
making
sure
that
we
use
types
in
both
the
responses
and
the
requests
to
ensure
that
we
have
this
kind
of
extensibility
in
the
future
for
an
add,
additional
types
also
means
everything.
E
Validated
schema
door,
which
is
handy
for
validation,
tools
means
we
can
switch
on
types
and
things
like
that,
making
sure
that
we
use
schema.org
for
properties.
If
we're
doing
research
so
slash
sessions,
query
gender
restriction
equals
male
rather
than
just
gender
equals
male,
which
just
is
more
expressly
schema.
E
As
timezones
kuanysh
each
one
but
using
time
zone
suggesting
to
actually
include
the
time
zone,
if
there
is
one
with
the
in
the
start
date
rather
than
link,
we
know
as
a
separate
property
just
because
it
allows
you
to
render
an
actual
event
in
local
Tommy
coupon
or
in
UTC.
If
you
want
to
and
then
there's
this
miss
action
block,
which
is
basically
a
way
of
saying
and
I
think
it
might
be
included
in
the
swagger
as
well.
E
So
let
me
show
you
instituting
this
many
more
somes
in
the
actual
block,
if
you're
getting
a
session
and
there's
buttock,
and
you
can
book
that
session
there's
now.
This
is
a
potential
action
here.
This
reserved
action
allows
you
to
book.
So
that's
that's
specified
like
that.
So
you
can
go
ahead
and
use
that.
E
Yeah
we're
using
reservation
and
then
reservation
as
a
schema
type
to
represent
the
actual
thing
of
booking
us,
sorry
that
reservations
being
created
by
the
booking.
If
we
need
to
represent
that
separately,
for
example,
the
order
might
contain
a
number
of
reservations
and
so
society
to
include.
We
look
at
that
in
more
detail
and
another
point
and
yeah
finally
making
sure
that
we
consistently
use
the
scheme,
the
old
customer
concept
so
representing
the
customer
using
the
schema
terms.
E
C
Yeah
Nick
Nick
here
again,
we've
we've
done
some
stuff
with
non
UK
clubs
and
and
UTC
is
something
we
wish
we'd
thought
about.
When
we
build
a
platform
in
the
first
place,
because
we
had
to
rebuild
the
whole
bloody
thing
so
yeah
go
for
UTC
and
as
you've
put
it
so
that
you
can
just
strip
out
the
timezone
display
in
local
local
time
for
that
provider.
C
But
I
would
have
a
clear
strategy.
I
mean
we've
come
to
the
conclusion
that
you
need
to
display
times
in
the
local,
in
the
clubs,
local
timezone,
and
so,
if
you're
in
France,
you
actually
want
to
see
the
time
in
the
in
UK
time,
even
if
your
location
isn't
in
the
UK,
because
actually
that's
the
location
is
linked
to
the
time
of
that
event.
E
If
we
do,
if
we
going
with
the
strategy
here
means
we
can't
easily
order
by
the
content
of
this
field,
we'll
have
to
have
a
separate
field
so
I
suppose
there
is
an
argument
for
splitting
out
time
zone
as
a
separate
field
so
that
we
can
do
in
order
by
on
this
field
and
that
kind
of
trade-off
in
complexity.
Here
was,
if
you
put
x
in
as
a
separate
field,
not
some
libraries,
don't
let
you
easily
do
that
and
kind
of
combine
time
zone
as
a
separate
field
and
UTC
time.
C
Stamp
we
record
everything
in
our
back-end
in
UTC.
All
the
clubs
have
to
choose
their
own
time
zone.
We
do.
The
front-end
is
responsible
for
for
rendering
it's
just
a
pain.
Frankly,
but
you
know
do.
E
C
This
is
work
it's.
This
is
where
it
gets
interesting.
We've
got
peak
and
off-peak
times
for
badminton
which,
where
we're
having
to
saw
the
local
time
zone
the
local
time
in
the
central
database,
because
actually
peak
and
off-peak,
doesn't
make
sense
in
UGC
in
the
morning.
In
the
local
time
zone,
there's
like
when
storing
it
is
7
o'clock
for
some
of
the
year.
C
I,
don't
know
what
your
moment
has
a
word
for
it
moment
chairs,
but
yeah,
it's
the
sort
of
time
zone,
it's
just
yeah
local
time
zone.
What
you
would
say
on
your
watch
yeah.
C
E
C
There's
another
another
issue
that
again,
we
believe,
we've
kind
of
learnt
about
cost
the,
when
you're
doing
filtering
with
your
opportunity.
Endpoint.
If
you
pass
in
dates,
you're
assuming
a
time
zone
or
you're,
actually
restrict
your
you're
restricting
and
what
you
actually
get
back
so
input
queries
need
to
be
in
a
time
zone
or
in
UTC
as
well,
ideally
UTC.
So
it's
up
to
the
client,
the
client
for
the
API
to
convert
to
UTC
and
then
ask
you
for
the
range
within
those
UTC
start
and
end
dates
times.
E
C
E
C
E
E
E
A
G
A
That's
in
the
the
booking
0.4
version
with
the
booking
standard,
I
email
back
to
the
list
earlier:
okay,
what
I'm
gonna
do
is
I'm
gonna,
so
I've
been
we've
been,
including
the
links
to
some
of
these
documentation
in
the
slides
which
I've
been
circulating
after
the
calls.
But
what
I'm
gonna
do
is
I'm
going
to
post
the
links
to
the
cumulative
blog
so
that
they're
a
bit
more
readily
available
for
everyone.
So
there's
a
common
reference
point:
yeah.
E
F
F
I'm
just
wondering
what
other
other
people
thought
about:
the
increased
network
traffic
and
that
sort
of
thing
when
before,
when
you
did
a
post,
you
got
the
order,
details
back
in
the
body
and
it
just
feels
like
okay.
It
might
not
be
the
most
resti
solution,
but
saving
saving
everyone
doing
extra
calls
and
adding
that
slight
delay
to
everything
else
and
complexity
in
code
and
whatnot.
G
F
E
E
Yeah,
so
I
I
I
don't-
I
don't
really
have
a
take
on
this
other
than
I
know
that,
there's
a
bit
of
a
slight
kind
of
conflict
between
restful
correctness
and
efficiency,
which
is
why
Google
created
gbg
RPC
info
for
all
their
traffic,
because
they
obviously
fed
efficiency,
I
suppose,
because
we've
gone
with
restful
as
our
kind
of
philosophy.
Maybe
we
are
making
the
decision
here
to
and
as
probably
just
quite
important
to
flag.
That's
the
decision,
we're
making
to
opt
for
correctness
and
and
in
a
design
over
potential
of
network
efficiency.
E
Look
is
obviously
doubling.
The
number
of
calls
in
every
for
every
booking
across
systems
has
a
effect
on
well
the
whole
the
whole
ecosystems
traffic
overall.
But
if
we're
consciously
doing
that
because
of
the
design
decisions
were
making
I
guess,
that's
that's
just
something
to
bag,
and
then
we
can
be
aware
that
we
made
this
point
here
when
someone
else
says
what
we're
making
on
four
or
five
calls.
A
A
Because
otherwise,
if
we're
going
to
optimizing
to
minimize
network
traffic,
we'd,
probably
make
a
whole
bunch
of
different
decisions,
you
know
we
might
just
have
one
or
two
post
endpoints
go
into
binary
format
rather
than
than
Jason.
You
know
and
kind
of
optimize
for
that
there's
where
some
of
these
I'm
just
suggesting
some,
where
this
was
flagged
before
in
another
context,
but
there's
other
guidance
that
we've
put
in
place
to
help
reduce
kind
of
traffic.
A
You
know
encouraging
GZ
and
compression
of
responses
to
minimize
what's
been
sent
over
the
wire
and
one
thing
specifically
around
the
the
two
one
created
pattern
in
the
response.
It
is
possible
to
return
an
e-tag
so
that
the
request-
and
he
starts
going
to
get
requests
to
the
resource-
can
be
a
conditional
request.
So
they
might
actually
not
be
a
response,
so
they're
still
a
HTTP
request,
but
they
might
just
end
up
with
a
content
that
makes
sense
how.
E
A
When
you
get
back
so
in
a
in
a
201
created
response,
so
we
concluded
a
location
header
alongside
that
location
header,
you
can
give
an
e-tag
for
the
current
version
of
the
resource.
That's
been
referenced,
just
been
created
so
that
that
immediately,
when
you
do
a
get
request
on
that
resource,
you
can
include
that
etag
as
a
conditional
request.
So
you
might
end
up
then
not
have
a
you
know
might
not
have
to
actually
serialize.
When
we
pass
a
response.
You.
E
E
E
Okay,
sorry,
if
that's
there,
this
is
a
derating
question
yeah.
So
there
might
be
a
thing
about
conditional
responses
to
be
discussed
and
explained
just
in
terms
of
time
somewhere
with
knowledge
Don.
This
I
think
Nick
Bailey.
This
I
know
you
were
talking
earlier
about.
Maybe
we
should
have
a
pattern
where
you
only
make
one
request
to
make
a
booking
rather
than
two
requests
where
you
know
for
the
payment.
So
maybe
there's
just
a
one-off
reserve
request
I
feel
like
if
we're
going
to
adopt
the
principle
that
we
want.
C
F
C
Think
that
I
think
one's
a
use,
K
one's
a
kind
of
customer
use
case,
whereas
ones
and
the
other
ones
more
about
network
hygiene,
I
think
they've
got
two
different
drivers.
I
don't
see
any
reason.
Time
came
for
a
single
request
is
I.
Think
that's
what
essentially,
our
customers
are
asking
for
it
on
other
api's.
E
Okay,
do
you
wanna
crack
only
with
the
last
bit.
A
Yeah,
just
very
briefly,
and
so
just
maybe
just
wrap
up
that
that
bit
so
we're
doing
some
more
work
on
the
0.4
spec.
The
intention
is
to
move
out
some
of
these
issues
and
discussion
points
into
github
issues
so
that
we
either
to
kind
of
comment
on
and
keep
a
kind
of
history
around
what
decisions
were
making.
A
A
So
we
just
need
to
kind
of
perhaps
clarify
what
some
of
the
processes
around
how
those
proposals
get
raised
during
the
community
and
then
how
they
end
up
with
moving
through
to
changes
to
the
specifications
so
to
help
address.
Some
of
that
I've
put
together
a
document
that
puts
of
just
a
bit
of
context
to
how
we
work
as
a
group.
A
What
the
kind
of
guiding
principles
are
around
us
trying
to
work
in
the
open
and
kind
of
collaborate
to
create
openly
licensed
specifications,
and
in
that
document
it
also
spells
out
the
process
for
raising
new
proposals
for
change
to
the
specifications.
So
the
what
I
was
suggesting
earlier
is
that
I've
worked
with
them
to
get
a
proposal
together
around
virtual
activities
and
I'd
like
to
get
some
of
the
other
things
that
we've
been
discussing.
A
Spells
out
a
kind
of
bit
more
of
a
release
process,
a
bit
more
rhythm
for
pushing
forward
on
the
specifications
so
trying
to
get
into
practice,
doing
more
regular
editor's
drafts
for
people
to
comment
on
and
aim
to
do
point
releases
of
call
specifications
every
two
months.
So
we'll
aim
to
do
a
1.1
release
of
the
opportunity
model
and
the
paging
specs
the
end
of
April
and
then
1.2
at
the
end
of
June.
A
A
And
the
idea
there
is
that
we've
got
the
saying,
regular
rhythm,
but
it
allows
us
to
kind
of
move
forward
at
pace
where
we've
got
new
requirements,
but
also
for
anyone,
that's
kind
of
slow
moving.
Then
they
can
choose
to
start
to
adopt
kind
of
stable,
well
versions,
additions
of
the
specs.
So
although
this
is
kind
of
outlined
in
the
document
on
the
mailing
list
earlier,
it's
only
for
comment.
If
anyone's
got
any
feedback
on
it,
then
please
either.
Let
me
know
or
leave
a
comment
on
the
dock.
A
Otherwise
we're
just
going
to
start
to
kind
of
adopt
that
going
forward.
I
know,
there's
anything
hugely
different
to
the
way
they've
been
working.
It's
just
really
just
kind
of
documenting
the
kind
of
informal
processes
we've
been
following,
but
we've
got
to
the
kind
of
size
now
and
size
of
the
group
and
the
number
of
kind
of
parallel
things
we're
doing
that.
We
kind
of
needed
that
reference
point.
So
that
was
it.
Anyone
got
any
questions
about
that
anyone's
had
time
to
look
for
the
doc
yet,
but.
A
Okay,
if
not,
then
we'll
wrap
up
the
call
where
our
next
one
is
on
the
25th
of
April.
We
plan
there
is
to
address
any,
have
a
discussion
with
us.
Any
final
comments
on
what
will
be
the
1.1
version
and
specifications
that
will
get
published
at
the
end
of
the
month
and
probably
a
more
another
review
of
some
of
the
issues
around
the
booking
specification
for.
E
A
Okay,
right,
okay,
thanks
everybody!
Then
then
we'll
wrap
up
the
call,
as
always,
there's
great
great
that
you
will
give
up
your
time
to
kind
of
move
this
discussion
forward.
It's
really
helpful
and
making
sure
that
we
got
some
good
quality
outputs
and
please
do
take
time
to
look
through
some
other
documentation
that
we've
shared
and
chip
in
with
your
feedback
and
thoughts.