►
From YouTube: OpenActive W3C Community Group Meeting / 2019-02-27
Description
A public hangout for members of the OpenActive W3C Community Group.
https://w3c.openactive.io/meetings/2019-02-27-booking-overview-and-direction-check
A
A
C
E
F
G
I
G
A
C
A
Okay,
noise
and
cool.
Well,
let's
get
started
comments,
oh
and
who's
on
call.
Thank
you
so
much
for
your
time
today,
in
joining
as
you
were
all
at
different
stages
of
this,
don't
feel
silly
about
asking
silly
questions,
probably
not
silly
questions
I,
don't
think
such
thing
at
this
stage,
so
please
do
feel
free
to
just
jump
in
and
ask
anything
if
it
sounds
like
it's
more
complex
and
you
feel
like
you're
little
bit
further
behind
and
we
can
schedule
a
separate
session
off
apart
from
this,
to
kind
of
get
you
up
to
speed.
A
So?
Yes,
that's
that's
open
to
everybody.
If
the
objective
of
today
is
to
go
through
the
specification
which
is
going
to
go
through
it
at
the
high
level
touching
on,
where
it's
at
across
the
different
parts
of
it
and
then
highlighting
some
issues
which
we've
flagged
they're,
actually
issues
in
the
spec
when
you're
reading
through
you'll
see
them
and
to
give
people
opportunity
to
comment
on
those
issues.
We're
going
today.
I
know
there's
some
questions
about
scope
which
have
been
discussed
in
here
and
other
places.
A
So
it
suggests
today
that
we
don't
include
those
in
detailed
discussion.
So
if
anyone's
got
a
comment
on
scope,
so
I
don't
think
that
should
be.
There.
I
think
that
something
else
that's
missing
should
be
there.
Please
do
raise
that
if
I
suggest
today
we
don't
go
into
the
detail
of
that
conversation,
we'll
just
note
those
things
and
then
we'll
figure
out
how
to
proceed
depending
on
what
they
are
and
whether
we
need
a
one
on
one
one
run-through
to
talk
through.
A
Why
they're
not
in
scope,
for
example,
and
if
you
still
think
you
want
to
bring
into
scope,
then
great,
let's
bring
back
to
the
next
call
or,
for
example,
or
if
there's
something
that
you're
easy
in
scoping.
You
think
it
shouldn't
be
there.
Then
we
can
think
about
cost
of
implementation.
When
we
look
through
that
the
detail
of
it
with
the
developers
in
the
next
few
calls.
So
hopefully
everyone's
seen
the
schedule
that
we
sent
out
with
the
kind
of
list
of
what's
what's
coming
up
on
it.
F
A
Okay,
great,
so
this
is
yeah.
This
is
so
this
is
a
spec,
so
what
I'm
going
to
do
is
I'm
going
to
go
through
apologies
for
those
of
you
that
are
already
aware
of
this.
This
detail,
but
I
think
maybe
starting
at
the
top
allow
people
to
kind
of
get
involved
more
will
fly
through
as
well,
so
very
quickly.
To
summarize
the
concept
of
what
we're
doing
here.
This
specification
is
about
allowing
an
order
to
be
placed
within
a
booking
system,
a
booking
system.
A
In
this
diagram
you
can
see
there
is
the
system
of
record
for
bookings.
The
idea
is
that
this
specification
allows
a
broker,
which
is
any
third
party,
such
as
trainers
once
on,
is
cool
to
to
book
something
within
that
booking
system
to
place
an
order
and
there's
an
acknowledgement
in
the
specification
that
the
customer
is
interfacing
with
the
broker.
That's
the
end
end
customer
there's
also
the
acknowledgement
that
there's
a
seller
who
uses
the
booking
system.
A
So
that's
involved
in
that
and
there's
a
payment
provider
who
allows
the
facilitates
the
payment
between
these
using
move
credits
or
nectar,
points
or
monthly
and
voicing
or
whatever
you
want
loads
of
different
ways
of
doing
that.
But
for
the
purposes
of
this
specification
there,
those
gray
arrows
are
out
of
scope
and
the
focus
of
the
specification
is
purely
between
the
broker,
which
is
that
third
party,
that's
making
the
bookings
and
the
booking
system.
A
A
You
then
expect
a
registration
of
some
sort,
and
then
you
expect
booking
and
payment
to
occur,
and
sometimes
you
might
already
have
a
selection
made
in
the
app.
Maybe
it's
ultimate,
maybe
there's
a
I
involved.
There
is
automatically
doing
that
registration.
There
might
already
be
someone
logged
in
so
these
steps
don't
necessarily
need
to
be
shown
to
the
consumer,
but
in
the
background
there
is
a
an
element
of
selection
that
occurred
somehow
through
some
mechanism.
A
There's
a
way
of
registering
and
identifying
that
users
somehow
again
through
some
mechanism
they
might
be
registered
with
their
Alexa
and
there's
booking
and
payment,
which
again
is
we
will
will
occur
here.
Paying
payment
will
happen
somehow
again
through
some
mechanism,
but
the
bookings
the
spec
covers,
so
that
jump
in
if
anybody's
got
questions
on
that,
so
I
get
through
to
the
next
diagram.
A
So
this
this
is
the
way
that
the
spec
works
again
high
level.
There
is
a
kind
of
three
three
steps
here
you
go
in
and
you
say:
I
want
to
select
this
thing
and
then
you
register
it
in
you,
you
book
and
pay.
What
happens
is
at
every
point
and
journey
you
you
interact
at
the
booking
system,
but
you
do
so
in
in
a
slightly
different
way
each
time.
So
when
you
select
a
thing,
you
go
to
the
booking
system
and
say
I
want
to
make
that
booking.
A
And
then,
when
you,
when
you,
when
you
do
sorry
well,
you
you
know
someone
make
that
book.
You
say
I
want
to
quote
for
what
that
button
would
look
like
if
I
do
make
it
so
you.
So
that's
what
the
checkpoint
one
is
so
I
want
to
know
if
I
can
make
this
and
what
it
would
look
like
and
the
response
comes
back
a
checkpoint
one
with
the
kind
of
the
result
of
the
basket
so
I
want
item
one
I
want
them,
because
it's
seven
o'clock,
the
result
comes
back.
Okay.
A
Great,
that's
number
course
is
gonna
have
fifty
P
of
tax
on
it.
It's
gonna,
be
this
total
and
it's
available.
It's
the
idea,
so
checkpoint
one
is,
is
the
anonymous
version
of
that
checkpoint?
Two
is
exactly
the
same.
You
say
I
want
to
book
that
summer
class.
It
comes
back
and
says
it.
Yes,
it's
available.
Here's
the
tax
additionally
in
checkpoint
two.
It
also
allows
you
to
pass
in
details
of
the
person.
A
That's
wanting
to
make
the
booking
and
and
the
reason
that's
useful-
is
because
a
checkpoint
one
and
checkpoint
two,
the
booking
system,
can
optionally
reserve
a
swap
is
called
a
lease.
While
this
is
happening,
so
the
thing
doesn't
get
nicked
from
their
shopping
basket
by
some
other
user
when
they're
getting
to
the
end
of
their
journey,
and
so
that's
really
the
purposes
of
these
two.
A
It's
optional
leasing,
but
everyone
makes
those
call
every
broker
will
make
those
two
calls
to
say
you
know
once
the
bar:
what's
the
shopping
basket,
look
like
effectively,
what's
the
total
and
the
taxes
involved
and
then
again
when
you've
got
more
information
about
the
user
and
both
times
booking
system
has
an
opportunity
to
make
a
lease.
Optionally
doesn't
have
to
do
that
and
then
finally,
the
booking
is
made.
A
So
the
broker
will
instruct
the
payment
provider
to
authorize
a
payment
which
is
a
temporary
again
effectively
another
lease
on
the
payment
itself
and
then
confirm
the
booking
with
the
booking
system.
And
then
we
capture
payment
that
last
step,
which
is
effectively
confirming
the
authorization
capturing
the
payment.
If
there's
a
failure
that
happens
before
that,
the
authorization
automatically
gets
removed
by
the
payment
provider
anyway
and
and
so
the
payment
is
never
captured.
G
A
A
So
the
way
this
works
is-
and
thank
you
in
for
your
your
interim
feedback.
I
know
that
you've
your
confusion
to
this
diagram
and
other
places
very,
very
valuable
indeed.
So
when
we
said
that
first
checkpoint,
that's
c1,
calling
it
so
c1
that
first
checkpoint
of
I'm
gonna,
see
if
my
shopping
basket
looks
like
honestly,
that's
a
put
with
an
object
with
what's
called
an
order
quote.
They
include
some
information.
A
So
broker
takes
the
EU.
Id
takes
the
shopping
basket
constructs
the
order
quote,
gives
it
to
the
booking
system.
Booking
system
comes
back
with
the
total,
and
the
availability
so
happens
in
at
this
time
again
with
the
user
details.
If
that's
available,
you
send
that
through
and
then
you
get
back
again
the
the
availability
and
the
total
payment,
then
the,
as
we
just
mentioned
before,
the
broker
will
authorize
the
payment
with
the
payment
provider
and
then
made
that
final
call
of
the
order,
which
is
a
full
order.
A
A
You
also
at
this
point
pass
in
the
payment
identifier
that
you
will
have
got
through
authorization
so
that
you
can
link
the
payment
together
just
for
all
dit,
so
the
booking
system
at
least,
has
that
information
about
what
the
payment,
what
the
payment
is
and
then
what
that
does
is
that
that
confirms
that
with
the
booking
system,
and
then
this
is
a
slight
change.
That's
happened.
The
result
comes
back
from
the
booking
system.
A
That
booking
is
successful
and
in
the
previous
version
this
was
actually
the
our
PDE
feed
that
did
that,
but
because
it's
likely,
as
was
pointed
out
in
the
feedback
that
we
probably
want
to
be
able
to
link
other
metadata
about
the
user
or
the
transaction,
some
other
stuff
that
the
broker
might
have
been
doing
other
than
just
the
order.
You
probably
want
to
be
able
to
save
down
the
results
of
this.
This
call
this
order
and
at
that
point
say
that's
the
order.
A
This
one,
so
their
payment
authorizing
capture
are
the
two
steps
of
making
a
two-step
payment.
So
the
the
authorized
step
is
saying
to
the
credit
card
company.
We
would
like
to
authorize.
It
happens
when
you
book
a
hotel
room
generally.
I
would
like
to
authorize
80
pounds
to
authorize
seven
pounds
on
the
card
just
just
to
lock
that
amount
down,
so
it
can't
be
spent
by
anybody
else.
So
if
you've
only
got
seven
pounds
of
your
credit
cards,
credit
limit
left
that
will
that
will
take
that
away.
A
So
you
can't
use
your
credit
card
for
anything
else.
So
that's
locked
down
and
guaranteed
and
the
capture
payment
is
actually
when
the
funds
get
transferred,
though
you
authorize
first
to
lock
that
money
down
in
the
credit
card
and
then,
when
you
capture
it,
that's
confirming
the
transaction.
What's.
A
You
don't
tell
the
booking
system
in
this
case
here,
so
the
so
the
booking
and
payment.
So
first
of
all
the
SAR,
it's
obviously
because
you
can't
see
at
the
top
of
the
isn't
it
there
we
go
so
yeah
there
we
go
so
here.
The
broker
first
of
all
calls
the
payment
processor
to
authorize,
and
then
the
broker
admits
that
order
to
the
booking
system
with
the
payment
identifier
and
then
at
that
point,
the
booking
system.
As
far
as
the
booking
system
is
concerned.
At
that
point
the
deals
done
it's
in
completed
and
acknowledge.
E
A
A
A
A
Represented
in
the
transaction
flow
and
they
are
reseller
broker
and
agent
broker,
so
the
difference
between
the
reseller
broker
and
the
agent
broker
is
it's
a
different
contractual
relationship
between
the
customer
and
the
seller?
So
just
quickly,
what
that
means
is
a
reseller
broker
owns
the
inventory.
So
it's
a
bit
like
if
you
have,
if
you
have
theater
tickets,
if
someone
books
a
coach
load
of
people
in
two
seats
in
the
theater
they'll,
buy
all
those
seats
and
then
they'll
sell
the
tickets
to
the
coach
tour
and
sell
them
one
by
one.
A
But
the
key
thing
is
that
the
reseller
has
bought
the
season
seats
in
advance
and
that's
what
the
reseller
broker
model
is
p.m.
pays.
You
German
and
some
others
do
this,
and
so
in
that
case
you
would
buy
from
the
seller.
That's
one
transaction
and
then
separately,
you
would
the
you
would
then
resell
those
seats
or
resell
the
the
past
day
pass
or
whatever
it
is
again.
The
focus
of
this
is
about
the
immediate
transmedia
interface
with
the
order,
and
so
that
is
between
the
reseller
broker
and
the
seller,
and
that's
what
we
would.
A
So
there's
an
if
there's
a
tax
exemption
in
the
UK,
which
a
lot
of
the
letter
Trust's
are
covered
by
which
basically
means
that
the
customer
can
purchase
from
the
seller
if
the
seller
is
selling
certain
leisure
activities
without
any
tax
as
no
v80,
and
so
that
that
only
applies
in
this
scenario.
It
doesn't
apply
in
the
previous
reseller
scenario,
and
for
that
to
happen,
the
contractual
relationship
has
to
between
be
between
customer
and
the
seller,
and
in
that
case,
all
the
age
of
brokers.
Doing
is
really
allowing
that
to
happen.
A
It's
brokering
it's
a
bit
like
eBay.
You
see,
you
know
that
you're
buying
something
from
another
known
seller
on
there,
but
maybe
not
as
obvious
as
eBay
as
a
marketplace,
but
what
that
means
is
as
a
as
a
broker
in
the
agent
broker
world.
You
need
to
be
really
clear
that
you're
not
selling
your
own
stuff.
A
So
if
you're,
if
you're
a
broker
picking
on
trains,
one
for
example,
if
you're
selling
some
an
activity
can't
be
branding
at
train
as
one's
activity,
you
have
to
brand
as
infusions
or
whoever
the
actual
salaries
and
make
that
really
clear.
That's
who
you're
purchasing
from
within
the
interface
within
the
experience
and
so
that
that's
there
for
customers,
qualified
tax
exemption
and
then,
if
you
want
to
do
things
like
taking
a
cut
of
you,
know
the
fees
or
whatever
commercials
you
want
around
that
in
terms
of
the
commercial
relationships
between
the
different
parties.
A
A
A
So,
and
so
now
you
understand
the
roles
that
the
broker
plays.
Hopefully
this
becomes
a
bit
clearer
and
that's.
This
is
the
separation
of
the
different
concerns.
If
you
looks
after
what,
so
the
booking
system
is
purely
concerned
with
orders,
that's
what
the
booking
system
is
concerned
with
and
the
payment
provider
is
concerned
with
payments
and
refunds.
A
The
broker
is
the
only
is
the
only
actor
in
this
that
has
visibility
of
everything
and,
additionally,
to
that
that
the
system
of
record
for
the
invoices
and
that's
important,
because
the
invoice
is
a
legal
document,
you
need
to
maintain
versions
of
the
invoice
every
time
you
change
it,
and
so,
rather
than
over
complicating
the
booking
system
side.
That
decision
was
made
a
few
weeks
ago
to
move
that
into
the
broker,
so
there
would
be
simpler
for
everybody
else
and
also
more
flexible
for
the
broker.
A
In
their
models,
so
they
might
want
to
do
monthly
invoicing
or
daily
or
just
a
receipt
for
a
pay-as-you-go
or
whatever
they
want
to
do,
and
also
with
the
invoice
that's
generated,
they
might
want
to
use
different
currencies
like
move
credits
or
nectar
points
or
whatever
else
or
employee
wellness
vouchers,
and
so
because
the
invoice
is
likely
to
involve
a
lot
more
than
you
want
to
put
into
the
booking
system.
The
idea
is
that
the
invoice
is
generated
at
the
point
where
that
diversity
exists,
which
is
the
broker
and
it's
the
brokers,
responsibility.
A
Therefore,
to
maintain
that
legal
document,
which
then
explains
what
will
come
on
so
you're
talking
about
feeds
because
the
invoices
exist
in
the
broker.
If
there's
any
changes
to
the
order,
then
you've
got
to
keep
up
to
date
with
the
what's
called
the
orders
feed
of
the
booking
system
as
a
broker.
In
order
to
make
sure
you
get
those
changes
coming
through,
and
so.
F
A
A
It's
20
percent
everything
everywhere,
whereas
it's
not
it's
change
of
state
by
state
in
the
US
and
it,
and
so
there
are
two
different
modes:
that's
tax
net
and
tax
gross,
and
this
is
saying
now
is
in
order
to
comply
with
the
booking
spec.
You
need
to
state
which
mode
you
are
using
and
do
that
at
the
cellar
level,
and
it
seems
to
be
common
across
a
lot
of
systems
that
it's
at
the
cellar
level,
that
this
is
a
distinction
as
maids.
You
can't
have
some
items
in
you
in
you.
A
A
Okay,
okay!
So
that's
what
that's
about
and
the
idea
is
it's
at
the
cell
level
so
that
it
could
be
the
booking
system,
support
both
and
allow
sellers,
if
they're,
an
international
organization
to
pick
whichever
one
suits
them
best.
A
C
A
Me,
okay,
great
so
first
issue
here
is
a
question
of
scope.
So
I
won't
labor
the
discussion
in
its
Jessie
label
discussion
here,
as
we
discussed
before,
but
I'm
flagging
it
so
that
you
guys
can
think
about
whether
you
want
to
comment
on
this
issue
and
comment
on
this
issue.
Just
click
on
the
issue
you'll
be
in
github.
You
can
then
just
add
a
comment
that
you
like,
like
so
I
open
a
new
tab.
You'll
see
that
github
issue
is
linked.
There's
already
a
comment.
I
believe
I
pasted.
A
The
ins
comment
in
here
from
legend,
so
you
can
read
that
so.
So
this
is
a
question
about
price
overrides
the
purpose
of
price
overrides
this
booking
spec
because,
as
we
mentioned,
puts
most
of
the
earnest
of
the
diversity
of
the
different
types
of
payments,
etc
on
to
the
broker
to
really
allow
for
that
full
scope
of
innovation.
A
The
only
thing
that's
not
possible.
The
only
business
model,
that's
not
possible
using
the
spec
as
it
stands.
Without
this
section
is
price
variable
ization
and
that's
the
case
of,
for
example.
If
you,
you
might
have
a
situation
where
you
want
to
agree
certain
prices
to
resell
certain
certain
items,
so
you
might
say
that,
for
example,
through
a
particular
broker
is
the
case
that
all's
number
classes
are
5
pounds
if
they're
from
gll
right.
A
For
some
reason,
you've
agreed
that
we
gon
GL
is
happy
with
it.
Maybe
it's
part
of
a
national
campaign,
maybe
it's
like
a
weekend
crazy,
sale,
whatever.
That
is,
as
you
just
want,
a
blanket
all
yours
and
possibly
five
pounds
and
it'll
come
out
in
the
wash
if
they're,
more
or
less.
This
is
what
that
enables
you
to
do
see
you
as
you
broke,
you
override
the
price
of
the
offer
and
that
allows
you
as
as
a
broker
to
say
it's
5
pounds
and
then
they
broke.
A
This
spec
provides
all
the
facilities,
but
the
commercial
relationship
is
what
lets
people
know
what
they
can
do
so,
for
example,
if
someone
signs
our
deal
with
GLL
for
those
number
classes,
and
they
start
also
offering
yoga
classes
or
some
other
class
for
five
pounds
in
it,
not
within
the
deal
that
they
have
greed,
they
will
be
able
to
do
it
within
the
system.
There's
nothing
to
stop
them
doing
that.
A
Of
course,
their
contract
probably
won't
last
very
long,
because
they'll
have
gone
against
that
contract
and
they
could
well
be
out
in
the
cold
and
lose
that
that
contract
and
so
obviously,
as
with
every
commercial
relationship,
you
want
to
honor
your
commercial
contract
so
and
continue
to
build
trust
and
do
business.
That
way,
and
so
in
this
case
and
one
principles
of
this
is,
we
won't
put
the
complexity
in
the
spec
of
fine-grained
access
controls
and
trying
to
you
know,
get
into
a
detail
of
all
of
that
stuff.
A
D
A
A
No
worries,
okay,
great!
So
so
that's
that
and
then
something
else.
That's
that's
that
that
I
just
wanted
to
clarify
this.
Just
me
in
since
the
last
version
is
book
ability
and
so
basically
designed
in
the
open
feeds
which
are
available,
and
many
of
you
will
already
be
involved
with
either
using
or
publishing
that
data
there's
a
number
of
things
that
make
a
session
bookable,
and
so
things
like
if
the
available
channel
is
equal
to
it,
has
got
the
value
open
booking
payment.
A
So
that's
something
that
you
sense
at
the
event
level
if
the
end
date
is
not
in
the
past,
and
that
is
that
the
so
that
allows
you
to
book
something
even
after
it's
started,
but
that
seems
it
seemed
reasonable
to
do
that
again
after
I've
to
go
to
the
book
went
to
me
any
thoughts
to
shout
on
that.
It
seems
to
me
any
reason
not
to
ask
someone
to
do
it
late,
just
in
case
doing
it
as
I,
going
to
the
turnstiles
and
they're
so
late
to
their
own
class.
A
There
must
be
enough
capacity
near
the
remaining
attendee
capacity
or
remaining
users,
so
there
must
be
enough.
Space
is
basically
the
potential
action
which
basically
means
the
potential
action
at
the
basic
site
includes
the
open
booking.
Action
basically
means
that
the
open
booking
API
is
enabled,
so
you
wouldn't
be
a
booking.
Otherwise,
there's
this
thing
called
valid
before
valid
from
before
start
date,
which
basically
means
there's
a
book
head
window.
It's
one
of
the
things
that
came
out
the
legend
workshop
with
with
their
customers,
but
you
can.
A
You
can
specify
a
global
window
which
is
they're
going
to
affect
all
brokers,
which
is
a
window
within
which
you
can
book
before
an
activity
starts.
So,
for
example,
you
can
only
book
a
squash
court,
seven
days
in
advance.
You
can't
book
it
eight
days
in
advance
and
a
blanket
all
brokers
have
to
abide
by
that
rule
is
there?
Is
the
idea
of
that
and
then,
as
we've
mentioned,
the
tax
mode
has
to
be
specified,
so
you
must
have
you
must
choose
tax,
gross
or
tax
net,
and
does
that
seem
as
that?
A
A
E
J
A
A
J
J
A
Great
yeah,
the
reason
it's
not
as
simple
as
just
a
book
of
all
is
true
flag,
as
you
probably
noticed
these.
These
things
here
are
all
in
different
parts
of
the
feed.
So
the
idea
is
that,
because
these
things
change
over
time,
things
like
capacity
and
status
and
end
dates
because
they
change
over
time.
It
means
that
you
can.
You
can
look
at
a
feed
and
without
needing
to
update
everything
in
the
feed
when
it
becomes
book
learns
or
not.
A
You
can
figure
out
whether
you
should
expect
to
make
it
make
it
book
a
book
which
just
reduces
the
amount
of
overall
traffic
in
the
whole
system,
because
we'd
be
updating
step
all
over
the
place,
as
things
become
but
again
there's
there
might
be
an
argument.
We
should
just
have
a
look
at
all
this
true
flag
and
then
make
the
feeds
busy,
but
I
suppose
we
can't
even
do
that,
because
their
remaining
attendee
capacity
depends
on
what
you're
trying
to
book
so
I.
A
E
Based
on,
but
every
time
someone
books
on
to
the
activity
you
potentially
have
to
update,
the
feed
obviously
depends
on
the
frequency
of
certain
you
through
the
RDP,
a
yeah,
so
all
you're,
really
adding
to
that,
is
any
changes
to
the
feed
that
relate
to
value
from
before
start
textbook.
It's
just
not
gonna
happen
ever
so
I'm.
Just
moving
with
that
in
your
book,
able.
A
Yeah,
that's
a
good
point
actually,
so
we
might
be
able
to
take
things
like
available
channel
status
and
end
dates,
tensioning,
yeah,
well,
I,
suppose
I
suppose.
Maybe
the
maybe
one
one
thing
to
say
is
at
the
moment:
there's
nothing
in
the
feed
that
requires
updating
as
time
passes
on
its
own.
The
things
in
the
feed
only
change.
If
something
gets
booked,
as
you
say,
have
something
like
end
dates,
encoded
as
a
boolean.
You
would
need
to
have
some
kind
of.
A
A
A
A
Basically
saying
that
started
started
the
where
you
are
in
the
in
the
air
in
the
tree,
so
whatever
thing
you're
trying
to
book,
if
that's
the
scheduled
session
start
there
and
then
work
your
way
up,
only
accepting
new
offers,
if
you
haven't,
got
something
that
conflicts
with
what
you've
already
got.
So
you
kind
of
look
at
the
parent,
okay,
there's
a
new
offer
include
that
that
we've
already
got
that
one
don't
include
that
and
the
idea
here
is
to
use
the
identifier
property
to
identify
if
there's
the
same
offer
being
overwritten.
A
A
A
Can
override
yeah
well,
the
rule
is
that
any
property
can
be
overridden,
so
it's,
but
within
within
the
scope
this
spec
the
focuses
around
the
the
offer.
So
not
so.
This
is
probably
not
quite
right,
because
the
offer
itself
is
here.
So
let
me
show
you,
this
is
the
parent
level.
This
is
the
child
level.
Sort
of
would
look
like
is,
is
this
so
you've
got
an
offer,
which
is
you've
got
the
offer
at
the
scheduled
session
at
when
you've
got
the
offer
at
the
parent
level,
and
in
this
case
they're
the
same.
A
D
A
Good
okay
I,
like
that
yep,
so
there's
a
thing
that
we
might
want
to
disable
or
something
an
offer
in
that
hierarchy:
okay,
yeah,
that's
a
good
point:
I
got
the
list
so
great
and
then
we're
into
cancellation
so
and
that
covers
it's
gonna
cover
our
last
few
issues.
Anyone
have
any
quick
points
before
moving
on
so
making
sense.
So
far,.
A
Okay,
so
cancellation,
one
of
the
things
that
is
an
issue
here
is
that
arbitrary
refunds
are
not
in
scope.
I
know
this
is
a
participant
you
aren't
on
this
call
before
on
the
previous
call,
it's
an
issue
that
I
think
they
would
they
cared
about
in
terms
of
in
their
system.
You
can
basically
choose
how
much
of
a
particular
item
to
refund.
You
can
say:
I've
got
a
squash,
but
I'm
only
gonna
read
the
monthly
to
perfectly.
A
But
again,
if
anyone
has
a
needless
to
scope,
question
anyone
has
any
views
on
that.
You
do
want
arbitrary
funds
to
be
included
in
the
scope
at
this
stage
and
that's
important
as
I
kind
of
make
or
break
for
whether
this
works
as
a
v1
I.
Think
the
general
view
here
is:
if
we
can
make
all
this
work
without
it
and
it's
not
show
stuff
with
them,
probably
best
keep
out.
But
if
there's
a,
if
it
is
a
showstopper,
then
that's
the
issue.
Please
do
comment
on
that
issue.
I
know.
A
A
D
A
That
was
great.
Thank
you,
okay,
so
cancellations
that
we
do
the
final
bits
of
this
so
cancellations.
This
is
effectively.
We
talked
about,
there's
a
feed
and
in
that
feed
there
are
items
that
may
have
already
been
booked
well,
will
have
already
been
booked,
and
there
are
two
ways
you
can
cancel
something
and
the
cancellation
can
either
come
from
the
seller
or
from
the
customer.
So
the
venue's
flooded,
the
seller
cancels
the
customers
feeling
ill,
the
customer
cancels.
So
with
the
customer
cancellation
scenario.
A
Obviously,
the
customers
got
to
request
that
and
the
customer
uses
the
broker
to
request
that.
So
in
that
case,
what
happens
is
the
broker
looks
at
the
is
always
keeping
an
up-to-date
you
on
the
orders
from
the
speed
so
they'll?
Have
it
they'll
have
an
awareness
of
the
order
because
it
all
have
been
stored
when
they
made
the
booking.
So
the
broker
will
know
about
the
order
and.
A
The
order
item
in
there
that
what
they
do
is
they
send
a
patch
and
say
I
want
to
cancel
this
customer
cancels
if
they
get
a
success
back.
That
means
that
the
cancellation
team
processed,
they
don't
do
anything
else.
They
wait
and
then
on.
The
feed
will
arrive
from
the
booking
system,
back
translation
confirmation,
so
they
say
cancelled
done
and
then
you
said
it's
in
little
notes
the
users
saying
your
translations
being
processed
later
on
a
minute
later
or
five
minutes
later.
The
feed
comes
back
with
customer
cancelled.
A
A
C
C
A
E
E
A
E
Previous,
whoever
was
speaking
sorry
for
yesterday
and
that
the
the
idea
here
is
that
this,
the
last
ones
we
should
cancel
so
before
that
you
get
the
refund
and
that
will
be
refunded
the
whole
amount.
After
that,
you
get
nothing
so
over.
You
can't
cancel.
So
that's
the
least
common
denominator.
I
think
with
the
challenges
with
the
booking
API
that
we
Trent
develop,
is
to
get
to
a
least
common
denominator,
because
we
will
try
capture
all
the
complexities
it
will
never
ever
ever
ever
ever
ever
be
finished,
although
severs
were
for
a
good
reason,.
E
So
I
think
that
you
know
if,
if
you
can
support
having
the
option
of-
and
you
can
say
what
the
cancellation
period
is
so
when
you
say
yes,
here's
the
offer,
you
can
council
up
to
two
hours
beforehand
and
we'll
give
you
money
back
after
you
can't
cancel.
Well,
that's
a
simple
case.
Perhaps
in
your
real
system,
people
still
cancel
but
don't
get
the
refund.
But
if
you
cannot
provide
that
window
gives
a
slightly
less
useful
functionality.
You've
tried
to
talk
to
different
audience
here
to
the
the
man
in
the
street
as
a
person.
A
E
I
think
we
should
have
that
there,
because
he
provides
enough
functionality
to
control
for
the
platform,
so
how
cancellation
will
be
managed
in
the
sense
of
before
this
time.
You
can
constantly
get
money
back
off
its
own
counter
and
that's
the
simplest
way
of
allowing
cancellation
with
refunds
yeah
anything
more
than
that
I
think
we
all
have
different
ways
of
doing
it.
So
we
need
to
capture
that
as
a
one
point
one.
If
we
can
work
with
this,
that
would
be
easiest
to
import.
C
So
I'd
actually
I
test
that,
and
so
the
easiest
way
to
implement
it
and
actually
support
everyone
would
just
be
for
that
cancellation
to
say
whether
they're
eligible
for
a
refund
or
not.
You
know
we
can
revise
partial
refunds
and
that
later,
but
there's
many
more
scenarios
than
just
your
insider,
a
refund
window
as
to
whether
someone
is
eligible
for
a
refund
and
I,
don't
think
the
two
should
be
coupled
I
understand.
A
A
Great
thank
you
and
I
guess
Wayne's
at
you.
It
doesn't
happen,
however.
Now,
as
you
brought
that
things,
that's
really
helpful.
Thank
you.
Okay,
so
swiftly
moving
through
there.
Sorry
to
have
to
expedite
the
conversation.
I
can
see
both
sides
of
that
allowing
halt
order.
Cancellation,
I
think
we
just
talked
about
this.
There's
a
question
about.
Oh
no.
We
sorry
we
haven't
looked
like
this.
Yet
this
is
a
very
simple
question.
A
The
items
have
the
status
of
either
they're
confirmed
or
they're
canceled,
but
the
order
itself
is
a
just
a
shell,
it's
an
empty
shell,
it
doesn't
have
its
own
life,
it
just
exists.
Behold
it's
the
things
within
it
and
I'm.
Simplifying
that
out,
so
it
doesn't
have
its
own
status
is
one
of
the
things
that's
happened
here,
but
if
there's
any
reason
for
again
I'll
just
sign
to
that
issue,
and
the
contribution
very
well
come
on
that.
A
If
there's
any
reason
that
you
can
see
why
you
want
to
be
able
to
cancel
a
whole
order
without
making
those
individual
calls,
which
obviously
has
some
complexity
in
terms
of
implantation
but
the
booking
system,
but
we
might
argue
for
some
reason
that
that
is,
is
better
and
and
so
I
guess.
That's
that's
that
if.
D
D
A
Okay,
good,
so
you
want
to
maybe
make
that
yeah.
It
just
says
thought
it
complexly
the
patch.
So
there's
a
there's,
an
argument
that
actually
that
that
patch
should
actually
be
a
patch
to
the
to
the
order,
rather
the
patch
the
order
Ison.
And
then
you
can
include
what
you
want
to
cancel
as
one
go
and
do
that
then,
and
maybe
we
simplify
it.
That
way.
A
A
There's
something
in
here:
we
have
around
natural
batching.
So
what
this
is
saying
is:
if
you
make
a
number
of
changes
to
an
order,
then
those
ordered
those
summarizing.
This
whole
thing.
Those
changes
don't
come
through
to
the
feed
for
about
30
seconds
or
whatever
30
seconds.
30
second
delay
and
exist
for
two
reasons
one
is
is
if
we
were
to
do
multiple
translations,
which
it
sounds
like
we
might
actually
switch,
so
we're
not
having
any
more.
The
other
thing
is
that
there's
a
race
condition
here.
A
B
A
I
knew
this
is
coming
sorry.
We
have
hit
our
time
box.
Thank
you,
everybody
for
your
contribution,
so
far,
I'll
I'll
flag,
that
there
are
a
couple
more
issues
in
here
and
I
just
quickly
pointing
them
out
there's
one
around
at
the
moment
the
orders
feed
doesn't
include
detail
of
the
actual
underlying
logistics.
So
if
there's
a
change
of
the
start
time
of
an
event,
currently
the
order
field
isn't
updated.
A
The
responsibility
is
on
the
the
broker
to
read
the
actual,
live
open
feed
and
get
those
changes
and
relay
them
on
which
reduces
some
complexity
from
the
broker
from
the
from
the
booking
system.
So
that's
an
issue.
I
would
love
your
thoughts
on
it.
Maybe
when
she
wave
his
hand
quickly,
there's
disagrees
because
then
we
know
he
disagrees.
You
might
never
have
time
to
comment
on
absolutely.
E
A
A
So
please
do
read
through
and
the
next
step
this
everybody
knows
is
to
have
somebody
privacy
in
an
email
we're
looking
for
developers
to
start
to
design
what
it
would
look
like
in
their
systems
to
implement
against
this
spec
and
that's
really
important
because
it
means
you'll
come
face
to
face
with
some
of
the
challenges.
That's
involved
in
doing
that
and
so
we'd
love.
A
If
you're
interested
in
that
just
ping,
us
an
email
reply
to
the
email,
vise
and
round,
say
you're
keen
so
that
we
know
who's
doing
what
and
next
call
will
be
in
two
weeks
time
and
we'll
be
doing
a
bit
like
what
we've
just
done,
but
specifically
focusing
on
implementation,
and
you
need
developers
to
begin
to
implement,
get
involved
and
raise
any
questions.
They've
got
and
we
can
also
deal
with
any
any
other
small
feedback.
The
idea
we're
in
finalization
so
making
small
changes
like
we
did
to
the
patch.
A
That's
what
we're
expecting
to
be
doing
here
and
as
we
move
through,
we
should
see
that
we
restart
getting
to
the
point
of
consensus
around
the
whole
thing
and
everyone
agreeing
on
it.
So
thank
you.
Everybody
putting
up
with
the
expedited
nature
of
the
call
and
yeah,
hopefully
see
you
guys
in
a
couple
of
weeks.