►
From YouTube: OpenActive W3C Community Group Meeting / 2018-09-12
Description
A public hangout for members of the OpenActive W3C Community Group.
Agenda and summary: https://w3c.openactive.io/meetings/2018-09-12-booking-api-1.0
For more information visit: https://www.openactive.io/w3c-community/
A
A
Okay,
I
think
I
think
we
should
make
start
so
that
we've
got
time
to
discuss
couple
of
things
today.
So
thanks
everyone
for
joining
the
call.
As
always,
it's
very
useful,
to
have
these
more
dynamic
chats
than
just
discussing
issues
through
github
helps
just
to
work
through
some
of
the
wrinkles
in
a
bit
more
detail.
So
I'll
just
share
the
slides.
A
The
terms
of
agenda
today,
I
just
wanted
to
give
you
a
quick
update
on
where
we
are
with
the
booking
work
and
highlight
one
of
the
key
changes
to
the
spec
for
the
1.0
draft
that
was
published
earlier
today,
and
then
just
talk
about
one
of
the
issues
that
has
come
up
in
the
feedback
on
the
2.0
specification,
which
you've
got
no
modelling
spec.
And
then,
if
we
have
time,
we
can
go
anything
else
that
people
to
discuss
today.
B
A
But
the
work
has
no
largely
been
done
and
I
sent
an
email
to
Maine
yes
this
morning,
just
to
let
everyone
know
that
there
is
a
1.0
draft
now
available.
I
provided
a
summary
of
the
changes
to
the
list,
but
there
which
has
got
more
detail.
But
for
me
there's
basically
three
main
things
just
to
kind
of
let
people
know.
A
The
first
is
that
there's
been
some
reworking
to
the
request
response
formats
based
on
some
discussions
that
we've
been
having
in
the
team
here
and
some
discussions
that
we
had
on
one
of
the
calls
couple
weeks
ago-
and
this
is
largely
to
make
the
response
is
slightly
less
verbose,
ain't.
It
correct
a
couple
of
the
properties
that
were
using
so
that
they
were
aligned
with
the
rest
of
the
specification
and
also
schema.org.
So
that's
largely
just
evident
in
changes
to
the
the
examples
in
the
doctorate.
A
In
looking
at
the
the
cancellation
workflow.
We
realized
that
we
had
overlooked
one,
which
is
the
kind
of
the
new
section
that
appears
in
the
spec.
So
we
had
in
those
0.8
draft.
We
had
a
mechanism
for
how
a
broker
could
cancel
a
booking
on
behalf
of
a
participant,
so
they
could
say
they
no
longer
want
to
attend
and
they're
in
the
1.0
spec.
A
There's
some
clarifications
in
there,
so
that,
for
example,
it's
possible
for
a
platform
to
indicate
when
canceled,
until
when
cancellations
can
be
accepted,
so
specifying
a
window
within
which
somebody
could
change
our
mind.
Otherwise
they
come
have
committed.
But
what
we
hadn't
documented,
which
is
really
just
an
oversight,
is
that
there
are
occasions
where
the
booking
system
needs
to
cancel
an
event.
The
organizer
might
have
decided
that
they
can
no
longer
run
it
or
a
facility
might
have
to
be
closed
for
some
reason.
So
what
we.
A
So
we
hadn't
really
thought
through
how
that
interaction
happens.
So
how
does
the
booking
system
update
the
broker
detent
so
that
everyone
is
clear
that
event
has
been
cancelled?
The
booking
system
can
only
update
a
customer
because
they
have
the
customer
details
as
part
of
the
booking.
So
they
can,
you
know,
send
an
email
or
give
them
a
call
or
whatever
good
to
let
them
know,
but
it's
important
that
the
booking
system
be
able
to
update
the
broker,
because
it's
the
broker
that
is
responsible
for
taking
payment
and
handling
refunds.
A
So
there's
a
in
the
draft
document
that
I
circulated
earlier.
So
this
just
looking
at
the
1.0
draft,
which
is
dated
today,
there
is
a
new
section.
It's
currently
five
point,
six
point:
two,
which
is
booking
system
originated
cancellation.
So
this
goes
into
a
bit
more
detail
about
what
how
we
visit
this
workflow
happening
and
I
just
wanted
to
go
through
it
at
a
high
level.
A
Now,
on
the
call
just
to
see
if
anyone
had
any
feedback,
I'll
say
at
the
start
that
there's
this
section
of
the
spec
needs
a
bit
more
detail
going
into
it.
But
we
wanted
to
put
some
draft
text
out
for
discussion
before
getting
into
providing
examples.
So
this
needs
to
be
revised
to
just
give
some
examples
of
what
the
API
calls
would
look
like
between
the
booking
system
and
the
provider
can.
C
I,
throw
in
a
comment
lis
by
the
way,
hello,
everybody,
hi
I'm
in
here
information,
remember
about
counseling,
an
order
and,
whilst
I
recognize
at
the
moment
the
intent
is
to
only
have
one
booking
per
order
in
version
one
point
not
allots
you'll
be
able
to
have
multiple
bookings
in
an
order
when
you
tippet
counts
all
the
bookings.
So
some
of
my
book,
a
badminton
court
at
3
o'clock
at
a
swimming
session
at
6
o'clock,
only
women's
will
get
canceled
sort
of
only
Lera.
A
A
We've
also
said
that
they
should
also
then
update
the
booking
system
to
indicate
that
that
refund
has
taken
place,
and
the
reason
for
that
is
to
make
sure
that
both
ends
of
the
communication
are
clear,
that
it
is
transparent
that
that
has
happened
so
that
whoever
is
engaging
with
the
customer
or
whether
the
customer
chooses
to
to
approach
about
refunds.
Everyone
has
the
right
information.
A
A
D
A
It's
specified
as
an
array
to
give
flexibility.
If
the
booking
system
wanted
to
just
send
out
an
update
for
each
one.
As
it
happens,
that's
fine
there's,
no
assumption
that
you
would
you
would
patch
them
up.
This
is
just
where
an
example
of
examples
which
we
haven't
gotten
here
yet
would
make
that
clearer.
I
think.
C
The
use
case
for
me
is
where
you've
got
the
pulls
out
all
the
Jim's
out
and
there's
actually
five
or
six
different
people
booked
in
there.
So
you'd
actually
want
to
say
this
resource
is
not
free
anymore.
These
are
the
things
affected
and
that
will
probably
be
an
array
of
borders
and
likely
be
easy
to
implement
that
by
Ison,
my
lats
at
once,
and
it
would
be
by
actually
sending
out
individual
requests.
I
get
the
point
of
that.
Obviously,
you
could
equally
well
just
send
out
individual
requests.
Yeah.
A
Yeah
I
mean
we're
aware:
I've
implemented
these
in
the
past.
I
think
that
usually
we
want
some
flexibility
about
whether
you
you
know
immediately
on
a
state
transition
in
your
you
know
your
database
or
platform
to
send
an
API
call
or
whether
you
just
want
to
send
those
out
every
five
minutes.
Ten
minutes
hourly,
depending
on
what
notifications
there
are
so
I
think
this
just
gives
a
bit
a
bit
bit
of
flexibility,
both
sides,
if
we
yeah.
D
D
B
D
A
D
A
B
The
replay,
so
if
you,
if
you,
if
you
know,
there's
been
a
problem,
you
could
go
back
and
replay
it
in
some
way.
The
other
way
than
the
way
I
think
the
Nixon
place
is
kind
of
difficult,
because
it's
unfair
I
feel
on
the
booking
thing
to
have
to
keep
trying
to
send
all
the
stuff
it.
It
should
be
down
to
the
consuming
one
to
try
and
go
get
the
information
back
again.
At
some
point,.
A
Yeah
yeah
I
just
went
to
go.
What
would
what
would
be
the
expectation
on
the
broker
that
they
should
be
regularly
poling
for
cancellations
in
just
in
case
they
missed
any
webhooks,
because
if
you
did
it
that
way,
then
you
we
could
not
use
a
web
hook
and
just
require
just
put
that
requirement
on
a
break
anyway.
Well,
I'm,
just
thinking.
B
So
like
a
safety
thing
would
be
so
you
get
me
the
workbook.
That's
fired
on
the
state
change,
for
example,
but
then
you
might
have
this
almost
like
a
best,
but
the
supposed
to
be
like
a
checksum
in
the
sense
that
you
could
then
go
and
poll
it
at
the
end
of
the
day.
They'll
call
all
the
translations
and
you
can
reconcile
them
or
in
case
you
mr.
C
Yeah
I
think
it's
a
question
of
ownership,
really
I.
Think
if
you're
saying
it's
the
brokers,
responsibility
to
poll,
it's
very
difficult
to
police,
that
yeah
there's
no
way
I'm
going
to
write
software
or
a
light
system
that
helped
us
checks
every
day
to
make
sure
it's
been
pulled
every
how
it's
just
not
going
to
happen.
I
think
that
would
be
even
more
true
for
smaller
providers
or
operators.
C
Whereas
if
we
say
you
know,
if
we're
going
to
send
information
to
the
broker,
then
we
know
there
has
to
be
webhook
and
if
there's
not
a
web,
but
we
can
say
we're
not
doing
it
yeah
and
therefore
gives
us
some
control
of
knowing
that
they've
got
some
some
process
in
place
rather
than
passive
about
it.
So.
C
Think
well,
I
think,
to
start
with,
we
could
assume
and
I
think
that
if
we
don't
get
a
response
back
we're
going
to
send
it
again.
Perhaps
we
need
to
have
some
ID
within
it
to
say
this
is
the
you
know.
This
is
a
batch
we're
sending
and
if
it
gets
received
twice
the
the
broken
not
to
press
it,
the
second
time
and
but
it
would
mean
that
there's
some
owners
do
a
retry
process
on
the
part
of
the
provider.
D
And
enable
that
Ida
potent
there's
a
name
for
that
toggle
ideas
in
there.
That
sounds
like
a
really
good
idea,
especially
if,
if
the
things
can
get
refried
Walden,
while
some
processing
could
fail
for
a
number
of
reasons,
I
don't
know
how
many
times
we
really
expecting
the
reach
writer.
So
let's
say
that
let's
say
a
broker
goes
down
for
for
a
five-minute
period.
For
example,
would
we
be
expecting
the
booking
system
to
retry
that
web
book?
Oh
for
our.
D
C
There's
no
right
answer
to
this.
It
depends
what
we
do
in
situations
like
this.
It
kind
of
have
a
back
off
tap
situation,
so
try
again
in
a
second
try
getting
in
a
minute.
Try
get
in
ten
minutes.
Try
getting
twenty
minutes,
trying
there
now
and
a
half
give
up,
and
when
you
give
up
have
some
kind
of
alert
that
shows
what's
going
on,
because
he
may
mean
the
brokers
got
out
business
yeah.
That's
really
good!
That's
good!.
D
C
Know
and
I
think
the
also
I
think
there's
I
think.
The
final
scenario
is
that
you
might
have
just
a
manual
processing
yeah
this.
This
with
any
software
system
is
always
some.
You
can
deal
with
manually,
so
I
think.
If
you
can't
get
hold
of
a
system
for
a
day,
then
you
can
solve
that
with
a
manual
process.
That's
the
broker
to
implement
something
that
can
manually
say:
oh
I,
haven't
of
these
pills
being
canceled,
maybe
not
sure
about
that.
One
yeah.
A
D
Might
help,
but
this
is
that
the
opportunity
API
or
at
least
at
least
I,
think
part
of
bookings
back
in
fact
defines
an
orders
endpoint,
which
is
already
queryable.
So
you
can
already
request.
You
can
already
do
a
get
request
on
orders
to
get
a
list
of
orders.
You
can
in
then
implicitly
filter
those
orders
by
parameters
and
so
wouldn't
be
a
huge
amount
of
extra
work
to
say
you
can
filter
those
orders
by
status
and
then
any
other
cancellations,
I
guess.
There's
a
challenge
here
about
well.
D
Ian
said
earlier:
if
there's
items
within
the
order
of
cancels
and
then
how
do
we?
Because
you
could
have
the
same
order,
canceled
twice
for
two
different
items
and
then
maybe
it
just
appears
once
with
timestamps
saying
these
are
latest.
This
is
the
latest
status
its
cancelled,
and
so
you
can
get
that
get
that
feed.
That.
A
Might
work,
although,
if
we're,
if
we're
attaching
a
kind
of
unique
ID
to
something
so
that
the
request
can
be
idempotent,
it
would
be
like
the
notification,
so
I
think
you'd
have
to
have
a
an
end
point
which
was
give
me
the
list
of
notifications.
You've
tried
to
send
me
with,
so
you
can
if
I've
missed
them.
My
web
book
endpoint
was
damned
and
I
can
attempt
to
replay
them.
D
A
B
Sorry,
who's
who's
building
the
book
consistent,
there'll,
be
lots
of
distributed,
potentially
do
booking
systems
as
well
yeah
mm-hmm.
So
it
sounds
like
you're
putting
an
awful
lot
of
effort
on
the
person
in
the
booking
system
to
or
the
organization
to
have
to
keep
sending
out
all
these
things
all
the
time
so
I
was
sorry.
I
was
kind
of
looking
at
it
more
more.
The
consumer
should
take
on
the
effort
if
they
want
to
be
taking.
B
You
know
if
they're
broke
they're,
doing
a
brokerage
they
should
be
taking
on
the
effort
or
checking
whether
a
booking
has
been
cancelled
and
reconciling
in
their
own
systems.
Ultimately,
the
booking
system
is
the
canonical
source
of
whether
something
has
been
booked
or
has
been
cancelled,
and
then
the
other
systems
would
poll
that
and
pull
that
information
back
to
update
their
systems,
because
they
also
might
want
to
tweak
how
they
inform
the
customer
that
the
work
has
been
cancelled.
Wouldn't
they.
D
This
is
exactly
the
same
problem
that
the
RP
Det
and
the
whole
conversation.
We
went
through
the
synchronization
between
two
systems,
so
you've
got
you've,
got
the
booking
system
and
then
you've
got
the
broker,
and
you
want
to
make
sure
that
you've
got
a
synchronized.
Well,
there
are
PDE
design
was
for
a
synchronization
of
the
activities.
You
can
get
everything
to
be
synchronized.
The
reason
that
was
a
good
idea
in
that
case
was
because
of
open
data
because
it
couldn't
be
a
web
book.
D
It
had
to
be
polling
so
that
it
could
be
open,
which
then
leads
you
to
that
type
of
design.
Suppose
this
isn't
open
data
because
it's
orders
it's
cause
of
its
have
credit
cards
and
all
that
kind
of
stuff.
So
it's
all
authenticated
and
it's
on
a
per
broker
basis,
slightly
different
use
case
and
I.
Guess
that's
why
we
have
the
option
I
feel
like
we're,
having
basically
a
little
bit
of
the
same
conversation,
which
is
good
so
there's
both
options,
available
of
webhooks
versus
polling
and
I.
B
A
So
we're
not
specifying
a
authentication
mechanism
in
there.
Okay
it'll
be
up
to
them,
but
the
way
that
whether
there's
discussion
to
be
had
about
how
much
detail
you,
if
we're
using
web
hooks
or
a
notification,
feed
or
some
form,
there's
a
question.
If
you
had
about
how
much
detail
you
put
in
that
one
approach
is
that
you
just
provide
the
minimum
amount.
A
You
know
a
status
update
and
the
relevant
IDs
for
the
things
that
have
been
changed
and
then
you,
the
broker,
would
then
use
the
existing
API
calls
that
we've
documented
in
order
to
get
further
information.
So
that
means
we
wouldn't
have
another
endpoint
that
could
be
feeding
out.
Customer
information,
I
can't
say
I'm
kind
of
preferred
that,
because
it
keeps
the
kind
of
API
surface
a
bit
smaller.
D
D
So
it
sounds
like
the
trade
off
then,
if,
if
that's
not
thing
is
either
sending
these
notifications
then
create
more
traffic
on
the
API
to
get
each
response
as
a
result
or
a
feed
approach.
Where
all
that
data
is
just
in
the
feed
and
you
just
rpg-style
just
get
the
stuff
and
then
you
just
you
just
consume
it.
So
I
feel
like
of
those
two
approaches.
It
might
actually
be
easier,
well,
I,
suppose,
what's
basically
easier
for
the
booking
system
to
implement.
D
C
The
from
a
I'm,
not
sure
I
can
say
this
but
kind
of
vaguely
technical
perspective
city
for
the
legend,
we've
got
the
the
cash
for
the
feed,
but
it's
not
specific
to
who's
booked
through
what
so
we
know
that
there's
five
places
left.
We
know
there's
17
books,
but
we
don't
really
know
which
individuals
have
booked
them.
I
mean
that
just
in
terms
of
an
ID
or
something-
and
we
certainly
don't
know
at
that
point
what
the
mechanism
was
for
being
bought,
what
they
particular
broker
was.
C
So
you
know
that's
quite
a
lot
of
additional
information
to
put
into
the
the
cache
because
she
actually
have
to
cash
all
the
bookings
individually
as
broad
as
the
quantities
that
are
remaining
and
that
feels
to
me,
like
wild,
have
overhead
compared
to
some
I
guess
queuing
system.
For
this.
These
events
I
mean
council,
go
and
tell
the
relevant
rockers,
because
that
week
and
I'm
phoning
about
other
information.
Well,
the
cached
information
yeah.
A
B
D
C
Prefer
that,
and
one
of
the
reasons
refer,
this
is
because
constellations
be
quite
short
notice.
Yes,
so
if,
if
you
from
from
a
operators
perspective,
if
there's
a
cancellation,
we
want
people
to
be
informed
within
minutes,
ideally
rather
than
informed
sometime
that
day.
So
you
might
have
some
it's
an
hour
away,
but
it's
been
canceled
and
if
you
have
a
web
hop,
you
can
inform
the
booking
system
that
the
broker
immediately
yeah,
whereas
if
the
broker
is
actually
calling
you
on
this,
for
you
don't
really
have
any
control
over
over
the
latency.
A
B
A
C
Also,
a
lot
of
the
prism
providers.
Don't
nestle
have
the
mechanism
to
support
that
notification.
So
you
know
a
lot
of
a
lot
of
our
clubs.
Do
it
manually
the
phone
people
up
which
converse
you're
not
possible
through
a
broker,
but
I
think
there
may
be
challenges
in
getting
that
implemented
in
the
short
term,
but
I
think
it's
good
to
have
it
spec.
D
D
It
gets
pushed
by
back
into
the
person's
bank,
account
as
a
whole,
and
it
goes
through
head
office
and
what
kind
of
stuff
and,
however,
interesting
me
when,
when
given
the
option
of
using
tokenization
on
a
credit
card
which
they
can
do
vice
stripe
for
the
booking,
they
actually
were
keen
to
do
that
because
it
saves
them
head
office.
Headache
to
do
it
that
way
so
and
I
mean
at
least
they.
They
would
use
this
feature
if
it
was
available,
in
addition
to
their
existing
process,
that
they
have
other
types
of
cancellation.
A
C
Are
the
things
that
was
something
else
which
I
don't
know
if
it's
a
concern
or
not,
but
I'm
not
sure
that
the
refund
process
amount
or
anything?
That
sort
will
be
quite
the
same
for
a
cancellation
initiative
by
a
customer's.
Remember
so
within
legend,
for
example,
we
might
obviously
this
cancellation
time
the
endpoint
you
can't
slough
for
that
you
don't
get
anything,
but
we
could
apply
penalties
and
it
may
be
that
the
cancellation
charge
is
less
than
the
actual
charge
for
the
the
booking.
C
D
A
So
then
we
it's
kind
of
a
belt
embraces
that
the
web
hook
is
the
preferred
option,
but
kind
of
a
fallback
or
some
prescription
to
be
able
to
support.
You
know.
Replaying
notifications
would
also
be
useful.
It's
up
to
a
booking
system
if
they
can
are
able
to
support
both,
and
we
just
need
to
be
clear
to
everyone.
What
happens
if
you
don't
do
both?
A
C
It's
one
thing,
I
think
where
you,
you
probably
need
to
suggest
how
frequent
the
polling
should
be,
what
we
know
what
the
interval
should
be,
though
it
may
vary
a
lot
depending
on
the
provider
but
I
think
you're.
What
you're
saying
they're
effectively
zabrze
a
broker
that
wants
to
have
a
wide
remit
would
have
to
implement
both
options,
whereas
if
you
stayed
just
where
book
or
just
see
the
polling,
then
they
don't
have
to
implement
one.
A
Different
failure
modes
so
I
think
we
agree
that
the
webhook
would
be
so.
The
advantage
of
the
web
book
is
it's
more.
Real-Time
can
more
on
can
be
played
out
quicker
customers
can
get
updated
quicker.
The
downsides
are
at
the
point
that
was
made
earlier:
that's
potentially
a
lot
of
traffic
going
outbound
from
booking
system,
depending
on
how
many
brokers
they're,
using
or
using
them,
but
there's
also
opportunity
to
failure,
because
there
could
be
communications.
Failure
between
the
two
end
points,
whereas,
if
the
odds
with
polling
you
know
the
downside
is
it's
not
as
real-time.
A
C
A
A
Yeah,
so
there
is
two
passes:
how
does
the
customer
get
notified
and
how
does
them?
How
does
the
refund
happen,
I
think
was
kind
of
under
the
impression
the
booking
system
might
want
to
just
email,
the
user
anyway,
we'll
get
in
touch
them
anyway,
because
somebody
wants
to
be,
as
you
said,
it's
like
late
notice,
just
that
communication
needs
to
happen
as
soon
as
possible.
It's
more
the
refund,
but
I
think
is
the
critical
bit.
C
D
Whether
this
I
mean
it
seems
like
quite
a
big
decision
for
this
going
to
1.0
I,
wonder
whether
the
application
is
a
list
of
those
well
I
kind
of
am
within
on
the
getting
everyone
to
implement
both
it's
quite
a
big
overhead
and
also
I
can
see,
there's
a
because
the
main
downside
of
the
webhook
I
can
understand.
Is
this
real-time?
What
you
just
kind
of
laid
out
their
issue,
but
you
can
have
relatively
real-time
I
mean
close
to
real-time
polling
in
terms
of
minutes.
D
Obviously
not
it
won't
be
seconds,
but
for
this,
for
this
use
case,
I
mean
you
know
mons
over
the
online
banks
and
I
kind
of
obviously
work
in
seconds
when
you
get
the
notification
instantly
that
that
things
being
cancelled
and
I
don't
know.
If,
because
we're
talking
about
processing
a
refund
here,
people
don't
usually
expect
a
refund
to
occur
immediately.
Sometimes
it
even
takes
14
days.
So
maybe
because
it's
you
know,
that
is
the
thing
like.
So
so,
let's
assume
that
the
booking
system
emails
directly
immediately,
so
that
that
happens
as
a
notification.
D
And
then
this
is
implanted
as
a
kind
of
polling
mechanism
which
could
happen
after
it
could
take
a
day.
It
could
be,
it
could
be
nightly
if
they
want
to
process
we
if
a
broker
wants
to
process
refunds
nightly
and
they're
gonna
just
rely
on
that
email
to
notify
users,
or
they
might
want
to
do
it
every
minute.
A
Yeah,
okay,
so
I
think
the
next
steps
is
to
spell
a
pros
and
cons
of
the
different
approaches
and
make
sure
that
we
get
wider
input
on
it.
I
don't
think
we
can
publish
1.0
without
having
something
to
deal
with
this
use
case,
so
I
think
we
have
to
we'll
have
to
have
something
in
place,
because
otherwise
there's
just
a
big
gap
in
what
could
be
again
what
he's
seen
pretty
common,
so
yeah
so
I'm.
So
this
se
action
I'll
take
from
from
this
core.
We.
C
Sorry
I
just
worry
about
the
billing
side
of
this,
because
I
guess
you've
covered
that
because
with
the
web
hook
side
anyway
in
that
you
send
the
web
hook
out
and
it
comes
been
a
yes
we've
canceled
it
or
rather
tells
you
they've
canceled
it,
and
then
you
can
put
what
about
to
a
refund
notification
through,
but
that
will
be
a
refund
notification
because
against
the
billing
there
wouldn't
be
any
cash
side
of
that.
So
that
may
be
a
model
that
people
don't
really
have.
We've
got
external
payments
by
do
believe
we
have
external
refunds.
C
So
there's
this
kind
of
an
implication
there
that
we've
never
had
to
process
a
refund,
that's
handled
by
a
payment
that
wasn't
made
to
us.
Yeah
I,
don't
think
so
that
that's
just
something
to
add
to
the
the
little
mix
there
and
how
would
that
work
out
from
a
billing
record
recording
that
bill
aspect?
C
D
C
Yeah
you
know,
we've
got
to
make
is
to
create
a
refund
when
you
quit
from
the
counting
perspective.
A
refund
is
you've,
got
to
take
money
from
the
the
booking
GL
and
then
paid
out
as
cash
yeah.
So
we
could
have
to
have
some
other
side.
That
says
we
aren't
really
paying
out
of
cash.
It's
against
the
I,
suppose
the
credit
or
something
for
the
the
broker
and
I
don't
think
we.
D
D
C
B
A
As
well
I
mean,
even
if
you
said,
the
booking
system
is
going
to
notify
the
user.
The
booking
system
is
going
to
have
actually
handle
the
refunds,
so
the
broker
doesn't
have
to
do
anything.
It
still
needs
to
be
a
notification
mechanism
because,
depending
on
the
business
model
between
the
breaker
and
the.
C
A
C
A
C
A
D
C
Do
in
the
system
I
would
be
astonished
if
our
customers
support
that
out
of
the
system.
You
know
so
you
know
someone
if,
if
someone
books
and
just
I
would
only
allow
that,
generally
speaking
when
he
was
booked
in
front
of
house,
so
there's
a
member
you
know
comes
in,
you
recognize
her
faces.
I'd
like
to
put
vomiting
next
week,
I
forgot
my
wallet,
the
old,
the
old
classic
yeah.
But
you
know
them.
C
You
have
a
relationship
with
them
and
you've
got
a
reasonable
trust
that
they
will
turn
up
and
you've
got
the
bill
against
them.
You've
got
their
address.
You
can
send
the
boys
around
the
baseball
bat,
not
that
I
think
I've
customers
do
that,
but
you
never
know
yeah,
whereas
in
this
case
you'd
be
saying,
here's
someone
I,
don't
know
I
have
their
email
address
and
they
want
to
book
something
she
might
be
quite
expensive,
but
not
pay
for
it,
and
if
they
don't
turn
it,
what
recourse
do
I
have.
So
we
do
do
that.
C
C
A
Okay,
so
we've
got
maximum
50
minutes
before
I
have
to
jump
off
as
well.
So
just
to
kind
of
reiterate
that
bit
the
we've
been
doing
some
review
on
the
2.0
modeling
spec,
so
Nick
has
been
doing
a
great
job
of
going
through
looking
at
some
of
the
published
feeds
and
working
with
people
who
are
prepping
to
prepare
date,
read
new
data
releases
to
see
how
the
changes
will
impact
them.
A
There's
a
number
of
issues
that
use
files
where
we
need
some
clarifications
on
the
spec
just
to
kind
of
summarize
those
there's
a
few
areas
where
we
have
proposed
tightening
up
some
of
the
conformance
requirements
where
we
might
be
doing
that
a
bit
too
soon,
so
we're
probably
going
to
relax
a
couple
of
them
and
there's
a
couple
of
areas
where
we've
defined
properties
for
events,
but
they
should
also
be
usable
for
facilities.
So
there's
just
adding
a
bit
more
consistency
across
how
those
information
can
be
used
across
different
types
of
opportunity.
A
So
that's
just
some
fairly
minor
revisions,
one
of
the
main
things
that
I
think
oversight
is
we're
in
description.
Last
time
we
talked
about
adding
new
types
of
events
to
clarify
between,
for
example,
big
headline
events
that
are
broken
up
into
a
program
of
other
activities
over
the
course
of
the
day
or
a
couple
of
days
and
Jim
sessions.
A
So
we've
got
that
document
in
spec,
but
there's
some
edge
cases
around
how
properties
are
inherited
between
different
events
that
we
haven't
fully
documented
I'm
not
going
to
try
and
go
through
all
of
those
on
the
call.
But
there
will
just
be
some
clarifications
around
that
that
will
go
into
the
revised
drafts,
which
were
flagged
up
as
part
of
the
work
that
we've
been
doing
on
the
validator.
So
the
validators
being
useful
as
a
way
to
kind
of
work
through
some
of
these
issues
as
well.
A
So
just
to
summarize
those
some
events
or
facilities
facilities
as
well,
some
are
free,
so
you
don't
have
to
pay
to
take
take
part.
Some
events
must
be
booked
in
advance,
so
you
have
to
book
a
book,
a
slot
to
use
facility
or
you
have
to
book
a
place
event.
It
might
still
be
free,
but
you
still
have
to
reserve
your
space
and
then
some
events.
This
is
a
requirement
in
was
just
talking
about
some
event.
It
may
be
that
you
booked,
but
you
don't
pay
in
advance.
A
You
might
just
still
pay
on
the
day
now
the
the
first
one
is
already
covered
in
the
specification.
The
second
one
is
not
covered
in
spec.
We
don't
have
a
way
to
say
that
you
must
look
in
advance.
We've
just
described
ways
to
do
that
booking,
but
we
haven't
got
a
way
to
state
that
clearly,
the
third
one
is
not
it's
not
covered
and
we
haven't
actually
discussed
before,
and
this
has
mainly
come
up
because
it
seems
to
be
a
feature
that
Google
Reserve
supports.
A
So,
there's
a
there's,
an
issue
on
github
its
issue
98
in
the
data
model
specification
when
Nick
and
I
have
been
having
some
conversations
about
this.
The
I
just
want
to
quickly
run
by
you.
What
I'm
proposing
just
to
see
what
people
think
of
the
requirements
and
the
approach
so
Nick
and
I
have
been
discussing
adding
a
couple
of
extra
properties
to
capture
whether
an
event
or
facility
use
must
be
booked
in
advance
and
whether
it
has
to
be
paid
for
in
advance,
as
well
so
to
cover
these
last
two
requirements.
A
So
what
I'm
suggesting
running
this
past
Nick
for
the
first
time
is
that
we
put
those
as
properties
of
office
rather
than
of
the
event
or
the
facilities
themselves.
So
we
have
these
two
new
properties
which
can
have
values
we'll
have
a
predefined
values
of
required,
optional
or
non,
so
advanced
booking
required
means
you
have
to
book
in
advance
or
you
can't
participate.
Optional
means
you
can
book
a
space,
but
you
can
also
pay
on
the
day.
A
Non
means
that
you
can
only
pay
when
you
turn
up,
so
it's
first-come,
first-served
and
then
similar
for
prepayment.
So
a
prepayment
required
so
that
you
have
to
pay
in
advance
optional
would
mean
you
can
pay
in
advance
or
you
can
choose
to
turn
up
and
pay
on
the
day
or
prepayment
non
means
you
can
only
pay
on
the
day,
so
there
would
be
some
wording
to
ran
those
those
two
things
in
order
to
describe
how
they
interact,
but
I
think
the
key
thing
is
for
me.
A
It
seems
like
these
are
these
aspects
of
an
offer
rather
than
of
the
event,
because
there's
other
things
that
we
describe
similar
things
that
we
describe
for
our
events
such
as,
can
you
cancel
them?
How
long
you
know?
What's
your
window
for
cancellation,
that
kind
of
thing
any
thoughts
on
that
from
anyone.
D
Lots
of
reasons:
yeah,
quick,
quick,
look
at
the
Google
Reserve
for
clarity
to
have
a
model
that
maps
ours
quite
similar
in
in
some
ways
they
have
a
weird
organizer
and
location
combination.
They
call
the
merchant
the
merchant
is
so
if
you
have
GLL
as
an
organizer,
and
you
have
a
particular
ledger
center
and
Slough
yeah
whatever
it
is,
you
need
as
a
center
and
then
your
GL
ELLs,
new
leisure
center
would
be
the
name
of
the
merchant.
D
So
by
combining
those
two
as
unique
things,
you
can
create
merchants
for
Google
and
that
basically
works
pretty
well
and
merchants
then
have
services.
Services
are
kind
of
similar
to
our
events.
Service
describes
what
is
available,
what
kind
of
descriptions
images
all
the
stuff
around
it
and
then
they
have
something.
That's
quite
similar
to
our
sub
events,
which
of
the
tickets
for
the
service
and
sorry,
that's
right.
D
The
availability,
which
is
like
some
events
and
then
there's
tickets,
which
are
like
offers
within
those
so
they've,
actually
handily
Maps
I
mean
other
thing.
They
don't
essentially
is
nothing
like
schema,
but
it
does
map
the
levels
that
we
have
all
that
to
say
that
they
actually
don't
put
this
information
on
the
offer
level
on
the
ticket
level.
They
actually
do
put
it
on
the
level
below
that,
so
on
the
actually
on
the
level,
not
even
availability,
they
fit
on
the
service
level.
D
A
D
Colleague,
you're
gonna
have
lots
of
different
ways
of
doing
this
thing
because
it
would
be
more
difficult
to
control
otherwise,
so
maybe
that's
why
it
hasn't
been
put
on
a
more
specific
level
in
the
Google
reserve
model.
Those
question
here
is
well
if,
if,
if
Google
was
going
to
consume
this
information,
using
their
existing
model,
they'd
obviously
have
to
make
an
assumption
about
I.
Suppose
they'd
have
to
take
their
what's
the
word
strictest
rifted,
they
probably
to
collect
all
the
offers
together
and
then
assume
the
service
has
whatever
the
strictest
of
those
is.
A
A
B
Just
go
back
to
the
one
you
had
their
own:
it's
fake,
I,
just
don't
know
how
you
described
it.
No,
but
yeah
say
based
on
how
you've
described
it
in
that
paragraph
or
a
sentence
of
both
I
read
that
as
so,
you
can't
do
advance
bookings,
they
are
optional,
but
everything
is
required,
whereas
you
can
hit
the
book
you're
saying
that
somebody
can
actually
they
can
pay
if
I'd
quit
or
they
can
book
in
events.
If
they
do
the
paper
I've
quit.
Otherwise
they
choose
to
pay
five
on
a
date.
A
D
Think
yeah
I
think
I
think
the
reality
of
I
think
I
think
there's
that
there's
a
challenge
here
in
that
with
the
booking
implementations,
when
we,
when
we
start
rolling
this
out
as
praluent,
and
we're
really
going
to
hit
this
because
there's
two
there's
two
parts
to
booking,
which
is
the
reason
I'm
I
guess:
I
introduced
prepayment
into
this
proposal.
Rather
than
just
let
you
say,
mapping
to
Google
Reserve,
that's
a
separate
issue,
but
although
interesting
about
their
model
and
why
they've
made
decisions
they've
made
in
terms
of
why
the
requirement
is
a
requirement.
D
I
think
it's
an
interesting
one
to
include
at
this
point,
because
it
lowers
the
barrier
to
entry
for
adoption
of
the
booking
spec.
It
doesn't
require
you
to
actually
implement
payment,
which
is
potentially
a
whole
other
world
of
pain
for
people
to
get
their
head
around.
You
could
turn
it.
You
could
take
a
box
and
just
allow
people
to
take
online
bookings
that
don't
require
prepayment
pretty
easily
without
needing
to
get
additional
kind
of
some
integration
with
strive
for
an
account
set
up
with
them
and
all
the
rest
of
it
and
reconciliation.
D
A
If
you
can
comment
on
this
issue,
be
useful,
is
where,
as
new
per
se,
if
this,
if
these
things
are
these
options
around,
whether
advance
booking
is
required
and
whether
prepayment
is
required
or
you
know
you
can
pound
the
day.
If
that's
a
policy
thing
is
that
there
going
to
be
a
policy
of
the
organizer
rather
than
of
applies
to
all
of
their
events?
If
so,
then
it's
something
that
could
be
presented
elsewhere,
rather
than
cascading
them
to
the
offers.
D
So
I
think
the
idea
what
that
was
that,
like
you
say,
there
are
a
lot
of
things
that
we're
likely
to
want
to
put
into
the
offer,
such
as
cancellations
such
as
terms
and
conditions
such
as
all
this
kind
of
stuff,
which
is
it
for
the
99%
case,
probably
is
standard,
because
it's
unlikely
that
you
know
our
parks.
For
example,
they
will
just
have
a
policy
for
all
of
their
events.
It's
unlikely
they'll,
do
it
individually.
D
So
the
idea
that
we
could
put
it
in
organizer
also
means
that
you
could
put
that
out.
A
band
of
the
feed
if
you
wanted
to,
but
but
the
advantage
of
doing
it
with
a
kind
of
offer
type
template
type
thing
is
that
we
can
put
it
in
the
offer
model,
but
then
put
the
information
somewhere
else.
Basically,
the
best
of
both
worlds.
D
A
D
Might
say
would
be
if
you,
if
you
put
it
on
putting
it
on
offer,
makes
makes
a
lot
of
sense
if
there's
a
mechanism
of
specifying
it
more
generally,
so
it
can
be
inherited,
which
you
can
already
do
with
offers.
Actually
you
can
already
inherit
you
can
already
in
here
it
offers
for
events.
Can
you
so
and.
A
I
need
the
whole
offer
that
this
kind
of
partial
thing
is
to
be
heavily
following
through
okay,
okay,
so
I
apologize
I
need
to
wrap
this
up
quite
quite
quickly.
It
has
been
again
it's
been
really
useful.
Discussion.
I
will
take
an
action
to
send
an
update
after
this
afternoon
to
the
list
and
ask
people
to
comment
on
specific
issues
and
discuss
the
proposals
in
a
bit
more
detail.
So
we
can
move
this
forward.
A
The
plan
is
to
try
and
get
the
the
modeling
spec
done
and
released
there's
a
kind
of
candidate
spec
in
not
today
and
tomorrow,
and
we
might
need
to
just
give
people
a
little
bit
more
time
if
we've
got
these
issues
still
open
the
booking
spec.
The
idea
was
to
give
that
a
few
more
weeks
to
kick
the
tires
on
it,
which
sounds
like
we
need
to
do
for
the
other
for
the
under
discussion.