►
From YouTube: OpenActive W3C Community Group Meeting / 2019-02-13
Description
A public hangout for members of the OpenActive W3C Community Group.
https://w3c.openactive.io/meetings/2019-02-13-booking-feedback
A
B
A
Follow
ups
with
the
community
so
we'll
give
an
update
on
that
and
Nick
and
runs
through
the
changes
and
any
issues
and
then
we'll
go
if
time
permitting
we'll
touch
on
some
just
kind
of
mix
around
implementation
and
next
steps
we'll
see
how
far
we
get
through
and
then
time
for
any
any
of
the
business
area
wants
to
raise
at
the
end
so
straight
into
it,
Nick
published
and
the
latest
update
of
the
spec
afternoon.
So
none
of
you
lived
on
Chester,
see
here
so
Nick.
C
C
C
And
I
must
say
that
there's
this
outside
of
this
conversation,
because
we
found
it
quite
difficult
to
get
everyone
on
this
call
for
this
particular
bit
of
this
spec.
Sometimes
we
call
this
round,
so
there's
been
a
few
people
feeding
in
in
between
thanks
Ian
for
your
contributions
and
also
Joe
from
book
when
and
array
from
clarity
were
two
major
contributors
to
their
thinking
and
other
people
have
been
chipping
in
bits
and
bobs
as
well.
C
So
what
I'm
hopeful
hopeful
we'll
have
at
the
end
of
this
is
something
that,
at
a
high
level,
we
all
agree
is
kind
of
at
a
good
MVP
as
a
booking
spec,
and
then
we
can
make
sure
that
we
can
circulate
that
and
get
the
detail.
Anyone
else
have
feedback
on
on
detail,
but
I
think.
Hopefully
this
satisfies,
why
understand
as
being
the
main
requirements
so
to
jump
into
it?
Maybe
Lee.
Actually,
if
you
jump
to
that
slide,
that
I
had
first,
that
might
be
just
for
Rogers
benefit
about
a
place,
yeah
perfect.
C
D
C
C
So
they
can
trigger
that
and
then
the
refund
can
be
processed
as
a
result
of
that
happening,
and
then
the
customer
cancellation,
which
is
a
quite
a
similar
process,
both
of
those
trigger
refunds
and
then
finally,
there's
this
optional
kind
of
leasing
bit,
which
means,
while
I'm
well
as
something
in
my
shopping
basket,
making
sure
that
people
can't
steal
it
from
me.
So
other
people
who
might
be
booking
on
the
site
at
the
same
time
can
take
the
last
space
in
a
in
a
yoga
class,
for
example.
C
C
Excellent,
that's
that's
really
great!
So
if
we
jump
straight
into
this
into
what
I'll
start
with
is
just
the
changes
that
we've
made
as
a
result
of
the
conversation
to
the
booking
journey
that
others
on
the
call
will
be
familiar
with
so
5.2
jump
to
there.
This
is
the
the
kind
of
main
looking
journey
which
includes
checkpoint
one
two
and
then
book.
The
idea
here
is
that
you
go
through
a
process
of
checking
your
basket.
C
Getting
the
total
amount,
including
tax,
that
that
basket
is
worth
and
then,
when
you
call
that
a
quote
and
when
you
want
to
then
complete
that
transaction
you
take
that
whole
all
the
items
in
that
quote,
and
you
put
them
through
as
an
order,
and
that
gives
you
the
booking,
and
the
idea
is
that
when
you
get
your
quote,
that's
enough
information.
You
can
use
to
take
payment
and
authorize
that
and
then,
when
you've
completed
the
booking,
you
can
capture
that
payment.
C
That's
two
step
process
change
we've
made
is,
if
you
go
down
to
the
next
diagram
in
this
series
of
diagrams.
Is
we've
added
this
little
bit
at
the
bottom
here,
which
basically
says
at
the
very
end
when
you've
completed
capture
the
payment?
We
then
there's
that
it
posts
the
order
that
was
generated
to
the
our
PDE
feed,
with
a
status
of
autocomplete
for
the
order
items,
and
so
that's
the
that's
the
first
main
thing
and
that
allows
the
broker
to
generate
invoices
and
notify
customers.
C
Accordingly,
all
those
things
about
v80
recedes
we
previously
talked
about
so
it's
kind
of
the
key
thing.
There
is
stressing
that
the
brokers
responsible
for
those
two,
those
two
things
and
that
they
will
only
do
it
as
a
response
to
the
our
PDE
feed.
They
won't
do
it
using
information
that
comes
back
from
the
order.
C
Good
question:
so
it's
slightly
more
detailed
but
but
to
answer
it
that
the
one
of
the
other
assumptions
this
effect
currently
makes
is
that
the
in
order
to
basically
simplify
this
as
much
as
possible
for
the
implementer,
it
might
not
always
be
the
case.
The
implementers
got
the
concept
of
an
order
at
all.
They
might
just
have
order
items,
and
so
it's
permissible
that
the
order
when
it's
returned
from
the
post
it
doesn't
have
to
be
the
way
it
could
be
either
way.
C
But
there's
there's
no
strict
requirement
that
the
order
that
gets
returned
from
the
post
of
the
of
be
is
the
same
as
the
order
that
comes
out
of
the
our
PDE
feed
and
what
I
mean
by
that
is.
Although
the
items
themselves
must
be
the
same,
the
item,
the
order
can
be
broken
up
into
it.
The
items
can
be
broken
up
into
a
number
of
orders.
C
So
if
you
post
an
order
for
five
things
that
could
come
out
in
the
our
PDE
feed
as
five
orders
or
one
order,
and
but
it
actually
doesn't
matter
because
the
our
PDE
feed
is
what's
being
used
as
the
kind
of
point
of
truth,
and
so
the
order
really
be
represents
the
transaction.
This
is
the.
This
is
the
thing
that's
completed,
atomically
it's
done,
and
when
that's
completed
that
the
ID
there
isn't
an
ID
of
that
order,
so
it
doesn't
persist
as
it
is
in
that
state.
E
Nick
height
yeah,
okay,
smiling,
so
you
can
hear
me
yes.
Well,
maybe
you
smile.
You
know.
I
got
a
couple
questions
about
that.
What
is
vaguely
technical,
which
is
that,
if
I
submit
an
order
with
three
items
on
it,
I
get
back
three
orders
with
one
item
in
each:
what's
the
keying
for
that
you've
obviously
got
the
gooood
which
qualifies
the
meta
order,
but
how
do
you
actually
specify
and
identify
the
the
suborders
and
how
they'll
relate
to
the
main
order
within
that?
Yes,.
C
C
So
as
soon
as
that's
completed
that
good,
it
could
persist,
there's
nothing
to
stop
it
persisting,
but
it's
not
a
requirement
that
it
does
persist.
So,
for
example,
if
if
the
simple
implementation
you
wanted
to
use
that
gooood
not
do
leasing,
you
would
effectively
ignore
the
good
completely
and
then,
when
you
come
to
process
the
order,
you
might
generate
several
order,
orders
one
for
each
order
item
and
at
that
point
the
IDS
would
be
present
in
the
in
the
feed.
So
the
RPD
feed
produces
the
IDS
sure.
E
You
need
to
have
you
know
the
broker
is
creating
an
order
and
then
goes
off
into
limbo,
and
then
something
comes
back.
It
must
be
able
to
link
back
to
the
order
they
created
that
they
that
they
registered
with
the
provide
the
booking
system
in
these
fragments
come
back.
Otherwise,
you
know
how
they
gonna
correlate
it,
and
if
they
want
to
be
able
to
say
to
the
customer,
here's
your
tax
invoice,
they.
A
E
A
Otherwise,
there's
a
chance
that
you
get
even
the
c1c2
can
happen
at
different.
You
know
repeatedly,
there's
just
potential
if
that
things
get
recycled
accidentally,
so
I
think
they
have
to
be
persisted
and
my
I
mean
I
could
maybe
this
is
more
detail.
You
want
to
go
just
now,
so
I
can
defer
commerce
to
base
it,
but
it
feels
like
what
you've
ended
up
doing
is
is
exposing
some
of
the
details
of
the
implementation
that
people
might
have
orders
differently
to
every
broker.
In
this
case,
where
you
could
easily
have
just
said,
if
bookends
mr.
B
A
C
I
see
okay,
so
the
reason
for
that
is
that
the
way
the
our
PDP,
if
you
were
gonna,
if
you're
gonna,
to
generate
the
our
pd
feed
off
of
the
just
booking
table
just
a
normal
booking
table
with
yes
without
having
any
kind
of
grouping.
So
it's
difficult
to
generate
an
RPD
table
with
grouping
because
of
the
way
that
the
the
way
you
need
to
store
the
state,
and
so
that
basically
means
that
you
can
you
can
separate
them,
you
can.
A
A
C
A
C
Can
take
that
yeah?
Okay,
great
okay!
Thank
you!
Yes!
Well!
That
was
that
was
what
I
thought
might
be
the
most
controversial
and
the
things
so
I'm
glad
that
you
guys
both
picked
up
on
that
immediately,
because
that
was
it's
difficult,
because
it's
a
kind
of
trade-off
between
making
it
slightly
more
complicated
to
implement
but
more
consistent
and
I.
Guess,
that's
that's!
The
trade-off
we
need
to
decide
on
is
what
level
of
complexity
want
to
pause
on
the.
E
There
doesn't
seem
to
be
useful,
so
you
know
you've
got
the
the
broker,
well
broken
nose
of
the
broker,
so
you
don't
need
a
dress.
Similarly,
the
seller.
You
know
the
the
there's
going
to
be
one
to
one
relationship
with
the
seller
and
the
broker
yeah.
So
you
don't
need
to
pass
the
information
about
who
they
are
backwards
and
forwards
in
full
detail,
with
every
order
just
that
food
for
thought,
I
mean
that's
just
in
passing.
Yeah.
C
Yeah,
okay,
excellent
on
the
cancellation
charge.
There
are
some
issues
with
adding
cancellation
charges.
If
we
allow
arbitrary
separation
of
order
items
or
if
authorized,
if
orders
can
be
generated
arbitrarily,
as
we
just
discussed,
then
cancellation
charges
become
slightly
more
difficult
to
do
consistently.
So
I
was
going
to
actually
suggest
that
we
remove
cancellation
charges
from
scope,
but
I
don't
know
again.
If
that's
something
that
is,
is
that
a
must-have
from
legends
could.
E
C
E
C
E
E
C
C
C
C
You
have
to
generate
an
actual
date
for
each
of
those
which
isn't
actually
that
useful
to
do
so.
I
was
going
to
suggest
that
we
deviate
from
the
schema
there
and
just
use
the
relative
time,
which
Google
Reserve
also
instantly
does,
instead
of
using
the
actual
dates
which
saves
us
some
dating
stuff
like
that
in
the
are
PDF
or
you
does.
You
say,
okay,.
A
No
just
yeah,
okay
I
was
actually
gonna,
just
jump
us
back
one
stage,
so
some
of
the
some
of
the
changed
design
here
ozone
standard.
What
you
described
is
because
of
potential
implementation
issues
that
for
systems
that
are
unable
to
generate
a
single
order
to
reflect
what
is
actually
coming
through
the
API.
So
the
original
API
design
was,
you
generate
an
order
with
order
items,
and
that
was
what
yeah
that's.
What
persisted
that
we
were
you
get
notified
on,
so
it
seems
like
in
between,
in
the
last
couple
weeks,
you've
identified
some
issues
with
that.
C
The
idea
to
simplify
that
order
was
thinking
about
the
exact
instructions
we'd
have
to
give
to
England
netball
to
Ooty
touch
rugby
and
to
those
other
simple
systems
and
what
they'd
need
to
implement
and
knowing
their
systems.
That
was
me
knowing
their
systems.
That
was
additional
instruction.
We'd
have
to
provide
to
them
in
terms
of
how
to
generate
an
order
table
and
all
that
extra
work.
So
that
was
where
that
came
from
it.
Wasn't
anyone
specifically
saying
this
is
too
complicated
and
it
was
getting
ahead
of
that
advice.
E
E
A
Oh
I
got
slightly
differently,
but
we've
we've
been
veering
between
single
item
orders
and
multiple
item
orders
over
the
last
three
or
four
iterations
of
the
spec.
The
original
scope
with
a
single
item
orders.
So
if
there
is
some
implementation
complexity
in
the
for
the
purpose
of
actually
getting
this
first
version
done
saying,
we
only
do
single
item
orders
and
just
leaving
it
there
for
now.
I'm
dealing
with
any
other
complexity
later.
Whether
that
is
just
on
the
implementation
side
or
change
to
the
design
would
be
another
way
to
resolve
that.
C
Yeah
I
mean
that
so
the
reason
that
I'm
thinking
about
the
multi
item
order
is
one
of
the
use
cases
is
around
people
booking
with
their
friends.
That's
that
was
the
main,
the
main
thing
and
the
more
so.
Every
time
we
talk
about
multi
item
orders.
It
causes
us
to
have
a
crisis
of
design
in
some
way
or
another,
which
is,
we
have
been
helpful
so
far,
I
think
it's
removed
a
lot
of
complexity
actually,
because
we've
ended
up
which
will
come
on
to
talk
about
removing
invoicing
completely.
On
the
basis
of
that
complexity,
you.
A
Know,
I
just
want
to
make
sure
that
we're
making
the
right
trade-off
that,
like,
obviously,
if
some
systems
aren't
able
to
have
multiple
order
items
in
a
single
order,
do
we
want
that?
We
want
that
to
be
something
that
has
to
be
surfaced
across
the
whole
API
design
and
everybody
who's
implementing
it.
I
was.
C
Gonna
say
about
ot
touch,
and
others
is
that,
although
I
do
see
what
they're
saying
about
them,
accepting
one
order
at
once,
but
there's
other
examples
such
as
British
Cycling
that
do
allow
you
to
well
actually,
even
even
though
to
touch
allows
you
to
at
once
and
the
difference
isn't
about
whether
you
can
do
two
orders
at
once.
The
difference
is
just
about.
As
you
say,
it
is
an
implementation
about
what
they
need
to
store,
and
so
it's
mainly
that
the
advantage
of
home
multiple
items
in
an
order
is
it's
atomic.
C
So
you
can
only
succeed
or
fail
that
whole
order,
which
means,
if
you're
booking,
with
your
mate,
you
can't
get
the
situation
where
one
person
gets
in
and
the
other
doesn't
and
you
have
to
do
a
cancellation
you're
either
gonna
you
animate
in
or
you're,
not,
and
so
in
the
case
of
British
Cycling,
for
example,
where
you
do
have
rider,
plus
one
or
rider
plus
five.
Many
you
can
you
can
book
that
as
one
atomic
thing,
but
then
it
might
split
those
out
into
separate
waters
in
the
feed
just
to
simplify
the
the
feed
implementation.
C
C
C
I
mean
I've
covered
this
at
this
point
and
then
yeah.
We
should
definitely
cover
the
bits,
but
one
of
the
other
changes
we've
talked
about.
So
the
end
suggestion
actually,
which
was
a
really
good
one,
which
is
we
should
get
do
away
with
the
order,
quantity
and
so
not
allow
you
to
book
three
tickets,
but
actually
force
you
to
create
three
order.
C
Items
and
the
reason
that's
actually
better
and
simpler
is
that
when
you
cancel
an
individual
order,
item
you're
canceling
them
individually
as
well,
and
so
you
don't
have
a
situation
where
you
say
you
know
to
cancel
and
one
is
complete
and
so
by
getting
rid
of
all
the
quantity
that
has
a
layer
of
simplicity.
But
also
do
you
say
that
you
know.
C
B
C
Part
of
that,
because
there's
a
legal
requirement
with
invoices
where,
when
you've
generated
an
invoice,
it
must
stay
the
same,
we
have
to
version
them.
Basically,
every
time
you
generate
a
new
version
of
the
invoice
every
time,
there's
a
cancellation
or
a
change
to
the
order
you
have
to
generate.
You
have
to
maintain
a
new
version
of
that
invoice,
so
people
have
that
history
and
invoices
connected
to
a
payment
and
the
payment
has
multiple
refunds,
but
all
of
that
complexity.
C
Actually,
although
this
recommendations
in
here
to
keep
it
simple
around
in
Villisca
payment
and
refunds
and
the
links
between
them,
so
order
has
a
series
of
invoices
or
all
versions
at
the
same
thing,
one
payment.
So
it's
one
payment
per
order
and
then
the
payment
can
have
multiple
refunds
associated
with
it.
So
if
you
have
three
order
items
in
the
order,
then
one
payment
covers
those
three
and
you
can
have
three
refunds
as
you
refund
one
of
them,
each
one
one
at
a
time.
C
D
A
A
The
book
is
going
to
notify
the
customer
I
guess
they
could
do
it
a
couple
of
stages,
because
and
partly
depending
on
with
the
UX
the
broker
system
right
it.
You
might
just
want
a
simple
notification.
Yeah
your
orders
complete
whether
you
want
to
hire
formally,
you
want
to
notify
them,
will
present
them
with
the
invoice
objects.
The
invoice,
but.
C
Yes,
absolutely
so
that's
what
that's
what
this
that's,
what
is
covered
in
the
other
diagrams,
whether
we
put
in
here
as
well,
but
that's
right
so
currently
every
time
has
it
changed
the
order.
It's
basically
notified
every
time
an
invoice
is
generated
so
more
specifically
so
I
guess
maybe
yeah.
That's
probably
good
cue
to
carry
on
going
through
could.
E
I
just
make
a
point:
you
talked
about
the
invoices
being
one
to
one
with
orders
and,
whilst
I
agree
that
that's
the
give
me
the
cases
b2c,
it
wouldn't
Esther
with
the
case
and
b2b.
So
if
you're
ordering
a
whole
chunk
of
courses
or
block
bookings
or
sports
courses
with
an
automatic
process
as
a
business,
you
wouldn't
necessarily
expect
to
get
a
notification
back
with
a
formal
dat
invoice
for
all
of
them,
but
rather
be
even
boys
once
a
month
for
it.
Yeah.
E
C
That
makes
sense.
So
there's
that's
so
that's
supposed
to
constraint.
We've
got
at
the
moment
where
there's
a
payment
per
order
might
not
be
no.
That's
right.
Actually
that
works.
So
a
single
payment
can
span
multiple
orders,
but
the
reverse
isn't
true:
a
order
can't
be
paid
by
on
multiple
payments.
That's
the
assumption.
That's
made
here!
So
it's
a
and
all
they
must
have
one
payment
payments
can
be
used.
C
E
E
Guess
that
it's
in
a
b2b
context,
you
might
raise
some
reporters
30,
40
or
bazolar
month,
and
then
you
actually
invoice
as
a
broker
to
the
customer
once
a
month,
yeah
now
there's
no
payment
against
the
order.
What
you're
doing
is
stating
that
the
payment
is
externally
some
way
or
the
payment
hasn't
happened
yet
or
something
of
that
kind.
And
the
other
thing
which
relates
to
that
is
of
course
there
may
be
no
payment
at
all,
because
it's
a
free
booking.
D
E
C
So
at
the
moment
this
doesn't
there's
no
there's
nothing
that
says
the
invoice.
The
order
doesn't
reference
anything
about
invoices
in
the
in
the
payload.
The
only
thing
your
references
payment
identifier,
and
so
because
the
order
has
a
payment
identifier,
just
one
it
must
have
a
payment
ID.
That
then,
is
used.
I
think
we
said
this
before
the
traceability.
So
if
there's
a
problem,
you
know
what's
what's
what's
connected,
but
then
that
could
be
that
same
payment
could
be
used
in
50
60
different
orders.
C
C
B
The
first
one
in
the
event
can
make
a
decision
whether
they
have
people
to
pay
fine
voice
or
my
card.
You
know
for
such
papers,
one
by
the
other
one,
given
the
choices,
the
options,
so
the
paper
I
pay
by
card
there
and
then
they've
got
to
get
a
receipt
payment.
If
they
choose
to
pay
invoice,
don't
forget
to
get
an
invoicing.
You
know
you
know.
Is
this
money
within
30
days
or
yeah?.
C
B
C
E
So
they
can
I
just
sorry.
You
apologize
for
this,
but
I
have
a
comment
on
seven
point:
six,
which
is
above
deal
with
it
now
I
really
wasn't
clear
what
that
was
about
and
what
we'd
enemies
were.
Maybe
we
shouldn't
do
that
now,
but
just
just
so
it's
a
placeholder
for
you,
so
I
don't
need
to
go
through
the
high-level
stuff,
but
okay.
C
Let's
come
back
to
that
to
announce
then
after
we'd
cover
the
other
yep,
that's
not
good!
So
that's
a
yes,
sir
cancellation.
Following
on
from
what
we
talked
about
just
now,
the
way
the
cancellation
would
then
work
is
that
if
you've
got
that
the
our
PDE
feed
of
items
again
TVC
what
the
makeup
of
those
is,
but
regardless
there
will
be
an
order
in
which
inside
the
order,
there
will
be
one
or
many
items,
and
so
the
way
this
works
is.
C
B
C
E
I
think
you
need
to
have
the
constellation
rule
within
that
feed.
You
either
got
added
to
the
cancellation
rule
from
the
RFP.
Did
the
order
or
the
creation
point,
or
any
amendments
needs
to
be
in
there
cuz
it's
quite
possible
the
cancellation
rules
change.
So
in
fact
we're
saying
you
can
cancel
up
to
allowing
of
balance,
but
then
people
get
in
there
like
that.
So
you
make
it
two
hours
in
advance
or
something
like
that.
So
I
don't
know
how
we
do
that
model,
that,
in
terms
of
the
feed
and
by
suggestion,
would.
E
E
C
How
good
yeah
so
I've
pitted
it
now
I'll
just
open
up
odds,
but
it
is
Roger.
Sorry,
Roger
I
didn't
realize
that
I
just
pressed
me
before
wherever
I'll
continue
at
any
point
of
course.
So
so
that's
that
yeah
and
then
in
order
to
go
for
the
maximum
simplicity
here,
what
I'm
proposed
is
that
we
just
use
it
delete,
and
this
was
from
a
previous
version
that
we
basically
just
get
just
from
just
a
single
delete
against
the
order
item
ID.
So
it's
only
allowed
at
the
order
item
level,
not
the
order
level.
C
C
A
A
C
A
C
C
What
then
happens-
and
this
is
key-
because
it's
consistent
with
the
next
diagram,
so
the
order
comes
back,
comes
the
RPD
feed
with
custom
cancelled
and
if
you
just
go
to
the
next
diagram,
you'll
see
very
similar
except
it's
just
this
bit
is
said
to
seller
cancelled
and
so,
in
both
cases,
there's
a
desert
cancellation
triggered
and
in
the
case
where,
in
this
case
the
sellers
done
it.
So
that's
just
it's
just
done,
and
in
the
previous
case
it's
the
customer
looks
plummet
in
both
cases.
What
that
does?
C
Is
it
put
it
on
the
feed
and
there's?
The
idea
here
is
as
soon
as
that
cancellation
goes
on
the
B.
It's
then
the
brokers,
responsibility
to
process
that
refunds,
rain
or
shine,
and
as
far
as
the
booking
system
is
concerned,
that's
the
done
deal
they've
thrown
the
feed.
That's
the
end
of
their
responsibility:
there's
no
feedback
loop.
C
That
then
changes
the
state
in
the
booking
system
from
refund
requested
to
refund,
confirmed
or
anything
like
that,
because
as
booking
system
doesn't
need
that
level
of
granularity
and
I'm
thinking
here
is
practically
if
the
refund
doesn't
succeed.
What
whose
problem
is
that
and
what's
the
action
that
would
then
be
taken?
And
basically,
if
the
gifts
and
things
cancelled,
the
reason
needs
to
happen.
C
If
the
refund
doesn't
have
the
Mac
systems
going
to
be
annoyed
already,
with
the
broker
and
not
receiving
their
refund,
because
you
know
that's
they've
been
told,
they're
gonna
get,
but
there's
no
there's
no
situation
where
you
would
say
to
a
customer.
You
know
you're,
you
know
the
venue
got
flooded,
so
we've
issued
a
refund
to
everybody,
but
because
your
card
didn't
work,
you
know
I
had
one
sorry
and
it
would.
It
wouldn't
be
the
case
that
you
know
just
because
you're
some
technical
failure
occurred,
you're
not
allowed
to
refund
the
refund.
C
A
Yeah
so
I
understand
that
we,
you
need
to
have
that
clear
responsibility,
but
one
of
the
reasons
for
having
to
phase
with
so
that
the
booking
system
can
also
be
clear
when
the
broker
has
processed
the
refund,
so
that
you
know,
following
the
principle
we've
got
elsewhere,
that
both
sides
of
the
system
always
have.
You
know
knowledge
of
where
things
are
at
I.
A
E
Think
you
know
I
think
Nick's
right
here,
that's
the
responsibility,
the
broker
yeah,
and
so
as
far
as
the
booking
system
concerned,
they
want
to
get
paid
and
that's
what
we
have
to
face
commit
if
some
of
these
counselors
through
some
of
the
requests
or
the
booking
system
request.
But
they
say:
okay,
it's
been
cancelled,
you
guys
would
be
counseled.
You
mister
broker
have
to
provide
refunds,
and
actually
it's
of
no
real
interest
in
the
booking
system.
Where
that
refund
is
done
or
not,
yeah
it's
in
their
accounts
and
that
will
go.
E
You
know
W
part
of
any
reconciliation
that
happens,
but
the
book
is
some
can't
do
anything
about
it,
whereas
in
the
case
of
a
booking,
if
the
payment
fails,
then
you
want
to
make
sure
it's
even
booked.
In
this
case
the
actual
operation,
the
booking
system,
sighs
already
done,
we've
already
cancelled
it
so
and
just
to
add
to
that,
the
refund
may
well
be
asynchronous.
They
may
well
put
in
the
batch
mode.
You
know
every
every
night
as
a
person
in
real-time
yeah,
yeah.
C
C
Think
part
of
the
change
here
is
now
that
the
record
I
think
it's
seven
at
one,
so
I
think
part
of
the
change
here
is
that
the
booking
system
actually
has
very
little
knowledge
about
the
payment
and
refunds.
An
invoice
situation
in
fact
invisibility
in
this
diagram
shows
they
have
no
visibility
of
the
payments
and
the
refunds
and
the
invoice.
All
the
booking
system
knows
is
that
it
has
been
paid
and
that
they
have
requested
a
refund
I.
A
C
I
see
well,
generally
speaking,
the
refunds
are
connected
to
the
payment,
so
in
the
Sopris
tribe,
for
example,
the
payment
is
15
pound
payment.
You
can
issue
refunds
against
that
payment,
so
the
moral
is
as
this
diagram
shows.
If
you
can
get
the
payment
you
can
get
to
the
refunds,
the
payment
is
worth
the
kind
of
total
amount.
Any
one
point.
C
A
I
know
they
they'll
have
to
do
that.
They
have
to
process
the
broker
has
to
process
the
the
refund,
but
again
I
was
I
would
have
expected
in
that
scenario
as
well.
The
booking
system
may
want
confidence
that
ever
you
know,
because
he's
been
flooded,
that
they
know
that
everybody
has
been
properly
fund
it.
So.
C
Suppose
this
might
be
where
it
comes
to
the
the
broker
needs
to,
and
maybe
I'll
start
something
to
the
for
the
broker
to
to
offer
or
or
something
that
okay.
Well,
let's
take
sounds
like
there's
a
slight
question
about
that.
Maybe
that's
something
we
can
ask
some
other
people
and
see
if
there's,
if
that's
something
which
didn't
that,
but
others
might
be.
So
it's
a
good
question.
A
E
C
I
started
out
with
it
was
started
as
a
patch.
It
became
a
delete
just
because
it
was
the
most
simple
thing,
but
yeah
I
can
see
that
okay,
so
just
to
kind
of
cover
off
the
last
couple
bits.
Then
so
that's
that's
mainly
the
those
diagrams
kind
of
cover
that
there
are
a
couple.
Other
things
I
wanted
to
point
out,
and
so
maybe
if
we
do
seven
point
six,
you
know
we've
only
got
six
months
left.
So
maybe
just
going
back
to
that
cuz
you
had
a
comment.
Oh
yeah.
E
Yes,
I
didn't
understand
it.
Yes,
who
was
providing
the
override
when
it's
going,
whether
the
broker
was
saying?
Oh,
you
said
it's
seven
pound
fifty,
but
it's
going
to
be
four
pounds
or
whether
it's
part
of
the
author
request
and
seven
pound.
Fifty
or
we
will
do
fees
were
four
pounds.
I
wasn't
sure
which
direction
he
was
in.
Oh
I,.
C
See
so
yes,
the
idea
with
this
is
this
is
this:
is
that
and
requirement
from
the
which
booking
workshops?
One
of
the
things
we're
we're
saying
that
the
the
value
of
price
variable
ization
in
this
is
is
a
strong
thing
that
all
the
innovators
want
to
have
freedom
to
to
do,
and
maybe
it
was
even
Steven
Wingfield.
That
said,
that
should
be.
These
kind
of
things
are
up
so
they're
the
commercials
to
decide
on
what
the
prices
are
at
the
end
of
the
day.
C
So
that's
that's
in
the
quote
and
then
subsequently
in
be
as
they
would
with
any
other
offer
that
would
be
accepted,
but
instead
of
taking
an
offer
ID,
which
is
one
that's
been
provided
in
the
feed,
they
just
simply
provide
an
offer
over
eyes,
which
is
a
price
and
the
currency
which
then
is
is
then
taken.
I
think
we
said
this
in
previous
discussions
that
Ray
was
in
as
well
as
long
as
that's.
It's
got
to
be
the
same
tax
type,
so
tax
gross
or
whatever
it
is.
It's
got
to
be
consistent.
C
E
Should
the
Brooke
should
the
provider?
Should
the
seller
not
be
able
to
say
no
I'm
not
doing
that
for
ten
pounds,
because
you
know
I
mean
that
this
whole
thing
about
what
the
commercial
relationship
is
still
in
its
infancy
and
I?
Don't
think
that
Steven
had
in
mind
that
this
is
a
squash
court
with
ten
pounds?
Oh,
yes,
you
can
sell
it
for
a
pound.
I
think
there'll
be
some
kind
of
range
which
is
acceptable
and
you
know
you've
got
not
only
I'm.
E
C
I
think
what
Stephens
appointment
that
was
I
can
kind
of
see
where
he's
gone
from
it.
It's
almost
that
that's
that
that's
a
problem
for
the
commercial
side,
in
that
you
know
when
they
do
the
reconciliation,
when
they
could
obviously
they'll
they'll,
be
reporting
on
this.
What
how
much
income
there
is
and
how
much
is
all
that
kind
of
stuff
when
that
process
happens,
if
there's
stuff
that's
happening
it's
on
towards
ie,
not
within
the
bounds
of
their
agreement,
which
they'll
need
to
be
properly
kind
of
checking
against.
C
Not
just
for
this
everything
you
know
what
they've
booked
this
not
booked.
If
they
said
they're
only
going
to
touch
offbeat
courts
and
they
start
booking
on
peak
courts,
and
you
know
all
kinds
of
things
and
it
might
might
not
be
in
the
bounds
of
that
agreement
that
they
would
need
to
have
that
check
and
balance
between
them.
So
I
suppose
this
is
the
same
kind
of
thing.
It's
just
a
you
know
it's
another
one
of
those.
C
E
So
a
little
complication
that
we
should
we'll
probably
ignore
straight
away.
If
you're
going
to
do
that,
then
the
price
you
charge
with
a
squash
court
as
an
override
would
depend
on
when
he
was
selling
it
if
you're
selling
it
off
peak,
but
he
didn't
make
it.
You
know
the
four
pound
because
he's
better
than
nothing.
If
he's
selling
at
peak,
then
he
probably
wants
to
manage
that
so
beginning
with.
C
A
C
C
D
I,
don't
if
you
have
any
view
on
this,
yeah
I
was
just
going
to
chime
in
there.
My
view
would
be
it'd,
be
really
useful
and
to
kind
of
leave
that
as
possible,
but
at
the
same
time
I
guess
it's
it's
further
down
the
line
and
if
it
was
still
in
mind
for
the
next
iteration
of
this
then-
and
that
would
be
fine
if
it
was
gonna-
hold
hold
up
in
any
sense
but
yeah.
D
A
C
Basically
they
can
do
anything
you
want
to
do,
except
with
this,
because
the
booking
system
ultimately
holds
the
keys
to
the
reconciliation
in
this
respect.
So
that's
that's.
The
only
reason
this
is
in
here
is
just
because
that's
laughter
that
only
thing
that
is
is
restricted
to
be
something
significant
but
yeah.
Let's,
let's
make.
A
Okay,
well,
I'm
gonna
remind
us
that
we
did.
We
did
round
up
people
and
we
did
have
a
list
of
requirements
for
1.0.
So
in
order
good,
you
need
to
get
this
agreed
and
finished
so
that
people
can
start
implementing
it
and
then
thinking
about
what
future
iterations
were.
We
need
to
keep
coming
back
to
the
stuff
that
the
community
had
agreed
to
yet.
C
Totally
agree
why
yeah?
My
main
thing
here
is
that
this,
although
this
is
this-
is
a
paragraph
in
here.
If
it's
in
terms
of
implementation
not
usually
contentious,
it's
not
the
thing
that's
holding
us
up.
If
it
is
that
they,
you
know
lots
of
debate
around
how
we
do
it,
rather
than
whether
we
should
do
it,
and
maybe
that's
er.
D
Okay,
I
think,
is
it
if
it
doesn't
hold
it
up,
then,
if
this
I'm
just
not
sure
what
the
outcome
is,
if
it's
included
it'd
be
bearish,
it
was
included,
but
if
it
is
actually
going
to
hold
up
in
any
significant
way,
then
I
think
it's
worth
putting
in
the
next
iteration
but
having
this
included
and
make
it
possible
from
a
booking
system
standpoint
does
that
need
the
input
of
the
community
when
I
think
it
was
brought
up
before
and
I.
Think
if
it's
not
utilized
is
that
a
problem.
E
Can't
see
the
problem
I
mean
kind
of
two
lines,
because
I
think
that
we
did.
We
did
talk
about
this
at
some
point.
I
think
that
we
talked
about
this
stuff
first
session
with
the
legend
customers
go
back
a
year,
mm-hmm
because
they
do
want.
You
know
not
the
char's
of
prices
record
in
the
system.
They
want
the
brothers
to
be
able
to
have
the
face
bills.
You
do
it's
actually
more
work
for
us
because
we
don't.
You
know,
we
haven't
fought
the
prize
in
the
system.
E
The
price
we
charge
comes
back
and
we've
got
to
manage
the
way.
That's
done.
It's
not
a
huge
amount,
though
so
I
don't
have
a
bad
vibe
about
it,
but
I
also
think
that
it
may
not
be
the
right
mechanism
yeah,
because
this
is
a
very
open
mechanism
and
how
do
we
count
for
it?
For
example,
you
know
what
GL
code
is
this.
Is
it
going
to
be
the
same
for
every
kind
of
thing,
or
do
we
need
to
be
able
to
manage
that?
E
C
C
Yeah
I
think
that's
it.
I
know
what
this
was
going
for
is
just
like
you
say,
I
think
when
we
get
into
the
actual.
You
know
application
people
using
then
those
those
are.
The
requirements,
will
kind
of
be
shaken
out
a
little
bit
in
terms
of
people
saying
what
they
need
and
how
it
works,
and
things
like
that
and
there's
nothing
to
stop
us
removing
it
in
this
future
version
as
well.
C
If
you
know
it
was
causing
challenges
or
anything
like
that,
I
mean
it
will
be
extremely
simple
for
a
booking
system
to
rate
a
seller,
to
stipulate
that
this
must
not
be
used
to
the
broker,
and
then
you
know,
and
obviously,
if
they
go
outside
the
back
contractual
relationship,
that
would
be
their
relationship
over
I.
Don't
think
any
broker's
going
to
want
to
risk
and
ignite
that
so.
E
A
System
is
gonna
have
to
implement
at
least
a
check
to
make
sure
that
this
doesn't
happen
if
they're
not
sued
ice
overrides
at
all
or
with
individual
brokers.
So
they'll
need
to
be
I'm
thinking
that
system
to
to
track
that
I,
don't
think
it's
going
to
be
pushed
out
to
do.
It
can
be
unsafe
to
just
accept
orders
that
offer
overrides
and
hope.
C
C
E
Keen
that
we
keep
it
orders
right
find
about
it,
but
just
keeps
it
just
keeps
me
clean,
because
the
the
booking
system
can
store
an
order
at
the
brokest,
where
you
can
store
an
order,
but
then
it's
got
the
whole
thing
coming
in
I
didn't
I
kind
of
forget
what
I
said.
I've
got
mixed
feelings
about
it,
because
the
other
thing
is
that
they
say:
I'm
gonna
have
a
food
changes,
the
audience,
but
an
item
with
a
significant
order.
Hundred
items
in
it
and
one
item
changes.
That's
a
lot
of
works
to
construct.
E
A
F
A
C
But
the
main
thing
that
needs
to
happen
now,
assuming
that,
where
everyone's
onboard
with
this
is
that
the
model
needs
to
be
fleshed
out
in
more
detail
to
include
the
kind
of
the
fields
and
things
like
that,
so
the
moment
9.1
is,
is
a
just
an
example
model
to
includes
a
bunch
of
the
millions
kind
of
weather.
All
of
this
stuff
is
necessary.
C
Basically,
the
the
the
remaining
bit
of
this
that's
needed
is
to
flesh
that
out
in
detail,
so
probably
a
table
per
object,
as
we've
done
in
other
specs,
with
the
detail
about
what
each
of
those
fields
means
and
then
yeah,
and
then
that
some
cleanup
at
the
end
of
this
back
around
there,
a
handling
Tunisia
leveled
ties
up.
But
if,
if
these
questions
are
resolved,
I
think
we're
out
the
other
side
of
the
kind
of
main
point
of
contention,
because
we've
effectively
simplified
everything
out.
B
A
Then
give
a
link
to
a
github
issue
where
we
can
collect
why
the
comments
or
for
section
nine,
this
still
needs
work
and
then
submit
this
to
the
rest
to
the
rest
of
the
standards
group,
just
both
mailing
list,
because
then
we
can
confess
that
you
know
the
minute
we're
checking.
You
have
a
couple
of
weeks.
There's
quite
substantial
changes.
It'd
be
nice
just
to
get
into
refining
the
details
now
and
I
think
we
should
better
do
that
part
of
those
discussions
together.
C
D
A
Sound
like
the
big
areas,
I
think
there
might
be
a
few.
You
know
bits
of
feedback
on
wording
or
other
aspects.
This
respect
I
think
because
we've
only
we
because
there's
been
such
a
lot
of
changes
in
the
last
few
weeks,
I
think
we
need
to
give
people
a
bit
of
an
opportunity
to
digest
the
spec
for
those
Patino's
that
haven't
been
able
to
make
all
of
the
calls.
So
there
may
be
some
other
issues
of
people
service,
but
I
think
we
just
need
to
get
okay.
E
A
Last
year,
so
like
so,
the
the
process
which
might
following
previously
was
to
get
to
respect
where
we
think
we've
addressed
all
of
the
outstanding
issues,
give
people
a
kind
of
notice
that
we're
going
to
put
a
proper
1.0
rubber
stamp
on
it.
So
I
think
we
need
to
give
people
at
least
another
couple
of
weeks
in
order
to
do
a
review
and
surface
any
other
issues,
and
it
takes
up
then
on
the
next
call
to
see
how
how
many
issues
have
come
up.
A
A
E
From
my
perspective,
I
mean
I
had
I,
for
once
actually
did
some
preparation,
Nicky
be
proud
of
me.
Yes,
but
I
kind
of
got.
It
took
me
about
an
hour
to
get
about
a
third
of
the
way
through
it
because
he's
dense,
stuff
and
I'm.
The
really
at
this
point
stopped
putting
real
developers
behind
it,
because
you
know
I
know
stuff,
but
I
could
do
with
the
real
developer.
E
Looking
at
this
and
say:
oh
yes,
well,
but
not
and
I
think
that
overall
thing
to
actually
get
it
formally
approved
when
these
discussion
it
inside
particular
the
larger
organizations
and
it's
a
little
bit
more
stumping
in
their
levels.
So
I
think
we
need
to
be
just
aware
of
that,
and
things
need
to
get
to
a
version
which
the
the
group
here
feels
is
about
right.
But
I
think
there
will
be
another
another
step
where
we
get
that
rubber
stamp
within
various
organizations
make.
E
E
C
There's
a
couple
of
people
who
were
looking
at
doing
in
the
short
term,
a
peep
and
I
can
make
it
today,
but
I
know
looking
very
short-term
to
get
something
together.
So
soda
fact,
it
sounds
like
that
means
that
the
next
step
so
wrapping
us
up
and
getting
us
out
so
that
this
group
can
feedback
on
the
detail
in
github
issues.
That's
two
weeks
plus
two
weeks
potentially
and
then
we're
into
the
developers
looking
at
it
sounds
like
and
that's
another
two
weeks
plus
two
weeks
so
we're
two
months
off.
I.
E
Hadn't
thought
it
would
be
that
bad
I
would
have
thought
in
two
weeks
if,
if
we
can
get
a
final
draft
with
all
the
changes,
there's
a
lot
to
do
sorry,
I.
Think
there's
a
lot
of
detail
to
trim
through
I.
Do
things
a
lot
to
do,
but
that
still
work,
yeah
I?
Think
it's
I
think
this
change
is
a
very
positive
Nick
by
the
web,
thinks
it's
gonna
fall
well,
so
I
think
in
two
weeks
time
we
should
be
in
a
position
if
you
get
it
to
us.
A
A
So
on
that
basis,
then,
if
we
aim
for
into
so
we've
got
the
next
two
weeks
for
the
the
open
active
community
group
to
comment
on
this
draft
with
you
know,
there
might
be
some
revisions
from
Nick,
but
he's
going
to
annotate,
which
bits
are
about
to
change,
and
then
we
say
to
the
community
a
month
after
that
is
when
we're
aiming
for
what
we
know.
So
we
want
wider
review.
A
If
people
want
to
do
some
prototyping
within
that
period,
then
they've
got
a
day
to
shoot
for,
and
that
also
gives
time
for
that
internal
view
that
he
was
just
a
year.
That
means
that
the
the
call
in
a
month's
time
we
could
make
that
a
and
not
just
a
high-level
walkthrough
as
a
kind
of
tutorial,
so
not
going
to
the
details
necessarily
but
just
kind
of
use
it
as
a
way
to
do
a
kind
of
refresher
through
the
API
suspect
for
everybody
who
hasn't
been
able
to
make
it.
E
A
B
E
C
I'd
love
that
I
mean
but
part
of
the
section,
1
2,
3,
&
4,
really
quite
boilerplate,
section
5
starts
the
user
journey
in
strain.
2
diagrams
I
tried
to
remove
as
much
before
section
5
as
possible,
but
you
can
tell
everyone
to
start
section
5.
It
ignore
everything
before
that,
because
you
don't
really
need
to
read
it
and
I
guess.
Maybe
I
can
ask
me
about
whether
we
need
anything
before
sorry
section
so
section
section
3
typographical
conventions,
which
is
not
that
much
and
then
conformance
at
section.
2
is
a
very
boilerplate
thing.
A
A
A
F
F
Essentially,
they
worked
with
a
range
of
different
people
with
disabilities
to
kind
of
help
make
sport
more
accessible,
I
think
there's
a
real
interest
in
how
they
could
help
us
kind
of
redefine
their
kind
of
data
that
we're
capturing
potentially
even
about
accessibility,
because
I
think
the
feedback
I've
got
so
far
on
on
the
two
bits.
This
backward
just
kind
of
a
focused
on
accessibility
that
they're
a
kind
of
a
good
starting
point,
but
they
they
don't
really
capture
the
breadth
of
things
that
people
need
to
know
and
I.
Think
there's
I!
F
Think
in
this.
Forgive
me
I'm
going
to
not
remember
any
of
the
technical
titles
of
all
those
fields
are
called
it's
not
very
helpful,
but
I.
Think
there's
one
which
has
quite
a
lot
of
potential
tick
boxes.
Think
these,
like
a
real
range
of
things
like
pregnancy,
suitable
and
people
with
different
health
conditions
or
house
cancer,
has
wheelchair
accessible
I
mean.
Is
that
there's
a
real
kind
of
well-intentioned
mishmash
I
think
is
maybe
a
fantasy
of
different
things.
F
All
of
these
different
organizations
have
a
slightly
different
view
of
the
kind
of
data
we
might
need
to
capture,
which
is
going
to
be
an
interesting
challenge,
but
I
think
there's
a
bit
of
a
moment
happening
potentially
that
I
think
at
the
right
point
we'll
need
to
capitalize
on
and
I
think.
Actually,
the
other
thing
I'd
wanted
to
pick
someone's
brain
on
is
while
they're
kind
of
booking
stuff
is
happening.
F
Is
there
something
that
I
can
push
forward,
or
is
there
something
that
I
can
kind
of,
because
what
I
have
done
is
directed
activity
Alliance
back
to
that
video
call
that
we
did
way
back
where
nerds
like
a
that,
was
the
last
group
discussion
we
had
and
just
to
get
some
of
their
feedback
on
what
their
initial
thoughts
we're
on
dirty
bits
and
the
standard
that
cover
accessibility.
What
else
we
might
need
to
capture
as
a
starting
point
but
I'm
sure
there's
other
things
we
could
be
doing
yeah.
A
So
what
why
would
I
think
there
is?
There
is
a
way
to
go
to
progressiva
in
parallel,
so
what
I
would
suggest?
Is
we
start
to
pull
together?
A
description
document
could
just
be
a
Google
Doc,
maybe
kind
of
activity
lines
put
down
what
their
thoughts
are
around,
what
data
should
be
collected,
and
then
we
give
the
opportunity
for
other
people
to
chime
in
on
that
see
whether
they
go
in
just
agree.
So
we
can
start
to
see
where
there
is
some
alignment
or
some
discussion
required
before
we
drop
in.
A
F
Yeah
that
sounds
perfect
and
I
will
cuz
I.
Think
the
other
thing
which
I
know
is
kind
of
in
there
in
the
longer-term
roadmap,
but
it'd
be
good
to
know
if
there's
a
point
which
this
gets
picked
up
because
I
think
that
helps
people
to
forward
plan
I
know
that's
why
discussion
for
that
a
package
of
stuff
as
well
but
yeah.
F
A
F
Okay,
well
I'll
find
somewhere
to
put
a
shared,
Google,
Doc
and
then
I'll
ask
activity
Alliance
to
feed
into
it.
I'll
put
in
I
can
dig
out
the
relevant
bits.
The
spec
and
me
you
guys
can
be
sure
that
picks
out
links
the
cool
things
like
that
and
just
trying
galvanize
people
around
filling
filling
yeah
and
share
that
round.
Obviously,
yeah.
C
C
B
Yeah
just
come
across
this
really
the
last
last
week.
The
Petersons
Iranians
could
do
this
vectors
just
coordinating
with
everyone
else,
for
only
so,
we
can
certainly
get
things
to
get.
These
ribbon
hasn't
some
conversations
in
house
where
tuba
developers
here
who
do
this
one
thing
so
I
search
feature
to
the
relevant
people
here
and
see
if
we
get
these
movie
but
Sony
get
sort
of
beep
up
for
you
within
six
week
period,
yeah.
A
For
coming
on
yeah,
well,
thanks
for
everybody's
particulars,
we've
run
25
minutes
over
today.
As
always,
it's
really
useful
discussion.
So
thanks
for
your
contributions
and
thank
you
for
taking
some
time
in
the
next
two
weeks
to
comment
on
the
on
the
spec
and
we'll
catch
up
again
in
the
next
call
in
two
weeks
time:
okay,.