►
From YouTube: OpenActive W3C Community Group Meeting / 2018-02-14
Description
A public hangout for members of the OpenActive W3C Community Group.
Agenda: https://lists.w3.org/Archives/Public/public-openactive/2018Feb/0002.html
For more information visit: https://www.openactive.io/w3c-community-group.html
A
So
the
focus
of
our
call
this
afternoon
is
going
to
be
booking
again,
so
it
would
be
checking
on
progress.
We've
been
making
since
last
call
and
then
start
to
do
a
quick,
high-level
run-through
of
some
documentation
that
Nick
and
I
have
been
putting
together
just
looking
at
who's
on
the
call
I,
don't
recognize
seven
Sam,
I'm!
Apologies!
If
you
have
been
on
the
call
and
I've
missed
you
before,
but
do
you
want
to
just
do
a
quick
intro
to
see
where
you're
from.
B
B
A
A
Okay,
right!
If
you
think,
then,
at
the
end,
I'll
check
in
again
right,
so
just
a
quick
review
of
our
planned
roadmap.
So
last
time
we
reviewed
the
the
outcome
of
the
workshop
and
I
broad
high-level
plan
for
what
we
want
to
do
to
support
making
more
opportunity
data
bookable,
so
we're
planning
to
publish
set
of
best
practices
around
API
design.
A
So
that's
the
kind
of
board
framework
that
we're
going
to
be
working
on
and
within
over
the
next
few
months.
So,
in
terms
of
the
actual
tasks,
the
short-term
tasks
that
we
identified
at
the
workshop
within
subsequent
discussions,
there's
a
few
I
just
wanted
to
quickly
go
through
those
and
show
which
ones
we've
made
progress
on
so
I've
circulated.
The
workshop
summary.
We
discussed
that
last
time
at
the
workshop
attendee
said:
that'd
be
good
to
have
a
set
of
use
cases
and
requirements
that
would
inform
the
design.
A
A
We
probably
need
to
have
further
discussion
around
that,
but
I
think
we
know
what
the
minimum
is
in
terms
of
what's
required
to
actually
service
booking,
but
all
the
people
have
got
different
definitions
of
minimum,
their
needs
for
support
participants,
get
funding,
etc.
So
there
is
still
some
discussion
to
be
had
there.
We
also
said
that
we
needed
to
start
to
identify
some
early
pilot
implementations.
A
We
note
with
I
think
we're
engaging
a
Nixon
touch
with
a
number
of
people
who
are
currently
working
on
building
out
working
api's
and
are
trying
to
work
within
the
guidance
and
best
practices
that
that
we're
putting
together
here
so
I
think
we
can
take
that
off
and
in
I'm
in
about
a
month's
time.
We'll
do
a
kind
of
check
in
to
see
how
people
have
fared
with
those
experiments
haven't
yet
published
the
API
design
best
practice.
A
Obviously,
we
need
to
start
drafting
the
API
spec
itself.
So
that's
the
piece
of
work
that
Nick
started
on,
as
we
discussed
last
time,
we're
doing
that
within
a
Google
document.
That
I
think
it's
been
shared
with
a
few
people
initially,
but
we're
going
to
circulate
wider
today
we're
going
to
use
it
the
Google
document
to
make
it
easier
to
kind
of
collaborate
around
the
text
and
have
discussions
on
particular
features
before
turning
it
into
a
more
formal
doc.
A
So
that's
where
we
are
I'll
circulate
the
slides
after
the
call,
so
we've
got
base
cut
for
working
docks
at
the
moment.
There's
the
workshop
right
up,
which
I've
shared
there's,
the
use
cases
Amanda
said
yesterday
and
then
two
docks
that
you
hope
I've
seen
yet.
But
you
start
to
dig
into
are
the
API
best
practices
and
the
booking
specification
then
Nick's
going
to
take
us
through
so
I'm
open
I
can
just
we'll
do
a
regular
check-in
over
the
coming
months
around
these
documents.
A
A
There
shouldn't
be
anything
surprising
in
there
for
anyone,
because
I've
hopefully
captured
everything
that
we
discussed
in
in
the
workshop,
but
this
would
be
a
good
opportunity
just
to
see
if
we've
missed
anything
so
the
in
a
minute,
but
just
kind
of
just
give
you
some
context
of
why
I've
put
it
together
and
have
put
it
together,
wanted
some
high-level
use
start
again.
I
mean
for
putting
this
together
is
to
make
sure
that
everyone
is
clear
on
the
scope
for
the
first
pieces
of
work.
A
We're
doing
around
booking
so
want
to
make
sure
that
we
acknowledging
all
of
the
requirements
that
have
come
from
everyone,
who's
provided
feedback
and
suggestions
so
far,
but
also
just
clarify
how
we're
planning
to
prioritize
working
on
on
those
requirements.
So
the
use
cases
should
hopefully
capture
the
diverse
needs
for
different
types
of
users
that
we've
engaged
with.
So
the
platform's
people
providing
the
access
to
the
API
is
third-party
applications
of
using
them
and
end-users.
A
What
I've
done
is
I've
tried
to
capture
everything,
so
it's
trying
to
be
comprehensive
as
far
as
the
input
that
we've
had
so
far,
but
just
acknowledging
that
not
all
of
them
are
going
to
be
in
scope
for
vision.
One
again,
the
reason
for
doing
that
is
just
to
make
sure
that
when
we
have,
you
know
when
we
start
to
share
with
the
wider
community
everyone's
clear
that
we
have
acknowledged
that
there
are
the
specific
needs
or
extra
requirements.
It's
not
that
we're
ignoring
them.
A
A
A
A
So
that's
kind
of
my
fav
you.
Let
me
just
kind
of
show
you
the
document.
A
few
people
are
in
it
already.
Hopefully,
I
still
see
this
right,
and
so
the
what
I've
started
to
do
with
the
stuff
that
this
document
is
spell
out
some
terminology.
That
was
something
that
was
highlighted
quite
quickly
in
the
workshop
that
we
needed
to
be
clear
about
the
different
roles
involved
in
servicing
third
party
booking.
So
what
what's
the
role
of
the
platform?
What
is
the
third
party
differences
between
users
account
holders?
Members
etc.
A
So
the
the
use
cases
they're
divided
up
into
use
cases
for
users,
platforms
and
third
parties.
So
the
third
parties
is
the
term
I've
given
to
the
application.
That
is
the
client
of
the
API.
The.
A
Most
of
the
requirement,
the
most
of
the
use
cases
rather
are
under
the
users
rather
than
the
other
stakeholders.
So
that
would
be
something
that
your
attention
to,
as
so
are
there
additional
use
cases
from
a
platform
point
of
view
or
from
a
third
pod,
one
of
you
that
aren't
covered
by
some
of
the
existing
requirements?
A
So
please,
you
know,
please
take
a
look
there
and
give
us
some
feedback
on
the
document,
and
so
just
give
you
a
sense
of
the
kind
of
the
detail
that
are
in
there.
It's
supposed
to
be
quite
quite
straightforward,
so
first
on
see
the
price
to
participate
in
the
vendor
or
facility.
So
it's
just
reflecting
the
fact
that
we
need
to
be
able
to
show
within
the
opportunity
data
there
needs
to
be
a
price,
clear
price
available
that
can
be
used
by
the
party
application
to
filter
discovery
based
on
price.
A
You
know
somebody
might
just
be
interested
in
free
events
or
be
able
to
actually
properly
initiate
the
booking
workflow
for
each
of
the
use
cases
I've
highlighted
where
how
they
decomposed
into
some
of
the
more
fine-grained
requirements.
So
you
can
click
through
the
Leighton
and
document.
So
there's
some
cross-referencing
there
to
make
sure
that
we've
got
them
kind
of
clear
audit
trail
that
we
can.
You
know
for
every
we
require
MIT
and
we've
got
inspect.
We
can
go
back
to
like
where
it
came
from.
A
I'm
not
gonna,
go
through
all
of
these
in
detail,
because
he's
probably
but
the
easier
for
you
to
kind
of
review
at
your
leisure,
but
just
to
kind
of
highlight
a
few
things
like
there
are
some
use
cases
on
here
about
authenticating
as
an
existing
account
holder
on
a
platform
which
I
think
media
we'd
agreed
were,
would
be
out
of
scope
for
version
one,
but
I
have
included
them
here
and
tried
to
indicate
how
they
deeper
break
down
into
additional
requirements.
A
So
just
help
us
move
on
to
that
kind
of
later
stage
of
the
API
development,
because
we've
got
this
kind
ground
working
face.
So
take
a
look.
Take
a
look
through
these
see,
give
me
feedback
on
the
scope.
The
wording
tell
me
if
there's
things
that
are
missing
and
a
few
things
that
occurred
to
me,
that
I
think
we
might
need
to
have
a
bit
more
discussion
around
is
around
handling
of
personal
data.
A
So
obviously,
we
need
to
be
mindful
that
what
we're
defining
here
conforms
to
GPR
that
we're
doing
all
the
right
things
in
terms
of
handling
versatile
information,
but
importantly
that
third-party
applications
can
do
the
right
thing
in
terms
of
making
it
clear
about
where
somebody's
personal
data
is
going
to
end
up.
So,
if
you're
submitting
your
name
and
contact
information
through
an
app,
what
platform
is
going
to
be
storing
that?
A
Because
if
they
later
need
to
want
it,
they
later
want
to
exercise
some
of
their
rights
onto
GP
at
gdpr,
so
ask
for
the
data
to
be
removed.
They
need
to
know
where
to
go.
I,
don't
think,
we've
quite
nailed
down,
yet
whether
we
were
expecting
third
parties
to
remained
kind
of
in
the
loop
there
or
whether
users
are
going
to
be
directed
back
to
the
platform.
A
But
so
there's
some
things
to
discuss.
I
think
as
part
of
the
design
there.
But
I've
tried
to
draw
like
these.
These
kind
of
use
cases
so,
for
example,
that
if
so
within
a
booking
workflow
users
work
may
need
to
be
presented
with
terms
and
conditions.
They
may
need
to
be
asked
to
give
consent
for
their
data
to
be
stored
or
used
in
certain
ways.
A
If
that's
the
case,
then
that
information
will
need
to
be
exposed
in
a
machine-readable
way
for
a
third
party
to
be
able
to
show
the
right
terms
and
conditions.
The
right
consent
on
check,
check
lists
for
the
specific
platform
that
is
acceptable
booking.
So
that
is
that
kind
of
detail
that
we
will
need
to
get
into
and
I
think.
When
we
come
back
to
discussing
the
minimum
user
information,
we
need
to
bear
gdpr
in
mind
as
well.
There
there's
a
key
point
in
DGP
are,
but
you
can't
withhold
consent
or
collect
information.
A
A
I've,
said
this,
so
hopefully
that
will
have
helps
kind
of
reinforce
what
is
in
scope
so
for
each
of
those
there's
just
a
brief
summary
of
what
the
what
the
requirement
is:
I've
cross
linked
to
the
existing
spec,
where
we
might
have
already
covered
some
of
these
requirements
or
terminology
that
applies
so
just
give
an
example.
We
obviously
need
to
be
able
to
uniquely
identify
the
events
and
facilities
that
are
going
to
be
used
in
the
booking.
A
We've
can
already
do
that
within
the
modeling
spec,
but
people
aren't
necessarily
applying
that
part
of
this
back
in
a
consistent
way.
So
that's
where
we
need
to
go
back
and
revise
by
the
specification
or
provide
a
bit
more
guidance
to
publishers
about
what's
the
minimum
data
that's
required
to
make
their
data
book
of
all.
A
A
C
D
A
E
So
GL
ELLs
own
app
would
be
a
third
party.
But
then
so
we
change
for
life
and
I.
Think,
as
that
particularly
came
out
the
conversation
with
legends,
because
I
know
that
there
were,
there
were
two
quite
different
use
cases
in
some
of
the
things
we
were
talking
about,
depending
if
you're,
an
app
or
a
change
for
life
thing.
So
I
wonder
whether
we
call
them
I,
wonder
whether
we
call
the
latter
one,
a
broker
using
scheme
dogs,
kind
of
terminology
for
that
and
then
and
then
have
another
name
for
the
app
kind
of
scenario.
A
Well,
it
should
be:
it's
not
been
designed
with
them
I'm
in
in
mind.
It
should
just
be
a
general-purpose
API,
I
I
was
actually
gonna
suggest,
instead
of
broker,
because
I
hadn't
realized
that
there
was
this.
The
term
was
overloaded
whether
we
should
just
use
plan.
That's
eventually
what
we're
talking
about,
and
we
don't
have
to
identify
what
type
of
client.
E
In
one
of
the
stories
I'm
interested
and
how
you've
described
it
is
the
one
where
we
talked
about
remember
there
was
that
thing
about
new
I
think
we
called
them.
Third,
just
one
of
these
the
words
again
third
party
uses
or
third
party
accounts
or
something
is
it
did
you
use
the
words
third
party
to
talk
about
those
and
then
I,
guess
that
is
there
a
distinction
between
a
third
party
account
and
a
whatever
we
call
in
the
other
talks
account.
F
A
F
Probably,
what
I
was
talking
about
where
it's
a
Nayeem
type
thing
so
relationship
with
many
operators?
So
if
you've
got
the
GL
with
an
app
that's
kind
of
a
one-to-one
relationship,
I
mean
with
400
different
letter
operators.
You
wish
again
so
that's
probably
where
I
might
have
used
third
party.
But
if
I'm
perfectly
honest
I
can't
remember.
That's.
E
Okay
know
anything:
that's
that's
good,
like
external
service
I
said
that
did
the
particular
functional
distinction
there
from
the
last
conversation
was
that
if
an
app
that
gll
owns,
which
is
an
external
service,
creates
an
account
that
would
one
type
of
account,
but
if
an
app
that,
if
an
I'm
in
or
something
creates
an
account,
that
would
be
a
another
types
account.
That's.
A
F
To
try
and
link
up
to
a
DLL
account
which
gives
you
a
hundred
percent
discount
if
you're
in
Ironman,
for
example,
you
just
get
whatever
the
price
the
day
is
rather
than
getting
special
discounts.
I.
Don't
think
we're
at
the
moment
ready
to
look
at
how
to
link
up
external
and
internal
accounts.
They
say
something
you
found
quite
challenging.
F
E
E
Think
there's
a
requirement
here
is
that
if
the
at
the
external
service
identifies
itself
as
a
aggregator,
then
the
the
platform
will
do
something.
And
if
I
identifies
itself
as
an
app
owned
by
the
lesser
operator,
then
it
will
do
something
else.
So
there's
a
there's,
a
functional
distinction
in
what
happens
depending
on
how
it
identifies
itself,
but
is
that
is.
A
That,
whatever
that
behavior
might
be,
are
we
saying
that
that
is
something
that
is
true
of
all
platforms
and
all
of
those
types
of
clients
that
everyone
has
to
do
it
the
same
way
as
if
they
don't,
then
it
shouldn't
be
within
the
API
spec.
It
should
just
be
part
of
the
detail
of
that
platform.
Implementation
or
part
of
the
integration.
F
We
wrangled
for
two
or
three
hours
before
coming
up
with
that
and
I
think
we
were
quite
fortunate.
Someone
have
that
idea,
so
I
think
it's
useful
and
for
the
leisure
operators
to
have
some
guidance
as
to
it
might
work
with.
First
time
see
alligator.
No,
it
shouldn't
be
part
of
the
API
today,
I,
don't
think
you
should
be
I,
think
it's
it.
Rather
it's
relating
information
that
should
be
accessible
to
people.
I
guess
so.
We'd
have
to
think
too
much.
A
Okay,
so
what's
gonna
move
on
to
next
was
the
looking
at
the
work
that
Nick
has
been
doing
around
a
draft
design
for
the
API.
So,
as
I
was
saying
earlier,
I'm
is
a
number
of
projects
that
are
kind
of
in
flight.
At
the
moment
it
seemed
a
good
opportunity
to
try
and
start
to
point
people
in
a
common
direction.
So
that's
why
Nick
has
kind
of
started
to
do
this
drafting
work
and
it
gives
us
an
opportunity
to
get
some
real
implementation
feedback
from
some
of
these
early
design
decisions
so
Nick.
E
So
the
particular
people,
oh
and
Jamie,
for
your
for
the
API
you
provided
a
while
ago,
there's
a
you,
gave
us
a
spec
a
few
months
ago.
That
was
so
thanks.
Everybody,
hopefully
I've
tried
to
do
it.
Justice
bringing
this
into
one,
because
everyone's
kind
of
come
come
at
it
from
slightly
different
angles.
E
The
main
thing
we
tried
to
do
for
the
first
version
is
just
create
of
the
MVP.
That's
really
succinct
and
does
something
simple
that
we
can
kind
of
start
to
implement
and
because
I
know
that
some
some
folks
are
already
at
a
a
bit
of
an
urgent
need
to
implement
some
some
of
this
design
now
for
their
various
reasons.
So
that's
so
I
know
that,
for
example,
make
sweat.
E
E
So
that's
that
one
and
then
there's
this
two-step
two
phase
commit
there's
a
lease
in
a
book
step.
The
lease
is
at
the
moment
it's
an
order,
somewhat
modeled
off
the
basket
that
legend
has
and
the
idea
with
that
is
that
you
can
create
an
order.
You
can
add
items
to
the
order
and
then,
when
you
want
to
book
the
when
you
want
to
complete
the
booking,
you
just
add
a
payment
to
the
order
in
that
complete
set
and
that
uses
the
schema.org
order,
semantics
and
things
that
are
built
into
that.
E
So
we're
basing
all
of
the
language
currently
is
coming
straight
from
schema.org
we
haven't
I.
Think
we've
only
used
one
additional,
which
I'll
come
to
talk
about
element
that
isn't
in
schema,
because
they've
got
quite
an
advanced
model
for
both
invoices
and
for
the
order.
So
that's
what
that
is
before
I
switch
the
screen
over.
Does
anyone
have
any
questions,
comments
or
I.
A
E
B
E
Yes,
excellent,
okay,
great
okay,
so
this
is
the
this
is
the
booking
spec
and
it
will
be
shared
after
this
I
believe
if
you
haven't
already
seen
it
so
it
does
begin
at
the
top.
It
references
the
use
cases
document
these
just
gone
through,
summarizes
the
goals
come
out
of
that
document
and
also
the
non
goals.
Things
are
out
for
it,
but
rather
than
go
into
the
detail
of
this
now,
I
thought
it
might
be
good
to
just
talk
to
some
particular
points
which
such
as
the
one
hand,
just
highlighted
in
the
document.
E
It's
a
bit
I
just
just
mentioned
at
the
first
bit
about
it's
just
as
simple
as
getting
the
session
with
the
session
I
hear,
and
that
returning
just
a
single
of
an
object
as
one
would
get
from
the
feed,
but
just
with
everything
in
it,
and
so
this
allows
me
to
just
just
talk
about
the
thing
that
Ian's
rent
mentioned
there,
which
is
a
really
good
point.
So
there's
two
ways:
when
you
return
an
object
at
the
moment,
there's
two
ways
it
can
come
back.
E
One
is
that
it
comes
back
with
an
offer
and
if
it's
gone
offer,
it's
got
a
price,
the
currency
and
you
can
actually
book
the
offer
and
that
offer
is
obviously
an
offer
on
an
event.
So
in
this
case
it's
speed,
ball
speed
ball
on
the
27th
at
the
first
11:00
a.m.
and
it
cost
39
pounds,
and
that's
that's
one
mode
for
a
paid
session.
Another
mode
is
a
free
session
and
a
free
session,
according
to
schema,
doesn't
actually
need
an
offer
at
all.
E
It
just
needs
is
accessible
for
free
property
to
be
set
to
true,
and
the
issue
with
this
is
that,
if
you
have
a
free
thing
like
this,
that,
then
you
don't
actually
need
to
pay
it,
because
obviously
you
can
just,
but
you
can
just
confirm
it
instantly,
but
Ian.
Your
point
is
absolutely
right
and
I
haven't
actually
thought
about
it
until
just
now
that
you
probably
still
do
want
to
have
the
concept
of
reserving
it
and
then
confirming
it
as
two-step
process.
F
Yes,
I
mean
if
it's
just
a
one-off
booking,
if
you're
only
going
to
say
I
want
to
squash
quite
a
talk
and
it's
free,
which
seems
unlikely.
Then
you
can
just
you
don't
need
a
basket
ten.
If
you
speak,
you
can
have
an
operation,
that's
create
basket.
Lease
complete
yeah,
but
I
would
have
thought.
But
you
know
you
you
may
still
be
putting.
You
may
still
want
to
put
many
free
things
in
a
basket,
so
you've
got
yourself.
You've
got
your
daughter.
You've
got
your
bait
mount
and
you'll
want
to
go
at
this
free
session.
A
Yeah
so
Nick
and
I
very
briefly
discuss
this,
but
I
think
this
is
one
area
where
I
think
it'd
be
fine
for
us
to
put
some
extra
requirements
around
the
data
model.
So,
while
schema.org
has
this
property
for
indicating
free
events
for
consistency,
it
might
be
easier.
If
we
just
say
every
every
event
should
have
an
offer,
even
if
it's
the
cost,
because
it
just
gives
some
consistencies
in
the
data
and
then
she's
gonna
get
into
this.
But
it
provides
a
consistent
way
to
hook
into
the
booking
workflow.
E
Yeah,
that's
right,
I
think
I,
think
that
sounds
like
the
consensus
that
we're
kind
of
coming
to
here
there's
a
there's,
a
comment
on
the
side
on
one
of
these.
That's
talked
about
something
similar
and
I.
Think
I
think
that's
C
I
think.
Basically,
yes,
so
this
is
I,
think
this
is
Nick
and
potentially
axel
or
comments
on
this
as
well
with
something
similar.
So
maybe
maybe
the
simplest
thing
to
do
here
is
rather
than
using
the
semantics
of
is
accessible
for
free.
E
We
have
a
zero
price
offer,
which
is
which
is
effectively
an
offer
here
with
the
price
of
zero,
no
currency,
and
that
offer
is
then
you
can.
You
can
complete
that
and
pay
it
in
inverted
commas,
but
it's
obviously
zero.
So
your
confirmation
isn't
actually
a
transaction,
but
at
least
it's
then
consistent.
So
you
don't
you
complete
the
payment
in
the
same
way
as
you
would
for
a
paid
booking,
it's
just
for
the
zero
cost
at
the
end
and
and
no
invoice
generated.
F
This
is
a
detail
record
and
to
get
it
back,
you've
lots
of
know
what
the
record
is,
but
then
you're
you're,
including
things
like
the
organizer
and
probably
the
idea,
kind
of
makes
sense
in
it
and
two
things
that
you've
got
a
session
ID
in
a
book
item
ID
I'm,
not
quite
sure
why
they're
different-
and,
secondly,
do
you
need
to
have
that
we're
gonna,
see
in
there
or
the
use
cases
where
you
might
be
passing
this
object
around
without
it
be
linked
to
the
original
listing
requests.
Oh
the.
G
F
We've
got
an
identifier:
you've
got
identify,
as
you
got
say.
It's
called
by
a
session.
Id
you've
got
an
identifier
which
is
one
thing,
but
identifying
she's,
92009
and
you've
also
got
a
book
of
litem
ID
I.
Guess
that's
may
reflect
on
the
price,
so
you
might
have
different
pricing
for
some
circumstance.
We
don't
quite
understand
but-
and
you
need
all
of
those
different
things
in
there
or
in
fact,
are
they
redundant.
F
E
So
that's
a
good!
That's
a
good
segue
into
the
next
question
about
this
book
of
a
litem
ID,
because
you're
absolutely
right.
That
is
a
that
is
a
contentious
point
as
well.
So
I'll
jump
down
to
this,
so
we're
just
covering
these
in
the
kind
of
an
interesting
order,
but
that's
okay!
So
we
just
come
looking
at
time.
So,
let's
if
we
spend
the
kind
of
five
minutes
on
each
of
these
kind
of
remaining
questions,
that
might
be
most
helpful.
So.
E
So
the
fight
so
the
the
book
of
all
item
ID
here
the
issue
would
that
was
that,
if
we
have,
if
we
have
it,
it
is
accessible
for
free
option.
Then
you
have
to
put
a
book
of
a
litem
ID
in
the
in
the
object,
which
is
an
event
in
order
for
it
to
be
consistent.
So
you
can
add
it
to
a
basket
later
or
add
it
to
a.
What
are
we
calling
it
an
order,
because
the
event
type
is
different
to
the
offer
type.
E
However,
we'll
just
discuss
just
now
is
is
unifying
it,
so
there's
always
an
offer.
If
there's
always
an
offer,
then
there's
always
going
to
be
an
offer
ID,
in
which
case
this
doesn't
need
to
be
there,
and
we
can
just
instead
have
the
ID
of
the
offer,
which
is
then
sufficient
to
describe
anything
that
you
book
so
that
it
makes
sense
to
simplify
it.
E
E
Okay,
so
I
mean
I,
think
I
think
we
probably
I
mean
that's,
there's
a
million
talking
but
I'm.
Judging
from
the
comments
and
from
what
they
said
as
well,
we
I
think
we
probably
kind
of
agreed
that
using
offers
consistently
and
using
the
ID.
So
as
not
as
you
say,
overloaded
this
too
much
it's
probably,
we
want
yeah
agreed.
E
E
Should
a
timeout
occur
so
say
something.
You
know
that
user
disappears
with
some
reason,
then
the
order
is
is
disappears
vanishes
if
it
hasn't
been
paid
and
that's
how
you
kind
of
it's
effectively
at
lease,
an
order
which
has
not
being
paid
as
effectively
at
lease.
In
that
case,
the
other
alternative
is,
and
instead
of
having
a
single,
persistent
order,
object
that
gets
filled
up
with
stuff.
We
don't
have
a
single
object.
We
actually
just
individually
lease
all
the
different
things.
So
let's
say
we
were
booking
three
different
classes.
E
We
would
acquire
three
different
leases
and
then,
at
the
point
of
payment
we
would
pass
in
the
three
lease
IDs
into
the
payment
call.
However,
we
do
that
add
them
to
the
order
and
complete
the
payment
and
and
the
way
that
that
would
work
then,
is
that
the
leases
are
all
independent
and
then
at
the
point
of
payment,
you're
collecting
them
together
and
saying
this.
Is
why
transaction
on
book
these
things,
the
advantage
of
the
shopping
basket?
Is
that
the
there's
one
thing
to
timeout?
E
So,
as
you
add
things
to
that
basket,
obviously,
if
every
time
you
add
something,
it's
resetting
the
timeout,
which
means
that
you
you
can
you
know
if
there's
a
five-minute
elapsed
period
where
the
basket
will
disappear
or
15
minutes
or
whatever
it
is
that
that
will
be.
That
will
be
affecting
all
the
items
in
the
basket,
not
just
the
most
recent
one.
E
Conversely,
on
the
collection
of
Lisa's,
you'll
obviously
have
to
make
sure
you
keep
refreshing
each
lease
every
time
the
user
does
something
to
ensure
that
they
don't
timeout
other
time
the
user
gets
to
the
end
of
the
journey,
and
so
but
obviously
the
shopping
basket
requires
persisting
of
that
basket
versus
the
leases
which
don't
require
some
kind
of
centralized
persistence.
You
can
just,
but
you
still
need
to
persist
the
leases
of
course,
because
they're
effectively
stopping
other
people
from
booking,
so.
E
If
the
difficulty
of
moving
from
either
of
those
two
from
say
a
single
lease
to
a
shopping
basket
is
if
that's
not
gonna,
be
difficult.
If
that's
just
in
terms
of
like
the
format
of
the
JSON
structures,
then
maybe
it
doesn't
matter
so
much
yeah.
We
could
just
pick
one
I
mean
it
probably
needs.
We
probably
need
to
fall
on
one
side
or
the
other
and
happy
to
at
the
moment.
G
G
Home
using
myself
in
terms
of
the
complexity
building,
it
is
much
simpler
if
we,
if
we
just
have
individual
litres
and
then
it's
up
to
the
broker
sites.
I'm
I
didn't
hear
that
conversation,
but
you
might
call
this
announcement,
but
the
broker
sites
essentially
has
if
it
wants
to
do
if
it
wants
to
keep
at
least
as
it
does
that
as
a
broker
side
level,
you
know
trying
to
create
an
extra
kind
of
type
of
entity,
relationship
between
the
broker
and
the
actual
booking
platform.
F
F
G
C
E
I
actually
I,
actually
wonder
whether
it's
it's
actually
easier
to
implement
the
basket
option
of
the
two,
because
if
you've
only
got
one
item
to
persist
and
then
you're
effectively
adding
a
payment
to
that
item
that
that's
probably
easier
than
persisting
lots
of
leases
and
then
collecting
them
together
at
the
end,
which
has
got
two
bits.
But
sorry
look
Jamie
that
wasn't
was.
E
A
I,
don't
think
the
design
changes
at
the
endpoint
of
the
with
the
workflow
it
just
it's
just
really
what
we're
the
state,
where
some
of
the
state
is
being
held
in
the
middle
and
with
the
collection
of
leases
the
client
is
holding
the
state.
The
connection
between
is
that
is
this
user
and
these
leases,
whereas
a
shopping
cart
is
on
the
server
side
really,
but
otherwise
it's
pretty
much
the
same
amount
of
information.
A
The
one
thing
I
know
about
shopping
cart
thing
is
that
if
we
take
the
approach
that
every
time
a
user
adds
something
the
leases
are
extended,
then
it
kind
of
creates
a
way
for
somebody
to
create
an
infinite
lease
on
the
first
thing
in
the
cart,
so
you'd
have
to
be
still
have
to
enclose-
probably
some
timeouts
on
things.
How
long
they've
been
in
the
cart.
C
Yes,
just
to
just
a
few
things
on
this,
certainly
my
recollection
from
the
workshop
that
we
had
was
there
was.
There
was
certainly
a
recognition
that
long
term.
We
would
need
to
have
some
sort
of
notion
of
a
shopping
basket,
but
for
v1
the
goal
really
was
for
us
to
have
a
single
booking
being
May
least
and
booked
with
us.
With
this
few
calls
as
possible
I
think
long
term.
There
is
no
debate
about
the
fact
that
we
need
to
go
down
the
route
of
a
shopping
basket.
C
C
We
have
a
a
pre
mask,
commit
check
to
make
sure
that
the
leases
are
still
valid.
Once
a
payment
has
been
added
to
the
basket
to
a
try
to
regain
a
lease
if
it
has
expired
and
if
it
can't
regain
at
least
then
it
won't
do
the
basket
commit
at
that
stage.
You
then
need
to
do
some
other
stuff
I
pick
another
another
facility
or
do
something
with
the
payment.
C
But
going
back
to
the
point
which
I
was
going
to
make
was
I
personally
think
that
for
the
for
version,
one
of
this
we
should
be
focusing
on
it
as
a
single
booking
that
we're
going
to
be
making
and
I
think
that
we
should
make
that
as
simple
as
possible.
So
I
would
say
there
should
be
a
lease
and
then
a
book
operation.
C
The
the
actual
implementation
behind-the-scenes
could
well
be
create
a
shopping
basket,
add
an
item
into
the
shopping
basket
with
the
lease,
and
then
the
book
operation
pays
for
that
basket.
I
just
think
we
need
to
be
mindful
of
the
of
the
actual
booking
workshop
outcome,
which
was
we
need
to
keep
v1
as
simple
as
possible.
So.
E
G
Although
we
we
have
a,
we
have
a
shopping
basket
that
that
you
can
do
a
single
payment
and
it'll
split
the
payment
across
the
providers
within
shopping
basket
or
something
that
works
across
a
shop.
The
shop
function
on
that,
but
that
thought
makes
me
think
that
actually,
the
brokers
are
therefore
gonna
have
to
run
its
own
version
of
the
shopping
basket
anyway.
E
Well,
so
this
is
an
experiment,
maybe
the
last
couple
of
points
on
this
a
month
all
the
time
but
I'm,
the
that's,
that's
definitely
the
Spago
one
of
the
Spokeo
requirements,
I
think
we
talked
about
this
legend
workshop
was
to
have
the
option
to
book
across
different
providers.
I
don't
think
in
reality.
E
That
is
basically
but
but
it's
definitely
good
to
bring
that
up
for
sure,
because
it's
it's
worth
considering.
A
So
can
I
suggest
we
either
continue
this
in
the
comments
on
the
dock
or
on
the
mailing
lists,
and
we
have
because
we're
kind
of
running
out
of
time.
Yeah
I
think
there
might
actually
be
a
halfway
house
between
these
two
options
as
well,
depending
on
how
we
shake
the
API,
but
so
I'll
just
send
emails.
The
list
yeah.
E
If
we've
got
any
personal
details
associated
with
that,
and
that's
something
that
we'll
be
interested
to
hear
your
thoughts
on
whether
that
so
use
case,
you
would
even
think
about
supporting
or
do
you
need
any
personal
details,
because
obviously
it's
open
to
abuse
you'll
see
that
that's
the
issue
3
on
the
doctor,
so
gonna
be
shared
around
and
then
we've
already
talked
about
this
zero
offer
thing.
We've
concluded
that
so
that's
great
and
then.
Finally,
the
persistent
audit
versus
reservation,
there's
there's
a
bit
of
a
kind
of
bike.
E
Sharing
conversation
happening
up
here
in
issue
one
but
I
think
that
might
be
shaped
somewhat
by
the
outcome
of
the
last
conversation
we
had
anyway.
So
please
do
yet
send
you
will
get
your
thoughts
into
a
comments
on
this
dark
or
am
also
around
ministers
as
Lee
suggested,
and
we
can.
We
can
pick
it
up
in
the
next
call.
If
there's
any
any
more
I
think
I
think
that,
just
to
conclude
the
this,
we're
going
to
look
to
get
a
null
point
naught
point
two
or
more
point
three.
E
So
at
least
this
version
would
be
something
that
can
be
implemented
now
and
then,
as
we
want
to
expand
on
it.
Whether
we
create
an
array
of
items
for
the
shopping
basket
and-
and
you
know
start
to
post
in
additional
items
or,
however,
you
want
to
do
it-
you
can
can
expand
on
that
in
the
different
various
different
directions,
and
that's
that's
really
all
it
does.
E
A
book
is
a
patch
and
a
patch
to
add
a
invoice
to
that
and
again
you
can
kind
of
look
at
that,
but
that's
again
using
all
scheme
dog
semantics,
nothing,
nothing
particular
in
that
list.
It's
all
it's
all
straight
from
schema.
So
again,
any
comments,
we'll
I'll
make
sure
that
the
version
that
we
released
today
has
mandates
a
patch
in
order
to
confirm
the
booking
for
a
free
free
session,
as
was
brought
up
earlier.
That's
one
of
the
changes
we'll
make
anything
else
on
this
before
we.
A
A
So
obviously
the
work
on
this
document.
This
documentation
is
going
to
happen
ongoing,
but
in
terms
of
what
I
was
proposing
that
we
discuss
in
the
next
next
check-in.
So
on
the
28th
of
feb
1
D
2
description
around
making
opportunities,
data
bookable,
so
there's
some
stuff
in
the
draft
spec
around.
What's
the
minimum
required,
but
I
think
that
it's
just
largely
about
talking
into
the
work
flow
I
think
there
might
be
some
other
requirements
that
we
want
to
start
basing
on
publishers
to
ensure
the
opportunity.
A
Data
is
properly
described
well
enough
to
engage
users
and,
along
with
that,
I
want
to
have
a
discussion
around
kind
of
validation
to
help
kind
of
published,
and
then
following
that,
as
I
said
at
the
start,
at
the
call
I
think
we'll
have
some
useful
feedback
from
early
implementations.
So
we
can
use
that
bezerk.
There's
a
kind
of
useful
check
point
on
some
of
this
early
experimentation.
A
Make
sure
that
we're
going
in
the
right
direction
and
see
where
we're
at
with
the
spec
at
that
point,
so
that
was
it
so
yeah
we
can
wrap
up
now
so,
as
I'll
send
around
the
slides,
it's
got
links
to
all
the
documentation
in
it,
as
always,
if
be
good,
to
get
more
people
attending
these
calls.
Please
share
what
we're
doing
and
in
weeks.
E
To
discuss
them
over
the
Google
Doc,
just
just
to
put
the
comments
in
the
Google
Doc.
That's
way,
the
best
thing,
yeah
I
guess,
there's
always
gonna
be
irrelevant
place
regions.
There
are
three
issues
that
are
there.
That
we
talked
about
are
all
in
doc.
Each
of
them
is
an
issue
specifically
an
issue
area,
Oh
No,
yeah
yeah.
Exactly
so.
If
you
exactly
that,
so,
if
you
look
in
the
color
box,
you
can
just
add
to
that
either.
E
Well,
so
yeah
so
either
add
to
the
C
here
either
either
add
to
the
pros
and
cons
list.
This
is
just
a
wiki
style
thing
or
just
kind
of
highlight
here
and
press
comment
on
it
and
then
just
add
a
comment
to
either
side,
and
it's
quite
good
actually
because
you
gives
time
for
reflection
as
well.
So
it's
that's
kind
of
a
quick
back
and
forth.