►
From YouTube: OpenActive W3C Community Group Meeting / 2019-03-13
Description
A public hangout for members of the OpenActive W3C Community Group.
https://w3c.openactive.io/meetings/2019-03-13-booking-overview-and-feedback
A
A
First
of
all,
I
would
just
like
to
show
you
a
couple
of
things:
we've
done
with
the
speck,
and
so
we've
been
we've
been.
Revising
spec
based
on
feedback
has
been
coming
in
from
all
kinds
of
places
and
we've
not
made
any
major
changes,
but
I'll
go
through
the
changes
we
have
made
based
on
that
different
places,
different
people
providing
that
feedback.
A
A
Calls
then,
on
big
call.
It
turns
out
so
we'll
continue
this
process
and
bring
as
much
into
the
open
as
we
can
from
from
those
individual
conversations.
So
yeah
we've
got
just
published,
but
all
this
cool
a
new
version
and
it's
a
couple
of
minor
changes.
So
one
of
things
we've
done
is
clarified
the
scope.
It
was
a
bit
simplistic
before,
but
it
turns
out
that
over
the
time
and
various
conversations,
we've
actually
ended
up,
including
a
bit
more
in
the
scope
than
we
and
I
think
had
well
I.
A
You
have
to
wait
for
someone
on
the
other
side
say
yes,
and
then
it's
confirmed
so
a
minor
tweak
to
allow
that
to
be
possible
and
other
and
I
think
everything
is
the
same
as
it
was
in
the
previous
version,
and
then
we've
also
clarified
what
is
also
out
of
scope.
So
that's
including
things
like
the
subscriptions,
so
you
can't
you
can't
create
members
using
the
spec,
which
again
is
obvious
from
the
spec
content
itself,
but
just
making
that
kind
of
Claire.
A
In
this
section
some
of
the
decisions
we
made
about
business,
business,
tax
calculation
being
out
of
scope
and
that
we've,
including
GDP
our
current
collecting
marketing
preferences-
nothing
like
that
in
there
and
so
that,
hopefully
helps
to
clarify
what
is
in.
You
know
how
much
scope
another
thing
we've
done
is:
we've
we've
actually
updated
the
there's
another
spec,
we've
added
and
we've
updated.
This
Spector
connect
to
it,
link
to
it
and
that
spec
is
called
the
dataset
API
discovery
spec
and
which
I
haven't.
As
you
can
see,
the
title
isn't
completely
updated
yet.
A
So
this
is
a
very
early
draft
of
that
discovery,
spec
and
what
that
basically,
is
is
what
this
is
documenting
in
detail
is
what
we
already
have
to
an
extent
in
use
in
a
lot
of
places,
and
actually
you
know
the
class
didn't
have
just
implemented,
there's
that
this
is
a
standard
part
of
their
system.
So
it's
this
page.
Basically,
this
is
the
page
that
links
to
the
feeds,
and
so
when
this
page,
although
it
looks
shiny,
it's
actually
the
code
behind
this
page
that
we've
included
in
this
specification.
A
So
this
is
the
information
that's
encoded
in
the
page.
You
can
see
some
JSON
there
and
and
that
information
is
available
for
mission
to
be
machine
read,
so
you
can
find
out
where
those
endpoints
actually
are
by
just
accessing
this
page
and
Google
and
others
do
do
this
kind
of
indexing,
so
they
they
use
this
same
spec
to
to
get
that
detail.
A
So
that's
what
that
is
so
there's
a
whole
new
spec,
which
is
good
because
we're
trying
to
finalize
the
bookings,
which
means
we
can
not
worry
about
some
of
the
things
that
are
in
this
back
and
do
that.
A
bit
later,
I
mean
they're
not
of
much
consequence
if
I'm
honest
to
most
people,
it's
more
technical
details
about
the
kind
of
standards
were
basing
this
off
of
these
dataset
sites,
as
you
probably
know,
have
been
around
for
a
long
time
now
and
most
people
exactly
all
publishers
have
got
a
set
site
in
the
status
page.
A
You
can.
You
can
click
on
any
one
of
these
and
link
through
to
these
data
sites
that
sorry,
the
m
dataset
science,
that
these
publishers
have
and
they're
all
using
the
same
template.
So
basically
we're
just
slightly
improving
that
to
include
some
of
the
fields
that
aren't
in
there
at
the
moment
and
you'll
see
that
in
the
in
the
latest
version,
which
is
the
one
that
passed
and
it
have
kind
of
done
a
little
bit
ahead
of
time.
A
A
So
the
idea
is,
every
dataset
would
have
a
github
page
which
a
lot
of
Nouri
do,
and
then
you
use
this
the
conversation
rather
than
the
mailing
list,
mainly
because
the
main
list
wasn't
seeing
much
I'll
take
a
lot
of
people
using
the
feeds,
but
no
one
was
joining
the
mailing
list
so
rather
than
having
that
maintenance
burden.
We
just
thought:
let's
move
it
towards
towards
that.
So
that's!
A
What's
going
on
with
that
and
there's
a
lot
of
other
stuff
to
go
in
this
spec
and
so
you'll
see
there's
a
lot
of
headings
but
no
content.
That's
some
work
to
do,
but
thought
it'd
be
better
to
share
this
early
and
say
you
can
all
see
what
was
going
on,
and
that
does
mean
that
some
of
the
elements
of
the
actual
open
booking
spec
we
can
move
across
into
the
the
date
set.
So
I
expect
the
data
discovery
spec
and
they
are
the
information
about
the
discovery
model.
A
A
So
that's
what
this
is
it's
out
of
scope
and
that's
been
added
and
that's
that
link
there
and
everything
else
is
as
it
was
and
and
then
a
couple
of
things
that
we've
gone
through
and
looked
at
are
the
versioning.
So
I've
got
a
question
for
you
guys
actually
in
a
minute
and
so
I'm
going
to
ask
about
versioning
and
so
we'll
see
if
anyone's
got
any
views
on
that
and
then
other
than
that
I.
A
A
We
have
one
version
for
all
of
open,
active
that
says:
open
activities,
version
you're
using
open,
active
version,
one
so
there's
the
slide
and
if
you're
using
a
pen
active
version
one
then
you
must
be
using
this
version
of
the
booking
spec,
this
version
of
modern
speculation.
If
I
flick
you
this
version
of
discovery,
and
so
we've
got
one
one
version
that
we
use-
and
you
know
if
you're
working
with
a
booking
system,
it's
conforming
to
that
version,
exactly
what
to
expect
from
all
those
specifications
underneath
there.
A
So
that's
one
approach
and
then
the
other
approach
is
to
have
kind
of
use,
the
versions
of
the
specs
that
will
really
exist
and
have
and
dependencies
between
them
a
bit
like
you
would
have
dependency
management
in
libraries,
so
booking
spec
version,
one
uses
modeling
spec
version
2
in
our
PD
version.
1
publishing
requires
any
combination
of
the
two,
so
you
don't
have
to
have
any
fixed
combination,
which
means
there's
more
potential
variance
in
what
you
can
do.
A
As
a
data
publisher,
you
could
version
one
of
the
modelling
spec
conversion
to
of
publishing
or
whatever
you
want
to
do
and
discovery
will
be
separate
as
well.
So
you
don't
have
that
uniformity
of
guaranteeing
everything
is
the
same,
but
you
get
more
flexibility
because
you
could
implement
different
versions
of
different
bits
of
it
if
you
like.
So
this
is
more
flexible,
but
obviously
means
it's
slightly
more
complicated
the
data
users
because
you
have
to
deal
with
different
versions-
and
this
is
this-
is
less
flexible.
That
simplifies
the
what
people
can
expect
from
implementers.
B
B
A
Good
idea,
the
challenge
we've
got
is
that
modelling
version
two
and
modernization
one
already
exists
and
people
have
in
fact
implemented
more
than
version
what
and
the
modeling
agency.
So
unless
we
started
at
two
but
then
then
our
PDE
version
one
also
exists.
So
I
guess
we've
got
the
challenge,
because
these
two
in
combination
are
in
heavy
use.
B
A
That
any
reason
why
you
can't
do
that,
there's
no
technical
reason!
You
can
implement
one
one,
one
of
the
other
and
it's
just
a
question
of
whether
that
would
make
it
yeah.
So
that
allows
you
to
do
things
like
upgrade
your
publishing
before
you've
upgraded
your
booking
and
then
a
dating
user
would
need
to
know
how
to
work
with
both
I
guess.
But.
B
B
A
Great
that
makes
sense,
and
so
and
actually,
as
a
data
user
you're
perfectly
placed
because
you're
the
disadvantage,
of
course,
would
be
on
your
side.
So
you
would
have
to
have
more
permutations
to
connect
because,
of
course,
people
can
choose
what
combinations
that
they
are
using.
But
you
are
happy
with
that
you'd,
rather
that,
as
a
because
of
the
benefits
of
flexibility
but
published.
A
D
Versioning
for
different
modules,
because
each
one
will
evolve
differently.
That's
it
to
be
honest:
I
prefer
option
one
and
the
right-hand
side
of
the
slide,
because
from
from
if
they
provide,
if
the
data
promises
and
we're
using
up
an
active
1.0,
at
least
you
know
in
one
go
exactly
all
the
different
versions
that
they
are
using
for
all
the
different
modules.
I'm,
that's
something
that
you
don't
have
to
figure
out
yourself.
I
mean
it
grates
like
a
common
language
for
everyone,
for
both
the
providers
on
the
the
consumers
and
bad
asses
I
mean.
D
Obviously
each
company
will
have
their
constraints.
They
will
for
some
reason
they
will
have
to
operate,
may
impatient
or
they
won't
be
able
to
full
I,
don't
know.
Maybe
they
don't
have
enough
resources
to
to
embrace
the
latest
version
and
their
stick
on
the
old
version.
So,
even
though
I
agree
with
the
first
option,
each
company
will
happy
its
own
problems.
They
will
probably
give
you
a
list
of
numbers
of
versions
that
they
have
and
you
do
the
better.
You
can
do
a
lot.
E
F
B
E
E
D
A
That's
a
good
point:
we
have
no
I
haven't
looked
specifically
the
micro
services
you're
right.
That
would
be
wouldn't
there,
but
mainly
because
that
if
we
felt
like,
if
we
were
going
into
that
world,
it
might
be
too
complicated.
That
the
suggestion
here
is
is
just
that:
the
at
a
high
level,
if
you're
using
booking
version
one
it
includes
these
two
and
if
you're,
using
publishing
it's
kind
of
its
own
thing.
And
so
you
don't
need
to
I
guess
the
way
you
would
have
to
code
it
as
the
data
user
is.
A
You
would
have
to
code
against
all
the
versions
of
publishing
you
support
and
then
you'd
code
against
the
versions
of
booking
new
support
independently
and
the
versions
of
discovery
you
support,
and
then
you
would
then
just
you
would
have
different
combinations,
basically
that
you
would
be
able
to
you'll
be.
Obviously
these
are
lis
more
difficult
to
test,
because
you
have
lots
of
combinations,
but
you
you
would
have
to
then
yeah
just
rather
than
dependency
management
in
the
micro
services.
A
D
But
this
still,
you
have
to
test
the
whole
thing,
so
if
the
company
could
to
stick
to
anyway,
so
I
keep
thinking
that
the
the
presumption
they
option
in
the
right
hand,
side
is
slightly
better.
Okay,
it's
fear,
unless
prone
to
making
maybe
some
assumptions
or
trying
to
have
it
there's
so
many
options.
A
G
This
is
trap
from
legend,
so
yeah
actually
I
will
ask
pressure
option.
One
is
simply
with
option
one
by
option:
one
I
mean:
does
the
thing
on
the
left
hand
side
it's
just
that
it
gives
us
flexibility,
that
we
can
just
go
ahead
and
implement
something
standalone
without
having
to
just.
If
you
want
to,
let
us
say,
implement
version
two
of
some
often
active,
then
we'll
have
to
do
quite
a
lot
of
work
to
get
go
2.0.
G
A
A
G
A
A
Very
absolutely
so:
that's
where
this
complexity
comes
from.
Actually
so
the
booking
spec
requires
our
PD
and
modelling
and
then
publishing
also
uses
our
PD
and
modeling
separately.
So
it's
feasible
that
in
this
version
you
could
implement
you
know
someone
could
update
to
bookings
back
to
watch.
He
less
likely,
probably
more
likely
to
update
publishing
to
op
d2
and
modeling
version
3
and
leave
booking
on
modern
version
2
and
our
PD
version
1.
A
Do
you
sort
of
me,
okay,
yeah,
because
they're
separate,
because
they're
separate
end
points,
so
you
could
just
have
one
set
of
end
points
that
are
higher
than
the
other
set
of
n
points.
G
A
A
A
A
G
A
A
Don't
you
don't
talk
about
the
type
of
you
know
you
don't
talk
about
the
engine
spec,
but
obviously,
when
you
build
the
car
you'd
actually
would
need
all
of
that
stuff,
so
cool!
Okay!
Thank
you
right.
So
moving
on
to
the
next
point,.
A
So
this
is
about
the
minimum
amount
of
work.
You
would
need
to
do
to
implement
the
booking
spec
for
those
of
you
who
are
new
to
the
working
spec
and
apologies
to
everybody
else,
I'll,
just
oh,
just
in
three
minutes
five
minutes
just
quickly
covering
what
looking
spec
is
again
so
you've
got
that
background.
These
are
our
favorite
little
diagrams
that
we
know
and
love
now,
because
we've
seen
them
so
many
times.
A
So
this
is
this
is
the
different
actors
that
are
involved
in
the
system,
so
you've
got
a
booking
system
such
as
participant
or
legend
on
the
call
you've
got
a
broker
such
as
Moloch
or
pitch,
and
then
you've
got
the
seller,
which
would
be
customer
of
the
booking
system.
So
that
would
be
GL
and
you've
got
a
customer
hey
is
he
and
we've
got
a
customer?
A
Who
is
a
customer
of
the
broker?
So
that's
the
kind
of
flow
I'm?
Sorry,
that's
the
kind
of
the
kind
of
different
actors,
and
then
we've
got
the
payment
provider
that
sits
outside
of
these
there's
another
independent
organization
and
that
that
might
be
interacting.
And
so
the
idea
is
that
a
broker
uses
a
payment
provider,
so
Michael
pitch
might
use
stripe
and
the
seller
has
an
account
with
that
payment
provider
or,
however,
that
setup
and
and
then
that's
that's
how
that
works.
It
might
be
possible
that
the
broker
is
also
providing
a
PIM
provider.
A
Is
one
thing
equally,
it
could
be.
There
could
be
a
lot
number
of
mixes
here
but
effectively.
The
point
is
this:
spec
covers
the
arrow
between
the
broker
in
the
booking
system.
So
that's
the
focus.
It
doesn't
cover
any
of
this
other
stuff,
and
so
that
means
that
things
like
Commission
is
out
of
scope,
because
that's
actually
not
something
between
these
two
that
between
the
motoring
and
the
seller
or
now
on
to
that.
A
A
You
might
already
have
a
login
page
that
so
you
might
sorry
you
might
have
a
customer
logged
in,
and
so,
if
a
customer's
logged
in
you
don't
need
to
ask
them
again
for
their
details,
that's
already
there
and
for
book
and
pay
that
again
you
can't
details
might
be
stored.
You
might
be
using
other
types
of
payment
methods
like
move
credits
or
employment.
Well,
employee
wellness
vouchers.
A
So
all
of
this
means
that
these
steps
are
kind
of
just
notional
steps,
they're,
just
logical
they're,
not
an
actual
user
interface,
and
what
that
leads
us
to
is
this
kind
of
this
journey
here.
This
is
the
API
flow,
so
it
starts
with
you
select
what
you
want
at
that
point.
The
broker
sends
a
request
of
order
quote
to
booking
system.
They
send
an
order
quote
to
the
booking
system
and
the
booking
system
replies
with
the
kind
of
shopping
basket.
So
what's
in
the
shopping
basket,
so
you
might
say,
I
want
this.
A
I
want
this
Zumba
class
at
7:30.
You
ping
that
to
the
booking
system,
booking
system
comes
back,
great
that'll,
be
this
much
tax
and
this
is
a
total
and
then
you
can
you've
got
the
information
for
your
shopping
basket.
To
display
that
total
you
can
make
that
same
call
again,
that
you
can
do
it
during
registration
as
well.
So
if
you've
got
some
customer
details,
you
can
send
the
same.
Call
I'll
explain
why
that
might
be
useful
in
a
minute.
But
it's
the
same
idea
exactly
the
same.
A
Call
you
say:
here's
you
saw
that
the
customer
here's
the
basket.
It
comes
back,
that's
the
total.
This
is
a
tax
and
then
finally,
the
book
step.
So
assuming
that
that
both
are
successful
or
even
if
you
don't
need
to
do,
one
is
optional.
You
could
just
do
two,
assuming
that
you've
got
that
successful
order,
quote
back
that
says
you
can
make
that
booking.
You
authorize
the
total
amount.
Let's
come
back
from
that
quote
with
your
payment
provider,
so
that
was
a
credit
card
payment.
For
example.
A
You
would
you
could
authorize
that
at
that
point
and
say
7
pounds
plus
including
tax
and
authorize
that
from
the
card,
you
then
make
a
booking
call
to
the
payment
system,
the
booking
call
to
the
payment
system.
That
then
confirms
that
booking
with
a
payment
system
and
if
that's
successful,
you
move
to
capture
the
payment
from
the
payment
provider
final
step.
A
So
minimum
required
is
just
the
quote:
order
quote
and
order.
You
only
need
two
endpoints
okay,
so
that's
just
just
basically
you
don't
to
the
order
quote
in
a
minimum
form.
Doesn't
you
didn't
need
to
anything
intelligent?
It
just
needs
to
reply
with
the
availability,
so
it
doesn't
store
anything.
It's
just
a
dumb
kind
of
availability,
endpoint
in
the
basic
form.
The
order
endpoint
is
where
the
magic
happens.
A
B
A
A
minimum,
the
implementation-
absolutely
that's
right,
that's
right!
So
is
the
final
order,
which
you
I
mean
you
do
need
to
implement.
Order
quote
just
to
allow
people
to
get
that
tax
information
which
you
won't
be
able
to
get
any
other
way
from
the
existing
availability.
Even
if
it's
a
confirmation
that
you
know
there
is
no
tax
applicable,
but
it's
checking
that
that
is
is
an
available
space.
A
Yes,
it
is
a
separate
endpoint.
You
would
need
to
implement
from
yeah,
but
it's
it's
a
very,
very
lightweight
one,
which
you
would
probably
be
using
whatever
you're.
However
you're
creating
your
feed
very
similar
logic,
it
probably
exists
in
here,
so
it
shouldn't
be
complicated.
Yeah,
okay,
no
worries.
So
so
that's
that
and
in
order
which
great
sorta
has
anyone
got
any
questions
on
on
this
before
we
move
on
to
the
next
bit,
which
is
the
detailed
flow
just
again
and
slightly
more
detail.
A
Point
so
in
the
scope
of
this
specification,
I
should
have
said
that
earlier,
so
the
this
specification
is
about
guest
checkout
only,
and
so
it
doesn't
have
any
there's
no
changes
based
on
who
the
user
is
the
member.
It's
just
about,
as
you
would
with.
In
legend,
you
know
ticket
booking
yeah,
one
in
ticketing,
yeah
exactly
this
is
so
same
idea.
So
it's
it's.
You
know
us,
don't
have
any
connection
to
the
real
person.
A
Well,
anonymous,
yes,
and
none
of
us,
except
for-
and
so
maybe
I'll
talk
about
this
in
some
some
cases.
So
let's
just
talk
about
leasing
for
a
second
and
then
our,
and
that
will
explain
why
it's
not
totally
anonymous
but
relatively
anonymous
compared
to
member
membership
and
other
things
so
for
leasing.
A
The
best
way
of
explaining
leasing
is
if,
if
you
go
and
buy
something
from
Amazon,
if
you
want
to
buy
a
book
from
Amazon
and
there's
only
one
book
left,
then
you
will
only
get
that
book
for
yourself
when
you
give
them
your
credit
card
details
and
press
pay
until
that
point,
if
there's
only
one
left,
then
it's
not
reserved
for
you.
Anyone
else,
who's,
also
looking
at
that
same
page
browsing
can
get
that
book
and
and
and
buy
it.
A
And
that
means
when
you
get
to
the
end
of
your
checkout
process,
the
book
you're
looking
to
buy
is
already
gone,
so
someone's
stolen
it
from
your
basket,
basically
while
you're,
while
you're
looking
to
buy
it,
and
that's
because
there's
no
lease,
there's
no
reservation
on
the
book
before
the
point
where
you
purchase.
So
that's
in
the
world
of
of
Amazon
is
take
a
different
example:
let's
take
Ticketmaster
for
theater
booking
and
with
theater
booking
it's
the
other
way
around.
A
So
if
I
wanted
to
book,
Hamilton
I
would
start
a
clock
ticking
as
soon
as
I.
Look
at
the
page,
I
don't
put
any
detail
in
I,
just
look
at
the
page
and
as
soon
as
I
do
that
and
I
and
I
look
at
the
page
for
my
two
seats,
its
reserved
them,
and
so
no
one
can
take
those
seats
while
I'm
looking
and
while
I'm
putting
my
details
in
and
so
that's
in
theater.
It
works
like
that.
A
A
This
spec
offers,
which
is
this
customer
details,
so
the
idea
is
that
in
the
process
here
you
make
a
checkout
you
make.
The
first
quote:
call
when
you've
just
browsing
when
you've
got
no
further
detail.
You
make
the
second
checkpoint
call
after
they've
registered
and
you
make
the
booking
call
after
they
put
their
payment
details
in
and
what
that
means
is
that
as
a
booking
system,
if
you
want
to
it's
optional,
you
can
lease
the
space.
G
G
A
F
G
A
A
So
the
order
quote
is
is
exactly
that.
It's
just
a
new
quote
of
a
number
of
items,
so
you
might
the
first
Euler
quo
might
be
two
items.
Then
you
might
add
one
and
make
another
quote
for
three
and
then
two
and
then
one
and
if
you
wanted
to
do
a
lease
optionally,
you
will
update
that
lease.
Every
time
you
get
a
quote
updated,
you
would
remove
and
add
things
according
to
the
latest
quote:
you've
received.
A
And
then
the
idea
is
that
if,
when
you
get
to
book,
obviously
you've
already,
if
you've
got
a
lease
with
that
quote,
then
the
order
will
use
that
that
call
will
use
the
lease
if
the
lease
is
expired
or
for
any
reason
the
lease
is
not
not
there.
Then
it
will
try
and
get
a
new
lease.
So
in
be
the
only
reason
the
B
will
fail
is
nothing
to
do
with
leasing.
B
will
only
fail
if
there's
no
spaces
available.
A
B
A
Yep,
so
absolutely
so,
there's
a
good
point
there,
which
is
that
the
payments
themselves,
let's
go
back
to
the
scope.
So
obviously
the
payment
provider
is
outside
of
the
scope
here,
and
so
that's
something
that
is
is
not
it's.
You
can
use
any
provider
as
you
want
to
do
that
and
then
there's
a
or
is
in
the
scope
section
here.
So
the
key
point
here
is
the
payment.
Processing
and
business
models
are
outside
of
the
scope
of
the
specification.
B
A
B
A
B
I
mean
an
example
of
that
is
WorldPay
weren't
really
interact
with
people
who
don't
own
own
own
assets
yeah.
So
if
you're
dealing
with
the
client
who
takes
payment
by
well
pay,
then
as
a
marketplace,
it's
incredibly
as
almost
possible
to
do
anything.
They
just
won't
give
any
sort
of
accreditation
to
marketplaces
that
don't
have
their
own
assets
that
act
as
agents
only
interesting.
So
it's
a
real
big
problem.
B
A
B
C
D
Yeah,
so
it
might
be
the
case
that
you
have
more
than
one
payment
provider,
and
let
me
let
me
explain
that
a
bit
more.
So
let's
say,
for
example,
here
we
are
kind
of
a
we're
using
stripe,
and
so
when
the
customer
pays
any
money
through
the
broker,
the
broker
being
us,
it
goes
through
is
stripe,
and
so
nothing
is
stops
us
from
okay.
So
we
take
all
the
money
from
only
stripe
and
then
later
we
do
their
painting
installation
through
cash.
D
So
we
could
do
a
bank
transfer
at
the
end
of
it,
so
we
are
not
enforcing
so
the
data
can
provider,
it's
not
enforcing
the
broker
to
use,
for
example,
wall
pay
and
we
don't
have
to
enforce
our
customers
to
use
work
either.
So
each
one
can.
We
can
be
couple
these
things,
so
we
are
using
stripe
on
behalf
of
that
and
then
we
pay
money
every
month
to
them.
D
A
Absolutely
right,
that's
exactly
it!
So
it
doesn't
matter.
The
seller
receives
the
money
from
the
broker
through
some
means
and
the
booking
spec
the
booking
system
doesn't
in
this
bet
doesn't
have
any
connection
to
that.
So
any
any
way
of
doing
that,
you
know
sending
gold
bars
in
the
post
or
whatever
it
is.
D
D
A
Okay,
I'll
make
that
clear
in
the
spec,
your
totally
right
and
the
the
the
broker
here
is
actually
yea
able
to
use
multiple
payment
providers,
as
agreed
with
the
seller.
The
only
thing
that
this
currently
requires
is
that
there's,
some
identifier
that
relates
to
the
booking,
so
it
relates
to
the
payment,
is
posted
to
the
booking
system
and
that's
just
for
audit.
So
if
there's
an
ID
that
you
get
from
particular
transaction,
you
just
take
that
ID
and
you
give
it
to
the
booking
system
so
that
the
seller
can
trace
between
the
two
absolutely.
A
A
And
that's
actually,
why
there's
there's
a
ability
to
override
as
well,
so
you
can
override
so
I
just
for
completeness
and
let's
get
back
to
the
same
before,
but
this
is
really
so
in
offer
overrides.
You
can
actually
override
the
price
as
a
as
broker
if
you
wanted
to
and
that
override
allows
you
to
specify
different
price.
A
So
that
means
that
what
that
means
is
that
with
the
previous
diagram
that
everything
is
then
possible.
So
if
you
wanted
to
change
any
of
the
numbers
surrounding
this,
you
can
do
that,
including
this
one
and
the
main
amount
that's
being
transferred.
So
for
in
theory,
you
could
make
it
free
right.
You
could
have
zero
payment
here
and
then
you
could.
You
could
pay
it
entirely.
This
way
or,
however,
I
mean,
as
long
as
the
tax
will
checked
out,
which
there's
more
detail
on
in
here,
then
you
can.
You
can
do
a
part
part
payment.
A
Right,
good,
cool,
okay,
fantastic,
really,
really
helpful.
Okay,
so
I
think
we
would
just
about
to
go
on
to
here
was
the
order
quote,
so
we
worked
with
the
basically.
This
is
exactly
it
would
cover
a
so
all
the
quote
calls
made,
or
the
code
comes
back
and
then
the
further
calls
made
order.
Code
comes
back
and
then
finally
there's
a
sorry
and
then
finally
there's
a
the
final
order,
call
is
made,
and
then
you
authorize
and
capture
the
payment
either
side
of
that
and
when
you've
made
that
order
called
and
captured
the
payment.
A
Obviously,
the
payment
provider
will
be
the
system
of
records
for
the
payments
and
refunds,
but
the
brokers,
visibility
of
that
this.
This
blue
line
visibility.
The
broker
can
see
everything,
but
the
booking
system
actually
doesn't
have
visibility
of
the
payments
and
refunds.
This
is
a
an
Ian
thing.
Show
this
you're
interested,
why
that
is
the
case.
It's
his
legacy
of
leaving
those
things
separate
because
he
didn't
want
the
complexity
of
the
payments
and
the
invoices
to
be
in
in
the
booking
system.
A
A
So
the
idea
is
that
we
put
the
invoice
where
the
diversity
exists
in
the
kind
of
payment
methods
and
the
currencies
and
things
in
the
middle
and
broker
responsible
for
that,
and
the
orders
is
what
the
booking
system
is
responsible
for,
because
that's
that's
why
the
inventory
lives,
and
so
the
booking
system
deals
with
orders
and,
as
we've
said,
the
payments
are
outside
the
scope
as
well
and
I've
been
spec
in
general,
but
that's
something
that
the
broker
would
deal
with.
However,
they
want
to
deal
with
it
so.
D
A
Yep,
you
can
do
cancellation,
let's
do
cancellation
next,
after
just
wanted
to
show
you
back
to
this
this
diagram,
so
you
got
the
whole
flow,
so
you
can
see
that's
what
invoice
generation
means
and
the
other
thing
is
customer
notification.
So
customer
notification
is
that
again
the
broker
is
responsible
for
notifying
the
customer,
primarily
because
it's
an
app
or
it's
an
Apple
watch
sure
it's
an
LX
there
on.
You
know
it's
a
voice
command
whatever
the
medium
is
through
which
the
person
is
booked.
A
If
that
is
you
know,
they've
they've
asked
their
car
to
do
it
for
them.
Then
that
is
where
the
notifications
will
come
back
to
say.
The
booking
has
been
successful
or
there's
a
cancellation
which
we'll
talk
about
in
a
minute.
Something
like
that
and
that's
why
so
there's
no
there's,
no
notifications
that
come
from
the
booking
system.
All
the
booking
system
needs
to
do
is.
Is
we
talk
to
our
order
feed
earlier?
The
order
feed
is
where
those
things
happen.
So
there's
a
feed
of
orders.
A
The
booking
system
provides
to
the
broker
and
if
they
want
to
cancel
something
the
booking
system
just
posts.
The
thing
to
that
feed
we'll
talk
about
that
in
a
minute,
but
the
the
basic
idea
is
that
notification
and
the
invoice
generation
on
the
broker
side,
because
that's
where
diversity
exists,
that's
where
the
relationship
exists
and
that's
the
channel
that's
being
used
and
to
make
that
real.
What
that
means
is
we
don't
expect
the
booking
system
to
send
emails
to
the
email
address?
A
Although
the
email
address
might
be
provided
and
it
wouldn't
be,
the
booking
system
wouldn't
be
spent,
sending
any
emails.
That
would
be
the
broker
and
in
the
phone
number
is
optional
to
be
provided,
but
if
the
phone
number
was
provided,
we
wouldn't
expect
necessarily
the
seller
to
call
the
phone
number
to
tell
them
about
a
cancellation.
B
A
A
A
Ending
in
customer
counts
the
room
customer
requested
cancellation
after
that
should
be.
Oh
there,
you
go
the
requester
cancellation,
so
the
seller
requested
cancellation
is
really
easy.
There's
an
order
feed
and
what
they
do.
Is
they
post
an
item
that
order
feed,
which
is
that
the
sellers
cancelled
with
a
note
they
can
include
a
cancellation
message:
they
want
to
the
pitchers
waterlogged,
really
sorry
and
they
submit
that,
and
then
that
then
what
happens
is
that
the
broker
collects
that
information
from
the
feed
and
then
they
issue
the
refunds.
A
If
that's
the
you
know
so
that
they
and
in
this
spec
there's
no
partial
refunds,
that's
one
of
the
issues
in
here.
So
it's
an
all-or-nothing
situation.
If
you
receive
a
cancellation,
you
issue
a
refund
or
if
you
don't,
if
you
want
to
try
and
rebook
them,
of
course
you
can
because
you're
dealing
with
payments,
you
can
call
up
your
customer
and
say:
hey
pictures.
A
Would
you
like
to
rebook
or
something,
but
as
far
as
the
booking
system
is
concerned,
as
far
as
a
reconciliation
is
concerned,
at
the
point
where
that
is
posted
to
the
feed,
the
the
translations
happens,
that's
done
so.
There
shouldn't
be
any
situation
where
a
customer
is
saying.
Hang
on,
I
never
got
my
refund,
because
it's
the
responsibility
of
the
broker
entirely
at
that
point
to
clearly
indicate
to
the
customer.
What's
going
on,
so
the
pitch
was
waterlogged
that
it
got
cancelled
the
money
from
the
booking
system.
Perspective
has
been
refunded.
A
If
there
was
a
delay
to
that
refund,
because
you
know
any,
you
want
to
call
them
off
and
keep
their
business
in
a
different
way
and
reuse
that
money.
You
would
need
to
be
very
clear
to
the
customer
that
the
money
has
been
refunded
onto
their
account
or
something,
and
they
can
have
it
back
any
time
they
want
we're,
just
calling
it
as
a
courtesy
that
kind
of
thing,
because,
from
a
legal
perspective
we
talked
about
that
agent
broker
relationship
before
Meleager
perspective.
At
that
point,
the
seller
has
refunded
the
money
to
the
the
customer.
A
A
B
A
B
I
think
you'll
find
there
is
a
bit
of
resistance
about
that.
In
our
conversations,
do
you
think
there's
justification
where
the
operator
would
button
that
phone
number
of
the
customer-
and
you
know
as
a
as
a
broker
I,
don't
ask
me,
have
a
problem
with
that,
because,
ultimately
you
know
it
means
that
the
customers
that
we
told
so
there
is
a
cancellation.
Then
that
is
a
better
user
experience.
B
F
B
A
B
B
You
know
if
they
start
panicking,
then
at
least,
if
they've
got
a
phone
number
it's
within
their
control,
if
they
don't
have
a
phone
number
and
that's
really
cool
my
little
trying
to
get
perhaps
to
cut
her.
It
just
creates
quite
a
stressful
situation
in
practice
and
so
I
think
yeah,
giving
the
bad
news
that
kind
of
ability-
and
they
would
argue
as
some
have
in
the
past-
that
it
is
a
kind
of
requirement
of
the
burking
phone
number
so
that
they
can
do
that.
If
there's
problem.
A
B
Think
to
ensure
I
can
see
the
point
III
think
to
ensure
kind
of
real
operator
buying
I
would
suggest
that
it's
making
it
mandatory
and
taking
any
debate
out
of
the
equation
would
be
sensible.
As
long
as
it
comes
with
the
appropriate
gdpr
kind
of
marketing
confirmation,
then
I
think
it
would
be
simpler.
Just
to
say
it's
neither
than
say
no
sorry.
It's.
A
Required
yeah,
okay,
that's
good
to
hear
and
as
a
so
I
guess
what
I'm
thinking
is
is
obviously
this
four-pitch
booking
makes
a
lot
of
sense
in
the
context
of
other
types
of
activities
which
would
be
booked
so
zumba
class,
etc.
Is
that
always
case
and
does
every
type
of
front-end
want
to
do
the
same
yeah.
A
A
We
should
raise
that
in
the
in
the
wider
discussion
about
whether
people
feel
like
that
should
be
required
at
the
different
levels,
because,
as
you
say,
if,
if
ten
is
technically
we're
happy
to
keep
it
optional,
but
certain
races
require
it,
then
it
will
be
really
easy
for
a
broker
to
make
it
required.
Of
course,
you
could
just
check
that
no
bookings
are
being
made
from
the
local
pitch
that
don't
have
a
phone
number
and
be
really
easy
to
do.
A
B
E
Saw
Jeff,
what
is
it
I
think
making
it
mandatory
is
not
most
of
our
customers
want
to
go,
our
customers
are
yeah
activity
providers
and
their
customers
I
think
what
the
book
are.
Obviously
so,
most
of
us.
Yes,
we
have.
The
option
is
the
tick
box
and
they
can
make
it
mandatory
optional
or
not
require
at
all
have
a
phone
number,
but
some
some
others
pushing
back
saying
you
know
if
they
are
mandatory
to
have
a
phone
number
people
drop
it
off
nice
to
make
you
the
bookie.
Oh
right,.
F
E
You
know
and
filled
out
just
don't
double
to
give
it
they.
Don't
we
caught
up
it's
what
I
made
the
book
come
online
they're
gonna
try
to
need
address.
Okay,
getting
your
conflation
make
payment,
okay!
Well,
they
don't
really
want
to
know
what
to
call
them
up,
as
I
said
with
Vitus.
Yes,
you,
if
you
pay
on
an
event,
you
have
the
choice
you
could
make
it
you
have
to
get
off
this.
You
can
find
a
phone
number
on
your
car
book
or
softball,
but
make
I
think
forcing
it
to
happiness.
A
E
A
That
makes
sense:
okay,
yeah.
So
that
sounds
like
it's.
You
know
we
could.
We
could
keep
that
as
a
we
could
make
it
recommended
or
optional,
but
I
suppose
from
a
practical
perspective
it
doesn't
we're
not
gonna
fail
any
if
we
keep
it
as
recommended
optional.
No
one's
gonna
fail
validation
against
the
spec
by
not
including
it,
but
of
course,
as
you
say,
it
might
well
be
that
from
the
pitchers
perspective
gol,
when
we
work
with
companies
that
book
pitches
that
provide
phone
numbers
right,
that's
just
something.
A
Cool
okay,
as
anyone
else
on
on
that
or
a
sweetish
code,
customer
cancellation,
I
love.
That
list
is
regardless
number
of
people
on
the
call.
We
can
always
have
a
good
debate
easily
like
pretty
much
what
you
know
end
up
with
the
same
result,
it's
great
so
so
good.
So
let's
just
jump
into
customer
cancellations.
So
this
is
simply
the
same
process
that
happens
the
last
stages,
so
you
get
that
cancellation
request.
Customer
cancelled
refunds
process
invoice
generator
from
the
our
PDE,
so
the
our
PD
process
is
the
same.
A
The
bit
that
happens
before
that
is
obviously
that
the
trigger
is
different,
so
the
trigger
doesn't
happen
from
the
cell.
At
this
time
it
happens
from
the
customer.
The
reason
it's
exactly
the
same
here
is
because
it
makes
it
quite
easy
to
implement
for
both
sides.
So
you
just
mean
that
the
feed
is
the
same,
watching
the
feed
for
refunds,
same
and
processing
that
and
generating
invoices
and
notifications
to
say
the
refunds
confirmed
is
all
the
same,
regardless
of
how
it
happens
in
the
first
place.
A
The
difference
is
that
when
you
request
the
cancellation
here
that
you
actually
go
through
this,
this
quick
process,
which
is
that
you
say
first
thing-
is
that
you
you
check
the
order
to
check
that
it's
cancelable.
So
our
our
simple
cancelation
is
true.
If
it
is
either
can
be
cancelled,
then
you
attempt
cancellation
with
this
patch
order,
quote
thing
which
is
basically
saying
you
just
you
patched
the
same
jason
body
with
customer
cancelled
stages
against
the
items,
because
there's
multiple
items
against
the
items
that
you
want
to
cancel
and
then
that's.
A
If
that
works,
then
you
patch
again,
but
with
the
order.
So
it's
similar
kind
of
two-phase
commit
that
we
had
during
order
creation,
but
this
time
for
translation
and
that
one
that
allows
you
to
do
is
in
between
the
two
patch
calls
you
can
say
to
the
customer.
Are
you
happy
to
receive
a
5-pound
refund,
because
what
the
first
calls
return
to
you
is
is
the
new
order,
as
it
would
be
with
the
refund
was
processed.
A
So
if
you
keep,
you
know,
press
the
button
to
cancel,
you
can
make
the
first
call
and
get
back
from
the
booking
system.
What
the
new
order
looks
like
do
a
bit
of
a
difference
of
what
that
looks
like
compared
to
what
payments
you've
taken
as
a
broker,
so
I've
taken
ten
pounds,
payment,
I've
cancelled
one
item:
five
pounds
is
come
off
that
total,
so
I
now
switch
the
customer.
You
know:
do
you
want
to
continual
receive
power
refunds?
They
press?
Yes,
crack
on
previous
version
of
this
specification.
Didn't
have
the
extra
confirmation
step.
A
You
were
just
as
a
customer
blindly
request
a
cancellation
and
then
whatever
was
Duty
would
come
to
you
an
email.
This
is
added
as
a
cult
following
feedback
that
actually
having
that
to
step
in
there.
So
the
customer
knows
what
they're
doing
expectations
are
managed.
It
means
that
that's
probably
likely
to
result
in
the
best
customer
experience
and
probably
less
phone
calls
being
confused
or
annoyed
as
to
why
something's
happened
different
to
what
they're
expecting
so
that
will
make
sense.
D
Sorry,
I
didn't
feel
that,
so
when
you
do
the
batch
or
the
quote,
it's
basically
like
requests
for
the
cancellation
yeah.
It's
not
only,
and
then,
when
you
punch
the
other
when
you
actually
are
requesting
when
you're
actually
performing
the
translation.
Yes
and
the
other
thing
is
that,
and
even
though
in
in
this
diagram,
it
seems
like
the
brokers
pulling
the
data
from
the
our
PDE.
All
the
time
I
mean
the
the
obvious
solution
would
be
that
we
we
the
program,
will
have
to
store
all
these
other
votes.
A
Exactly
right,
so
your
so
so
I
should
have
mentioned
that
part
of
the
contracts
with
both
sides
here
is
that
when
the
what
yeah
at
the
end
of
this
process,
you
store
the
order
that
comes
out
of
B,
you
come
that
comes
out
of
this.
This
put
call
you
store
that
immediately
and
then
any
updates
yeah.
So
any
any
updates,
then
that
come
in
as
the
RPD
feed
are
I
think
to
be
patch
calls
to
you.
So
they're
kind
of
inbound
patch
calls.
A
So
you
might
store
the
whole
order
along
with
custom
met
today,
so
that
you
might
have,
because
you
obviously
might
want
to
store
more
than
what
you
sent
to
the
booking
system,
its
broker
and
then
anytime.
The
booking
system
wants
to
update
that
they
send
a
patch
in
and
that
updates
that
accordingly,
cool.
B
A
Issues
to
open
for
it,
so
yes,
not
this
one
I'll
retrieve
friends
of
mine
in
scope,
so
refunds
are
only
permitted
on
entire
items.
There's
no
way
of
saying
so
it's
night
and
by
item
thing.
So
if
you
dynamically
price,
an
item
the
items
booked
at
that
point,
it
exists
in
the
or
that
price
and
all
you
can
do
is
cancel
the
item
completely
or
not.
B
B
A
How
would
you
do
that
here?
Well,
the
challenge
is
a
reconciliation
problem,
so
at
the
moment
way
this
is
suggested
it
it
works.
Is
that
if
you
trigger
a
cancellation
that
that
that
booking
is
entirely
canceled,
that
really
is
focused
on
before
the
event
occurs
and
and
a
whole
cancellation
before
the
event,
if
you
want
to
do
a
refund
after
the
event
has
occurred,
that
order
has
been
stored.
Now,
that's
in
the
past,
that's
done
that's
interesting
about
how
you
then
reconcile
that
with
the.
A
That
said
number
of
partial
refunds
and
just
put
it
on
there,
and
that
would
be
what
we
could
want
like
a
out-of-band
solution,
so
not
in
respect,
wouldn't
have
it
in
there
that
you
would
just
have
like
an
adjustment
for
partial
refunds,
and
so,
if
they
were
doing
that
true
up
against
you
know
everyone
actives
Department
of
Finance
we're
going
through
and
looking
at
all
the
orders
they're
expecting
their
booking
system
would
match.
You
know
or
gll.
A
B
A
The
challenge-
I
guess
we've
got-
is
because
multiple
items
could
be
in
the
order.
The
question
of
how?
If
we
wanted
to
go
down
the
road
of
implementing
pottery
funds,
you
could
do
a
patch
call,
for
example,
to
the
booking
to
say
change
the
prices
of
each
item.
But
it
gets
a
bit
sketchy
as
to
how
your
item
by
item
based
or
is
it
a
partial
refund
on
the
whole
I?
Guess?
A
Okay,
yeah
I
didn't
know
if
anyone
on
the
booking
system
side
have
any
thoughts
on
that
and
what
you're
sure.
E
E
E
That
just
so
you
can,
you
know
the
glasses
for
the
extend
weeks.
You
don't
you
can't
go
the
last
fall
it's
up
to
the
discretion
of
that
on
the
class,
but
they
say
yet.
You
could
have
refund
of
you
know
five
thousand
session
I'm
gonna
give
you
twenty
pounds
back,
because
it's
still
against
the
order
of
that
of
the
ten
classes
right.
A
That
makes
sense
so
yet
to
doubt
that
I
can
see,
we
could
do
the
same
it
on
all
the
level
here
quite
easily.
We
could
have
a
partial
refund
amount
that
is
then
updated,
basically
by
arbitrarily
by
the
broker,
so
that
the
booking
system
has
that
records
they
can
provide.
Of
course
it
yeah.
It
might
be
difficult
to
know
when
to
post
those
into
the
accountings.
A
E
G
In
our
system,
the
other
do
a
full
refund
or
no
refund,
but
in
case
let's
say
there
was
a
problem
in
the
class
something
broke
down,
so
I
member,
it's
due
for
a
participant
kind
of
things.
What
we
do
is
that
we
should
write,
not
credit
note
which
could
be
of
the
full
amount
of
the
class
or
it
could
be
that's
a
10%
or
20%.
Something
like
this.
This
all
we
do
things
in
legend.
So
what
how
it
has
to
be
implemented
in
this
side
is
really
up
to
what
customers
would
want.
A
G
A
G
There's
there's
one
thing:
I
just
want
to
check
when
we
offer
a
price
to
broker,
is
the
price
dependent
upon
number
of
items
or
some
other
kind
of
similar
discount?
So
the
later,
when
you
reef
refund,
less
is
one
of
the
items
that
would
actually
invalidate
the
price
of
the
other
item
as
well.
So
when
the
price
is
calculated,
how
is
the
price
calculated
is
based
on
any
kind
of
promotion
or
the
number
of
items?
That's.
A
A
That's
so,
let's
say:
let's
just
go
back.
This
is
the
post
you're
making
includes
the
order
items
just
so
that
I
want
this
item,
and
this
offer
so
quite
simple.
There's
the
customer
details,
phone
number
email
address,
only
emails
currently
mandatory,
the
others
are
all
optional
and
then
the
order
creation
comes
back,
and
you
can
see
here
the
the
bunch
of
other
information
comes
back
then
so
does
the
expanded
authorizing
Manby
and
the
order
item
and
the
offer,
so
the
offer
is
10
pounds
and
so
you'll
have
an
array
of
these.
A
A
G
A
A
A
That
sounds
likely
yeah,
that's
not
likely
like
at
the
beginning,
rather
yeah.
Maybe
it's
simpler
to
leave
it
as
a
simple,
more
simple
case:
yeah
yeah,
okay,
okay,
so
we've
kind
of
we
come
to
our
art,
one
box
here
on
the
call-
and
it's
been
incredibly
useful-
we've
got
some
issues
and
hopefully
shed
some
knowledge
as
well
about
the
different
areas
of
the
specification,
and
it's
quite
good
going
through
it
again
actually,
because,
even
though
we've
gone
through
it
a
few
times
now,
we
find
different
bits
each
time
and
so
we're
continuing
refining.
A
A
We've
really
covered
them
all
the
diagrams
that
key
to
this,
including
the
the
different
approaches
to
cancellation,
we've
included
the
tacks
we've
touched
on.
We
included
the
roles
and
responsibilities
diagram.
We
included
agent
broker
and
that
set
up,
there's
more
detail
in
the
spec
that
covers
other
areas
around
different
other
types
of
brokers,
that
it
exists.
Direct
and
reseller
models
there's
also
a
few
other
nuances
around.
If
the
opportunities
are
completely
free,
what
do
we
do
with
that
thing
we
didn't
get
to
touch
on,
but
we
did.
We
talked
on
I
talked
about
briefly.
A
Is
that
you
there's
an
approval
flow
available
as
well?
So
you
can.
You
can
choose
to
wait
for
an
approval
to
come
back
before
you
confirm
that
booking
and
that's
this
additional
here,
which
has
just
got
a
slightly
different
end
to
it,
waiting
approval
to
come
back
in
terms
of
looking
so
I
think
I
think
you've
covered
like
I
would
say
most
of
the
spec
in
terms
of
model
kind
of
outline.
A
So
you
know
I
think
you
obviously
to
read
through
and
if
you
have
any
comments,
we're
going
to
be
next
in
two
weeks
time
we're
going
to
come
back
in
them
and
pick
this
up
again
and
and
go
and
do
this
some
of
the
things.
What
we're
doing
here
go
through
this
back
again,
so
you've
got
a
refresher
of
it,
but
then
coming
to
the
detail.
So
you
can
ask
further
questions.
A
If
you
had
a
chance
to
read
the
spec
between
now
and
then-
and
you
know,
we
can
answer
any
issues
of
course
in
between,
and
you
know
my
email
feel
free
to
ask
any
questions
and,
and
then
the
idea
is
that
next
time
we'll
have
probably
ended,
it
will
have
a
full
knowledge
of
all
different
areas
and
we
should
be
at
the
end.
At
the
I
mean
you
see,
there's
a
few
small
requirements
coming
out
each
time
we
do
it,
which
is
really
great.
A
So
hopefully,
next
time
we'll
be
nearing
the
end
of
that
and
we'll
have
the
small
things
done
so
has
anyone
else
got
any
other
Oh
one
more
really
important
bit
business
before
I?
Ask
any
other
business
we
are
short
on
time
is:
there's
there's
a
booking
workshop
on
the
2nd
of
April.
If
you
haven't
been
invited
by
me
already
I'll
send
him
by
out
the
list,
so
you
can
all
see
what
that
is.
That
is
an
open
invite
to
a
workshop
in
real
life
or
gonna.
A
Talk
to
this
back
now,
aspects
of
decisions
we've
made
with
a
big
group
of
people.
A
lot
of
senior
stakeholders
in
the
sector
are
coming
along
to
that
workshop.
So
it
should
be
really
good
to
get
into
the
detail
of
questions
and
comments
and
and
have
a
final
opportunity
to
feedback
on
the
spec.
So
the
next
call
is
as
we
discussed,
then
we've
got
that
workshop
final
call,
then
we'll
be
talking
about
anything's
come
out
of
the
workshop.
A
If
there's
any
changes,
we
need
to
make
off
back
of
that
suggestions
with
a
view
to
then
finally
submitting
the
Specht
release
on
12
April.
That's
like
current
timeline,
assuming
there's
no
disruptive
Porter's
at
player.
We
haven't
completely
missed
them,
I
think
so,
yeah.
Let's
just
try
and
nail
down
the
a
couple
of
issues
that
raise
today
we
can
before
we
next
get
together,
and
that
means
that
we,
we
should
be
looking
like
it
in
a
really
good
place
for
the
second
zoom
I.
Just
have
any
other
business
before
we.
H
Yes,
not
sure
how
entirely
relevant
it
is
to
everyone
on
this
call,
but
I
will
flag
it
anyway,
which
is
that
there
is
a
world
outside
of
booking
and
I've,
been
doing
a
little
bit
of
work.
Looking
at
the
disability,
accessibility,
sorry
standards.
So
it's
part
of
the
correct
me
if
I'm
wrong
Nick,
it's
part
of
the
data
model
I
can
active.
We
have
some
kind
of
bits
around
it.
Accessibility
and
I've
had
some
conversations
with
different
disability
rights,
kind
of
organizations
about
what
kind
of
data
we
might
want
to
collect.
H
So
I've
just
done
a
little
kind
of
summary
duck
on
Google
to
cover
where
the
standard
is
at
the
moment.
Some
of
the
current
suggestions
and
kind
of
call
a
bit
of
a
call
for
any
further
suggestions.
So,
for
example,
you
might
see
in
today
that
Paris
ball
platform
is
launched.
They're
using
some
of
the
open
active
data,
which
is
amazing,
I
know
they're
just
gone
done
it,
which
is
great
news.
People.
H
There's
not
much
data
which
includes
the
accessibility
information
at
the
moment,
so
yeah
might
be
another
way
for
us
to
think
also
about
data
I,
don't
know
we'll,
say
they're
collecting
data
as
well,
which
we
talk
to
them
about
essentially
publishing.
So
maybe
some
extra
stuff
they're
coming
through,
which
would
be
great.
H
A
Totally
and
actually
great,
if
you're
able
to
share
and
obviously
but
at
some
point
the
information
about
what
you
know
about
what
they're
using
of
the
data
and
any
challenges
and
because
think
they
can
actually
I
spoke
to
a
couple
of
new
providers.
This
week
they
were
quite
keen
to
publish
disability
data,
meaning
that
data
set
specifically
for
activities
for
that
demographic
and,
and
so
yeah
like
this
will
be
a
great
thing
to
tell
them.
If
you
do
that,
it'll
go
in
there,
yeah.