►
From YouTube: OpenActive W3C Community Group Meeting / 2019-03-27
Description
A public hangout for members of the OpenActive W3C Community Group.
https://w3c.openactive.io/meetings/2019-03-27-booking-overview-and-feedback
A
A
Well,
thanks
everyone
for
joining
again
I
mean
it's
a
good
progress
on
the
booking.
Spec.
Well,
I
haven't
been
here
last
couple
of
weeks
because,
with
the
commitments
I've
been
kept
up
today
by
Nick,
so
I'm
glad
to
see
that
things
are
progressing
and
we've
got
to
get
close
to
having
a
spec
done
so
in
terms
of
gender.
For
today,
just
get
the
slides.
A
So,
as
Nick
slick
laid
in
is
email
this
week,
there's
a
few
things
that
we
want
to
cover
as
description
points
today,
all
right,
some
specific
areas
of
the
spec
that
we've
had
some
feedback
and
discussion
around
run
through
again.
What
the
implementation
looks
like
and
they're,
just
briefly
and
of
key
dates
coming
up
over
the
next
few
weeks
to
try
and
get
this
over
the
line
and
I'm
going
to
Nick
to
take
us
through
their
kind
of
detailed
discussion.
B
John
can
sure
so
I'm
hoping
that
and
at
some
point
is
called
as
two
people
who
have
said
they're
going
to
join
in
order
to
discuss
one
of
the
points
on
here.
If
they
don't
join
and
I'm
gonna
I,
don't
know
if
I
can
be
three
people
trying
to
represent
everyone,
but
well
we'll
play
that
by
ear.
So
that's
the
approval
flow
and
that's
the
last
on
the
list.
For
that
reason,
so
any
luck.
B
Something
change
plans,
okay,
so
the
I
guess,
first
of
all,
before
we
get
into
the
discussion
points,
I
don't
know
if
anyone
has
anything,
they
would
I
mean
I
know
show,
have
you've
been
kind
of
looking
at
it
from
merchants
perspective
and
kind
of
getting
into
the
detail
of
that
Phil
and
Ian
on
the
call.
I
know
that
you've,
both
from
a
science
perspective,
being
you
kind
of
look.
We
went
through
that
in
a
meeting
last
week
and
kind
of
covered
the
high-level
points
of
what
the
spec
was
about.
C
Hi
Nikki
yeah,
so
I've
been
looking
into
the
spec
and
I
probably
send
you
an
email
about
some
points.
I
mean
there
are
some
things
which
we
I
mean
these
complex
I
mean
we
need
to
do
some
quite
a
lot
of
work,
so
this
I
mean
I
laughter.
Send
me
some
lists
of
questions
and
see
discussed
in
detail
some
of
the
things,
but
at
the
moment
and
I
don't
have
anything
to
raise.
Okay,
okay,.
B
Okay,
great
thanks
Phil,
so,
okay,
in
that
case,
let's
get
into
the
some
of
the
content
of
this
then
so
access
control
is
the
first
point.
I,
don't
know
if
you're
able
to
get
the
bookings
back
up
there,
Lee
and
just
just
go
to
the
access
control
section.
As
leaves
already
pointed
out,
access
control
is
probably
not
the
best
name
for
it.
I
think
it's
like
eight
point,
actually
have
no
idea.
I
just
made
that
up
somewhere.
B
Eight
point:
nine
point:
seven,
seven
eleven!
So
so
we've
had
some
discussions,
our
access
control,
but
not
not
brought
them
to
this
group.
I.
Think
that's
fair
to
say
we
haven't
heard
a
detailed
conversation
here
and
and
so
that
that
is
purpose
of
this,
bringing
this
little
bit
too
light
for
everybody.
And
what
will
this
means
access
control?
This
isn't
kind
of
date.
Base-Level
access
at
least
pointed
out.
B
Who
will
need
to
understand
that
they
can
let
someone
through
as
well
so
there's
that
angle
too,
and
so
what
what
we
tried
to
do
with
this
access
control
stuff
here
really
is
provide
the
variety
of
options
for
that
kind
of
proof
of
purchase,
being
machine,
readable
but
also
human
readable,
so
that
you
can,
you
can
get
into
the
site.
Basically
when
you,
when
you
actually
have
your
ticket,
if
it's
a
mobile
ticket
or
if
you
printed
out
so
in
the
conversation
with
Gladstone
on
Friday,
it
was
raised
a
really
good
point,
around
particular
IDs.
B
In
the
car
system
that
you
would
need
to
get
to
present
to
register
in
order
to
gain
access
and
that
actually
shine
a
light
on
that,
the
current
access
control
stuff
we
had,
which
was
really
very
rough
and
as
more
of
an
extension,
really
wasn't
sufficient
for
even
basic
access,
so
I
can
I
just
quickly.
Take
you
through
the
three
types
of
access
control
we've
got
in
here
and
then
it
would
be
great
to
hear
from
you
guys
whether
that
you
think
that
covers
and
I
am
Jamie
and
Tommy.
B
You've
obviously
got
experience
across
a
lot
of
broader
operators
as
well
that
you're
working
with
so,
and
so
so
that
would
be
really
good.
So
access
control,
the
three
types
we've
got
here:
text
based
access
control,
which
is
a
pin
code
or
a
booking
reference.
These
are
human,
readable
properties.
So
this
is
the
idea
is
that
we've
got
a
name
and
description
kind
of
pair
that
you
can
use,
and
you
can
supply
multiple
of
these
and
the
idea
being
that
in
a
different
system
or
in
a
different
setting,
you
might
call
it
something
different.
B
A
B
If
I
just
cover,
if
I
cover
the
next
two
and
then
we
also
image
based
very
similar
to
that
except
it's
an
image,
this
is
for.
If
you
wanted
to
provide
a
pre-rendered
bar
code
or
a
QR
code,
you
could
just
put
that
in
and
exactly
the
same
as
the
previous
and
then
the
extension
point
is
to
allow
for
rendering
of
barcodes.
So
there
are
barcode
libraries
available.
B
If
you
tell
them
it's
a
code,
one
to
a
barcode
and
there's
the
number
and
the
certain
other
information
you
can
actually
render
that
barcode
out
and
do
that
live.
There
are
advantages
to
doing
that
versus
using
a
PNG,
that's
being
rendered
on
the
server,
so
I
don't
know
which
will
be
where
we'll
see
the
uptake
across
both.
So
this
is
currently
included
as
an
extension
point.
Originally
that
was
all
that
was
there,
but
we've
added
the
previous
two.
So
there's
now
an
image
and
text
option
so
yeah.
So
that's
the
kind
of
brief.
A
A
Say
is
that
it
would,
it
seems,
like
generally
having
and
booking
reference
or
order
ID
would
be
common
across
systems,
even
if
you
don't
need
to
present
that
in
order
to
access
a
facility
or
get
through
a
barrier
or
something.
So
my
question
was:
is
why
wouldn't
the
booking
reference
be
the
order
ID,
you
know
why?
Wouldn't
that
be
baked?
Well,
I
wouldn't
be
using
that
two
unique
identifiers
things
elsewhere
or
include
it
elsewhere
in
the
data
model,
rather
than
as
a
kind
of
code
reference.
B
B
So
there's
a
reference
for
the
order,
but
the
access
codes
are
an
order
item
level.
So
if
you
have
multiple
people,
they
could
get
each
their
own
pin
code
or
their
own
bar
codes
is
how
it's
currently
set
up
so
per
so.
There's
no
item,
there's
a
an
item
per
person
per
order,
and
that's
so
if
there's
three,
if
you've
asked
for
three
places
in
the
yoga
class,
you'll
get
three
items
and
then
therefore
you
could
supply
three
access
codes.
A
D
I
think
so,
but
I
just
say
we
haven't
really
gone
into
it
in
that
great
detail.
Yet,
since
Friday
we
haven't
had
that
much
time
to
to
examine
it.
A
great
in
great
detail,
I
mean
it
seems
reasonable,
but
I'd
like
to
reserve
final
judgment
until
I've
had
time
to
think
about
it.
A
little
bit
more
okay.
B
C
E
C
B
B
Perfect,
okay!
Well,
that
sounds
good
and
I
know
that
on
the
content
side,
that
does
they
have
the
same
register
that
you
can
use
in
and
and
check
the
email
in
the
same
way.
So
that
sounds
like
it
probably
is
parallel:
yeah,
okay
and
there's
anyone
else.
Cybil
tom
or
anyone
have
any
ideas
on
this.
Or
are
we
all
good
with
it?.
H
A
A
B
Sure
I
presume
sure
that
you,
you
include
the
bar
code
in
the
email.
Is
that
a
URL
to
a
server
somewhere
or
is
it
just
an
attachment?
An
email,
I.
C
C
It's
embedded,
although
we
do
have
people
come
sometime,
complain
like
I,
always
did
an
update
to
the
operating
system,
and
so
the
Barkers
rob
banks.
So
we
had
to
change
the
very
email
format.
So
things
like
this
happen,
but
this
is
what
I
think
we
do
just
embed
it
inside
the
email
and
then
user
just
print
this
out
of
his
phone
and
then
take
the
paper
and
swipe
it
on
the
gate.
C
B
C
So
it
work
from
the
integrator
point
of
view,
so
if
I
think,
because
I
was
hoping
that
we
would
just
return
the
my
barcode
and
it
is
up
to
the
integrator,
how
they
present
it
to
the
user
either
create
a
link
or
just
embed
it
in
an
e-mail
or
whatever
they
want
to
do
so.
From
legend
perspective,
you
just
when
the
booking
is
confirmed
when
the
orders
come
from
we'll
just
return
list
of
barcodes
valleca.
Of
course,.
B
Yes,
so
you
have
choice
here,
you
could
I
mean
I
presume
I,
don't
know
what
you
think
about
this
in
terms
of
standard
practice
Lee,
but
you
could
put
a
base64
encoded
image
URL
in
the
URL
of
the
access
token,
which
would
be
similar
to
what
browsers
do
or
you
could.
You
could
include
the
barcode
number
as
the
second
example
on
the
screen
and
allow
the
broker
to
render
that
so
chose
either
of
those
yeah.
C
B
Well,
it's
well,
it's
not
currently
specified
in
here,
but
there
is
such
a
thing
that
exists.
It's
not
it's
not
entirely
clear
to
me.
How
standardized
that
stuff
is
from
the
quick
research
at
is
online
because
the,
although
the
code
type
is
used,
is
that
so
I
mean
legend
would
generally
use
one
code
type
aldair
all
their
customers
would
have
the
same
scanners
in
place.
That
would
accept
that
code
type,
but
there
are
other
variables
to
use
as
well
like
width
and
height
and
spacing
the
all
goes
into
determining
what
that
looks
like.
B
So
the
idea,
with
this
being
an
extension
point
of
the
minute
is
that
won't
get
tripped
up
if
we
haven't
thought
it
all
through,
and
it
saves
us
going
into
the
you
know,
details
trying
to
understand
how
that
works
right
now,
yeah.
E
A
Okay,
so
yeah
now
I'm
thinking
about
quick.
She
said
that
there's
width
and
height
issues,
whether
they
should
be
something
in
in
here
or
in
the
image
based
or
the
expansion
point
to
say
the
brokenness
think
about
that
that
the
images
are
suitable
for
their
barcodes,
explain,
suitable
for
scanning,
etc.
Yep.
B
B
B
When
you've
got
the
payment
system,
that's
working,
that's
obviously
out-of-band
there
are
payments
being
taken
and
those
payments
might
well
be
deposited
into.
For
example,
a
stripe
account
which
the
Romans
so
I
watched
their
ledger
operators,
and
so
they
can,
they
can
reconcile
the
payments
that
are
in
there
with
whatever
is
in
the
booking
system.
They
have.
B
There
needs
to
be
a
certain
number
of
identifiers
to
do
that
successfully
and
it
seems
to
vary
quite
wildly
by
booking
system.
What
those
identifies
actually
are.
It
doesn't
seem
to
be
as
simple
as
a
single
ID,
which
is
then
referenceable.
There
are
things
like
Department,
IDs,
booking,
IDs
activity,
IDs
site
IDs,
all
these
things
that
are
required
for
finance
to
effectively
be
able
to
take
these
two
things
and
check
them.
If
there's
any
issues,
so
that's
that's
really
what
this
is
for
and
again
it's
not
without.
B
Without
spending
a
lot
of
time
on
it,
because
if
they
were
quote,
this
is
quite
late
in
the
day
with,
with
the
making
sure
this
is
in
there.
The
suggested
approach
here,
what
we've
we've
added
in
is
it's
quite
a
generic
thing
that
you
can
then
use
with
whatever
IDs
are
necessary.
So
if,
if
you
jump
to
or
is
that
you.
B
B
So
that's
this
again,
a
quite
a
generic
approach,
but
using
the
property
value
pattern
that
we
just
looked
at
previously
for
the
bar
codes
and
this.
What
this
allows
you
to
do
is
include
whatever
it
is
that
your
system
needs
to
to
include
so
that
you
can
so
that
the
customers
can
do
the
reconciliation
appropriately
so
site,
ID,
Department,
ID,
is
kind
of
thing
and.
B
B
Every
column
that
you
want
to
see
replicated
across
in
you
know,
basically
the
expected
behavior
here
is
that
if
you're
using
you
straw
again,
as
example,
you
would
just
put
all
of
the
properties
in
here
straight
into
stripe,
so
that
you
can
then
marry
those
two
things
together
really
easily
or
whatever
your
equivalent
payment
for
is.
Basically
a
payment
seemed
to
come
with
metadata.
You
can
attach,
so
you
just
attach
this
metadata
in
there
and
then
that
allows
people
to
check
the
things
work
with
each
other.
B
B
A
Have
a
question,
thoughts,
yeah,
so
the
way
they
specified
it
means
that
a
broker
needs
to
be
able
to
store
an
AR
between
number
of
name
value
pairs
against
every
order
item.
So
as
many
as
the
booking
system
provides,
and
then
he
says
should
but
I
think
it
would
have
to
be
a
must,
provide
them
back,
because
you
presume
that
if
they're
provided
it's
necessary
for
reconciliation
and
so
means
that
you
know
on
the
British
side,
there
has
to
be
like
just
a
set
of
tags
that
attach
to
every
order
item.
B
Yes,
I
guess
it
says
shirred
only
because
in
some
cases
the
arrangement
that
the
broker
has
with
the
booking
system
might
well
be
different
in
terms
of
I
mean
I,
don't
but
yeah.
Who
knows
what
their
reconciliation
process
is
right.
It
could
be
a
number
of
things,
but
if
they
wanted
to
use
that-
and
that
would
be
something
that
they
would
talk
about
for
a
Chanel
when
they
did
the
integration.
A
So,
there's
a
there's,
a
different
approach,
which
puts
more,
which
puts
the
work
back
on
the
book,
insists
which
there's
already
a
shared
key,
which
is
the
UUID.
So
why
can't
the
booking
system
attach
this
metadata?
To
that
shared
key
I
know
that's
for
the
order,
but
it's
still
it's
still
achievable
on
the
service
side.
If
you've
got
an
ID
for
each
ordered
item,
which
I
think
we
should
have
and
an
ID
for
an
order,
then
the
extra
metadata
can
just
be
on
the
back
end.
So.
B
B
A
Of
the
reporting
of
all
of
the
different
platforms,
so
it's
just
all
comes
down
to
where
we're
the
day
yeah.
What
was
the
minimum
required
on
both
sides
in
order
to
do
reconciliation
and
so
far,
I
thought
we
covered
that
by
just
having
shared
identify,
as
you
see,
because
the
brokers
not
going
to
do
anything
with
this
information
other
than
store
everything
that
is
provided
and
then
be
prepared
to
give.
All
of
that
back.
A
A
B
We
mind
well
need
to
talk
to
some
operational
people
from
some
of
these
ledger
operators
to
probably
get
to
the
bottom
of
that
in
Venice,
I
guess
well,
maybe
I
could
ask
I
mean
because
we've
been
talking
about
that
zone,
but
I,
don't
know
from
your
perspective
in
legend.
How
did
if
you,
if
you
people,
are
doing
reconciliation
with
their
bank
account?
You
know
what
identifies
they
use.
C
Attached
to
booking,
or
maybe
more
than
one
booking
will
share
the
same
transaction
at
either.
Part
of
the
same
order
is
what
I
think
we
use.
Currently
this,
what
you're
describing
a
very
probably
most
looks
for
that
means
to
like,
like
a
counting
system,
they
can
move
the
payment
or
link
the
payment
with
multiple
kind
of
accounts.
This
is
what
it
looks
like
and
maybe
maybe
going
forward.
These
in
some
of
our
customer
may
want
similar
thing,
but
I
don't
see
any
value
of
exposing
it
to
the
outer
system.
H
C
B
Sure,
okay,
okay,
so
it
sounds
like
it's.
Legendary
was
already
a
transaction
ID,
which
seems
are
very
similar
to
the
order
ID
that
we've
already
got
here
so
I.
Guess
it's
more
question
on
the
gladstone
side:
I'm
I
guess
filled
you
probably
in
the
same
situation.
But
this
way
we
need
more
time
to
come
back
and
maybe
even
talk
to
some
of
the
casting
customers
about
this.
G
B
D
B
D
B
F
I
just
said
it
wouldn't
sound
sensible
to
have
a
kind
of
single
source
of
truth
because
I've
in
our
time,
with
interacted
with
a
few
different
finance
teams
and
we've
tried
a
system,
we
managed
the
reconciliation
basica
before
and
the
problem
is,
is
maintaining
that
database
under
finishing
changes.
Making
sure
that
they,
let
us
know
is
always
been
quite
a
difficult
task,
so
it
would
make
sense
to
have
it
managed
on
the
software
side.
F
B
In
this
scenario,
we're
talking
about
and
let's
say,
monocle
pitch
integrated
with
everyone
active,
then
how
would
you
so
they
may
have
a
they'll
be
able
to
be
a
debit
stripe
account
when
actor
would
own.
The
money
would
be
deposited
there
and
then,
especially,
what
this
is
saying
is
that
that
when
you,
when
you
put
the
money
in
there
on
the
stripe
account,
you
would
put
these
IDs
against
it.
So
they
can
do
the
reconciliation
on
their
side
to
make
sure
they're
being
paid
for
everything
that's
being
transacted
on
oh
I'm,
so.
F
We
know
so
when
we
put
the
money
in
their
strife
account.
We
would
include
the
reference
for
that
booking
and
we
also
includes
metadata
so
like
the
the
new
sport
format,
time
and
date,
but
the
actual
financial
reconciliation
data,
which
can
be
quite
complex
depending
on
the
operator
and
the
finance
requirements,
can
just
be
a
whole
different
kettle
of
fish.
So
all
what
tends
to
happen
for
us
is
that
we
supply
no
separate
report.
That
summarizes
the
bookings,
but
that's
done
outside
of
the
integration.
That's
done.
F
F
A
B
Sure,
if
you
go
and
leave
you
go
up
slightly
in
the
spec
I
think
it's
just
above
that,
yes,
a
payment
ID.
So
the
the
previous
sentence
to
that
section
is
basically
saying
without
an
example.
Unfortunately,
but
it
does
say
in
all
cases
a
payment
identify
must
be
solvable.
So
this
is
basically
exactly
what
you
just
said
there
and
a
payment
ID
is
given
to
the
booking
system
based
on
whatever
happened
in
in
stripe
or
wherever
is,
and
that
must
be
neatly
resolved
or
for
other
purposes.
B
So
without
this
section,
so
I
think
what
might
be
best
to
do,
because
this
requirement
is
really
I.
Think
it's
more
active,
specific
thing
we
and
and
I
understand
fusion
have
a
similar
thing.
So
we
probably
just
need
to
talk
to
those
guys
and
figure
out
whether,
as
you
say,
Jamie
that's
sufficient
and
we
don't
need
this
section
or
if
we
do
need
this
section,
maybe
we
need
to
drill
in
a
little
bit
closer
to
what
exactly
it
looks
like
and
how
that
works
with
the
Gladstone
system.
A
B
B
Absolutely
two
phase
commit
so
yes,
if
we
go
to
so
that
we
had
a
bit
of
a
debate
and
again
it's
a
shame
that
I
did
I
did
see
if
we
could
get
Pete
into
this
call,
because
I
know
that
him
that
raised
initially.
Obviously,
it's
gonna
be
difficult
to
debate
this
if
you've
not
hit
the
vendor
point,
but
will
and
will
never
never
try
it
as
we
do
so.
B
C
B
B
Specifically,
the
two
approaches
we
have
here
are
the
what's:
what's
in
front
of
us
and
there's
a
github
issue
all
about
this,
but
I'll
summarize
it
so
in
front
of
us
here
is
a
toothpaste,
MIT
approach,
which
basically
means
I,
want
a
council
of
thing,
I,
put
forward
a
cancellation
request
and
say:
I
would
like
to
cancel
this,
and
it
will
come
back
and
respond
with.
Yes,
you
can,
and
this
is
how
much
money
you'll
expect
back
when
you
complete
that
request,
which
allows
for
we've
I've
talked
about
syndrome.
B
School
I
think
chirp
said
something
about
what
happens
if
we
have
a
deal
where
you've
got
three
for
the
price
of
two.
How
does
that
all
work,
and
so
one
of
the
advantages
at
the
approach
where
you
say
I
want
to
do
this
cancellation
request
and
it's
it
gives
you
an
idea
when
you
do
that.
What's
possible,
is
that
you
can
present
that's
the
user
and
you
can
give
them
a
definitive
answer
as
to
what
the
old
expect
and
then
they
commit
the
actual
cancellation.
B
Then
they,
then
they
go
forward
forward
with
it
and
and
they
know
exactly
what
to
expect.
That's
the
one
side.
The
argument
and
the
other
side
of
the
argument
is
that
we
don't
need
two
phases.
We
can
get
away
with
one
phase
and
we
can
make
a
set
of
assumptions.
Oh
sorry,
assertions
about
what
happens
in
a
cancellation
that
mean
that
we
don't
need
to
check,
because
we
can
basically
based
on
what
we
can
see
in
certain
other
properties.
B
B
B
B
So
these
three
options
just
in
clubs
park
system,
so
cancel
that
refund,
cancel,
require
refund
and
cancel
attempt
refund,
and
basically
the
idea
here
is
that
when
you,
you
have
a
flag
that
says
I'm
going
to
do
this
I'm
going
to
cert
that's
kind
of
refund,
and
then
it
will
succeed
or
fail
on
that
basis.
So
you
would
assert
I'm
gonna
cancel
without
a
refund
and
if
that's
allowed,
then
succeed
or
fail
or
you
assert,
I
want
to
cancel
requiring
a
refund
and
then
it
will
succeed
or
fail.
B
If
you
can't
get
a
refill,
it
will
fail
or
you
can
cancel
our
temporary
fund
and
basically
it
will
succeed
whether
a
refund
is
possible
or
not.
In
that
case
and
and
what
this
means
is
you
don't
need
two
phases
because
you're
effectively
advertising?
Well,
you
don't
even
need
to
advertise
it.
You
can
just
you
can
just
make
the
call
with
one
of
those
options
and
then
it
will
happen
or
it
won't.
B
So
this
is
not
sorted
into
phases,
which
is
quite
simplifies
it,
but
it
does
mean
that
the
behavior
is
slightly
different,
because
you
don't
get
you
you're,
not
in
a
situation
where
you
can
advertise
to
the
user
a
cancel
button
and
when
they
click
it
tell
them
what
options
are
available.
You've
got
to
just
basically
decide
what
you
want
to
do
and
then
it
will
either
work
or
it
won't.
So
it's
the
other
way
around
I
explained,
maybe
haven't
explained
it
very
well.
B
So
so
the
two,
the
two
options
are
that
again
two
options
are:
when
you
press
cancel,
you
can
get
something
that
comes
back
for
the
booking
system.
To
say
this
is
what's
possible,
so
ie
you
can
get
refunded
click
here
to
continue
or
you
won't
get
a
refund
click
here
to
continue
whatever
it
is.
That's
option
one
option:
two:
is
you?
Can
you
don't
you
don't
have
that
first
step
you
just
the
booking.
B
The
broker
makes
a
decision
about
what
it
wants
to
ask
for
you
say
you
press
the
cancel
button
and
then
it
will
come
back
saying
sorry,
you
can't
cancel,
there's
no
refund
possible,
so
it
doesn't
it
just
doesn't
make
you
do
it
at
all
or
you
press
it
and
it
says
yes,
you've
got
a
refund.
You've
got
a
full
refund.
B
B
Well,
whether
a
first
call
a
first
stages,
call
of
some
sort.
That
indicates
the
result.
However,
it
is
toupees
or
whatever
some
notion
of
a
way
that
you
can
query
the
booking
system
to
see
what
will
happen
if
you
press
the
button
is
the
first
option.
The
second
option
is
you
don't
need
to
query
the
booking
system,
because
you
don't
care
as
long
as
you
can
press
the
button.
That
will
be
enough.
F
B
So
probably
could
have
straighten
this.
So
if
you've
got
a
if
you've
got
the
the
first
option,
you
imagine
you
press
the
cancel
button
and
it
comes
back
and
says
it's
a
pipe
I'm
booking
you'll,
you
you.
If
you
press,
cancel
you'll,
get
a
full
refund
and
your
booking
will
be
canceled.
You
press
confirm
that's
step,
one.
That's
the
approach!
Number
one
approach.
Number
two.
Is
you
have
a
counsel
button,
you
press
it
and
it
says.
B
It'll
say
a
little
thing:
pops
up
and
says
by
pressing
cancel
cancellation
is
only
possible
if
you
get
a
full
refund.
Do
you
want
to
continue
and
you
press
yes
and
then
it
does
it,
and
it
then
says
sorry:
we
couldn't
complete
because
you
weren't
able
to
get
a
full
refund
or
you
say
wooden
pops
up.
Saying
cancellation
will
complete
whether
or
not
you
get
a
refund.
Do
you
want
to
continue?
And
you
say
yes
and
it
goes
ahead
and
you
might
find
out,
you
didn't
get
a
refund
when
finishes
that's.
A
F
C
Well,
I
think
option.
One
that
you
described
is
probably
more
sensible
because,
because
the
the
booking
system,
a
legend,
will
have
to
decide
whether
you
are
allowed
a
refund
or
not,
or
whether
you
can
even
cancel
in
the
first
place.
So
all
the
rules
are
then
exist
in
the
legend
and
we
just
returned
couple
of
flags
and
the
line
integral
just
displace
the
those
flags
on
to
the
user
and
some
tax
passage
to
the
user.
So
it
just
hides
all
the
complexity
from
the
integrator
and
all
the
business
logic
exists
in
legend.
C
B
Okay,
that
makes
sense,
and
so
and
just
so
I
check,
I
understand
how
that
will
work
all
the
way
through.
So
if
you
have
a
two
items
in
an
order,
one
is
one
that's
possible
to
refund
and
when
it's,
it's
not
possible,
I
suppose
that
you
would
then
error.
If
you
try
to
refund
something
that
wasn't
possible
to
refund,
you
would
error.
The
whole
cancellation-
and
you
have
to
try
again-
is
that.
C
That's
an
issue
over
here
about
either
allowing
user
to
cancel
the
whole
order
or
just
individual
bookings,
because
normally
what
we
do
is
that
we
don't
have
a
concept
of
order.
Imogen
I
mean
they.
It
existed
the
database
level,
but
not
on
the
truth
to
the
and
user
level.
So
users
made
three
bookings
and
he
comes
and
say,
cancel
booking
number
two.
So
we
just
so.
We
work
on
the
booking
order.
Item
level
after
the
booking
has
been
made,
so
so
that
is
the
thing
how
we
gonna
present
it
to
the
user
in
this
workflow.
C
It's
probably
better.
Do
it
an
order
item
level?
So
user
is
looking
at
all
of
his
booking
coming
up.
He
picks
one
of
it,
regardless
of
which
order
it
was
in
and
then
say
it's
cancel
it
and,
let's
imagine
given
the
booking
ID
to
the
legend
and
legend,
it
tells
you
whether
it's
you
can
refund
of
note
or
cancer
or
not
so
so
at
during
cancellation,
I,
don't
know
whether
order
ID
is
irrelevant
other
than
just
as
a
flag.
B
C
Implementation
point
of
view:
the
simple
thing
is
for
us
to
just
work
on
item
level,
doing
cancellation,
because
with
order,
if,
depending
upon
what
kind
of
items
are
in
the
order,
a
class
working
or
course
booking
or
sports
course,
things
can
get
quite
complex
at
the
order
level.
So
at
item
level
from
implementation
point
of
view
is
very
easy
for
us,
but
again
it's
about
about
the
user
requirements.
So
what
are
the?
What
is
the
scope
of
this
whole
thing
over
here?
Yeah.
B
C
That
you
just
have
a
function
which
is
just
cancel
the
whole
order.
In
that
instance,
everything
is
fine,
yukio
cancelling
the
whole
order,
and
you
are
just
returning
all
the
money
back,
but
if
you
tell
a
user
I
want
to
cancel
the
whole
book
order
and
I
mean
there
are
five
bookings.
Oh,
he
can
only
cancel
five
four
of
them,
not
the
last
one.
So
this
is
where
things
get
complex
and
then
all
the
metadata
about
how
to
return
the
list
of
flags
and
everything
they
become
very
complex.
C
B
I
mean
we
just
we
just
need
to
be
able
to
undo
whatever
we
did
before.
I
think
is.
That
is
really
what
this
is
about.
Just
so
that
cancellation
is
possible.
We
had
an
item
level
and
the
reason
that
they,
the
discussion
that
happened
before,
was
that
that
would
be
more
complicated,
because
if
it
was
item
level,
you
would
need
to
make
multiple
calls
to
cancel
multiple
items
and
it
was
decided
to
actually
having
one
call
when
you
include
all
the
IDS
in
it
was
easier
because
you
could.
B
There
therefore
make
one
I
think
they
think
the
question
was
if
you
have
booked,
if
you
have
booked
to
go
to
a
yoga
class
and
you
have
booked
a
crash
for
your
child
and
you
request
a
cancellation
on
the
yoga
class
and
that
succeeds,
and
then
you
request
a
crash
cancellation
and
that
fails.
That
might
have
changed
your
that
might
change
what
you
would
have
done.
B
C
B
Okay,
yeah
no
make
sense.
Okay,
so
slightly
did
that's
actually
a
slightly
different
question.
Isn't
it,
but
it
sounds
like
whether,
with
the
gets
because
effectively
you're
doing
a
get
for
a
particular
pair
of
things,
you
want
to
cancel
your
they're
not
doing
it's
not
order
based
anymore,
like
you
say,
for
the
business.
For
this
to
be
complete,
the
business
logic
should
be
entirely
in
legend.
B
So
maybe,
if
we
take
that
as
a
requirement
here
and
then
we
can
go
and
think
about
how
we
we
do
that,
so
we
want
the
business
objects
being
legend
as
as
much
as
possible.
We
want
a
loose
association
between
items
and
orders
so
that
you
don't
necessarily
have
to
store
all
that
state
if
you
don't
need
to,
and
we
want
it
to
be
atomic
from
the
previous
conversation
so
that
a
parent
and
their
child
with
two
different
events
will
succeed
and
fail
in
translation
together.
What.
A
C
C
Yeah
it's
around
that
thing
yeah,
so
working
for
me
on
an
individual
item
is
quite
easy,
rather
than
the
whole
order,
and
then
it's
once
user
as
let's
say,
canceled
some
last
half
of
the
bookings
on
the
order
running
again.
Next,
it
comes
in,
say,
I
want
to
cancel
further,
so
you
have
to
calculate
all
the
rules
all
the
time.
B
Right
of
course,
yes,
so
I
think
yeah
and
so
to
say
that
I'm
sorry
for
my,
it
sounds
like
it's
all
dynamic.
So,
if
you're
doing
a
get
request
on
an
order,
you're
doing
a
ton
of
dynamic
calculations
that
depend
on
the
date,
the
time
like
how
many
things
are
in
the
event,
what
other
rules
are
applied.
So
it's
not
a
trivial
task
to
do.
Sounds.
E
B
Okay,
so
that's
really
helpful
it.
It
basically
sounds
like
we're
saying
that
some
some
type
of
thing
where
I
didn't
call
it
two-phase,
but
you
can
basically
make
the
minimum
number
of
calls
using
what
we
just
discussed
to
get
the
Business
Objects
response.
It's
basically
I
want
to
ask
the
business
object.
That's
imagined
a
question
get
the
answer
and
then,
based
on
the
answer,
allow
these
to
perform
an
action.
It
seems
to
be
where
we
are
so
I
guess.
We
just
need
to
look
at
the
best
form
of
that
okay.
B
So
we've
hit
time,
unfortunately,
and
in
terms
of
coverings
the
last
issue
around
approvals.
We
haven't
got
time
to
do
that
today,
but
that's
quite
handy
because
also
the
two
people
that
we're
really
pushing
for
it
haven't
you
have
to
make
it
so
I
would
save
me
trying
to
do
that
on
their
behalf,
but
I
will
so.
The
next
thing
to
that's
going
on
is
there's
a
there's.
A
workshop
on
the
2nd
of
April
I
know.
B
Some
of
you
guys
are
coming
to
that
and
we're
gonna
be
going
through
this
sort
of
very
high-level
make
sure
everybody
is
on
board,
with
kind
of
the
scope,
the
goals,
the
vision,
all
that
stuff
business
rationale
and
some
of
the
trade-offs
we've
made
in
terms
of
you
know,
including
cancellation.
We
won't
be
going
into
the
details
of
whether
it's
one
or
two
phase
commit
so
anything
like
that.
B
It
will
be
more
that
cancellation
is
in
there
and
it
lets
you
do
that,
that's
just
to
make
sure
everyone's
bought
in
and
if,
if
that's,
hopefully,
everyone
says
yeah,
that's
what
we
need.
Maybe
a
couple
other
things
get
surfaced
and
the
idea
is,
then
that
we
have
another
call
on
the
10th
of
April
and
optimistically,
because
we,
this
is
a
optimistic
plan.
B
We
would
be
able
to
finalize
the
last
of
these
issues,
so
we'll
do
an
iteration
of
what
we
discussed
around
the
cancellations
for
them
as
well
and
combine
those
things
so
on
the
10th
of
April.
We
should
hopefully
be
in
a
position
where
we've
taken
the
feedback
from
the
workshop.
There
might
be
a
high
level
and
if
there's
anything
most
of
the
changes,
we
might
need
to
revisit
all
of
this
plan.
But
if
everyone's
okay,
with
the
high
level
with
what's
included,
then
we
can
take
those
changes
on
the
10th
of
April.
We
can.
B
We
can
look
at
them
and
hopefully
be
in
a
position
where
we've
got
something
pretty
close
to
a
releasable
thing
and
I
mean
I
guess.
The
point
to
note
here
is
that
people
have
come
and
gone
from
these
calls
for,
and
the
people
are
watching
this
in
the
catch-up
afterwards.
We'll
know
as
well.
We've
been
doing
this
for
over
a
year
now
and
I
guess
at
some
point.
B
A
Yeah,
so
in
terms
of
process
over
the
next
few
weeks,
so
we'll
obviously
try
and
service
any
general
concerns
or
gather
feedback
at
the
workshop
I
think
for
those
of
you
that
are
planning
to
run
through
this
back
again
or
for
the
first
time
getting
any
feedback
on
anything
that
you
have
concerns
about
would
be
good,
so
you
know
seeing
issues
as
they
occur
rather
than
kind
of
waiting.
A
few
weeks
until
you
don't
have
complete
one
through
would
be
helpful.
So
go
ahead
file
stuff
in
in
github
we
have.
A
A
We
need
to
get
to
a
point
where
we're
confident
that
either
we've
addressed
these
sufficiently
for
what
we
know
or
where
we
need.
We
know
we
need
to
do
more
work.
You
know
to
get
get
it
over
the
line,
so
people's
attention
to
to
the
issues.
If
we're
asking
you
for
feedback
or
if
we
email
those
10
emails
to
the
mailing
list,
you
know
asking
for
a
feedback
if
you
can
try
and
keep
up
to
date
so
that
we
can
trigger
this
over
line.
A
That
would
be
appreciated,
sometimes
that
you
can
even
just
be
doing
a
thumbs
up
on
a
comment
on
github
to
say,
you're
happy
with
what
we're
proposing
it
doesn't
have
to
be
a
long
of
feedback.
Just
saying
yes,
I'm
comfortable
with
this,
as
a
decision
will
help
us
kind
of
trade
off,
sometimes
well,
sometimes
slightly
competing
new
points
just
so
that
we
can
get
somewhere
that
people
are
comfortable
with.