►
From YouTube: OpenActive W3C Community Group Meeting / 2018-01-31
Description
A public hangout for members of the OpenActive W3C Community Group.
Agenda: https://lists.w3.org/Archives/Public/public-openactive/2018Jan/0004.html
For more information visit: https://www.openactive.io/w3c-community-group.html
A
A
Just
summarize
what
we
discussed
some
of
the
requirements
and
roadmap
items
that
came
out
of
that
I
wanted
to
do
that
in
this
call,
because
it
give
an
opportunity
for
those
of
you
who
weren't
there
a
chance
to
hear
more
about
what
went
on
and
give
your
input
if
you
have
any
and
just
to
kind
of
summarize
what
what
I
think
the
next
steps
are
the.
So
we
may
not
need
the
whole
era,
it
depends
on
which
detail
we
want
to
get
into
on
specific
items.
A
A
Yeah,
okay,
so
just
kind
of
recap:
what
the
the
goals.
A
A
But
the
the
goals
for
the
workshop
were
to
share
some
of
the
work
that
the
ADI
had
been
doing.
So
we
could
get
modern,
shared
understanding
across
the
community
about
what
the
current
state
is
and
booking
api's
start
to
get
more
detailed
requirements
from
both
of
platforms
and
data
users
who,
in
the
room
we
at
the
you
know
the
work
we've
been
doing
in
the
open
active
program.
A
We've
had
a
reasonable
sense
of
the
kind
of
requirements
and
direction
that
we
would
need
to
go
in,
but
we
wanted
to
validate
that
with
feedback
from
the
community
and
I
think.
Most
importantly,
we
wants
to
make
sure
that
there
was
introduced
an
appetite
in
the
community
actually
moving
this
forward
and
that
we
had
a
kind
of
common
view
of
what
a
booking
API
should
look
like
and
a
sense
of
what
the
roadmap
would
be.
Because
for
this
to
be
successful,
we
can't
just
impose
those
this
on
on
the
secretary.
A
A
We
know
that
there
are
projects
going
on
between
individual
organizations
in
sector
to
start
to
build
out
api's
to
support
booking,
but
also
that
there
was
a
some
people
who
just
wanted
to
want
to
know
how
to
move
forward
that
they're
keen
to
offer
an
API
but
weren't
sure
that
the
best
way
to
go
about
it.
So
we've
got
countries
called
mixed
economy
of
people
at
different
stages
and
implementation,
and
we
need
to,
as
a
program
was
a
bit
up
to
program.
A
So
this
is
recognizing
that
some
platforms
may
not
be
a
point
in
the
roadmap
where
they
can
prioritize
this,
and
you
know
there
may
be
Airy
things
that
you
need
to
work
on,
but
anything
they
can
do
in
order
to
make
these
apos
more
accessible,
more
useful
will
help
them
participate
in
active,
but
obviously
we
also
need
to
quickly
get
to
a
recommended
design
for
the
API.
So
we'll
you
know
something
that
we
can
design
within
the
scope
of
those
best
practices.
A
So
that's
kind
of
our
direction
and
what
we
wants
to
get
from
the
workshop
is
feedback
on
that
get
people
to
surface
their
thoughts
and
ideas
about
what
they
think
the
best
approach
was
or
where
they
thought
there
were
particular
challenges
or
issues
that
we
need
to
address
and
start
to
get
into
some
of
the
more
detailed
requirements
that
would
support
the
the
API
design.
So
we
we
organized
a
workshop
in
kind
of
two
halves.
We
had
an
issue.
A
We
had
discussion
to
try
and
surface
some
of
that
there's
different
viewpoints
and
then
add
some
practical
exercises
to
pull
out
within
requirements
and
roadmap.
So
I'm
just
going
to
kind
of
briefly
summarize
those
the
next
next
few
slides
and
if
you've
got
any
questions
or
comments,
then
then
then
jump
in
as
go
through.
Just
listening
to
me.
Talk
so
I've
tried
to
in
the
report.
I've
tried
to
capture
as
many
of
the
different
discussion
points
and
requirements
as
as
possible.
A
We
generated
a
post-it
notes
over
the
course
of
the
morning,
but
I've
just
pulled
out
what
I
think
are
some
of
the
key
themes
and
requirements
from
that
discussion.
Just
to
kind
of
review
you
this
afternoon,
so
it
was
quite
a
quite
wide-ranging
discussion,
but
I
think
we
managed
to
converge
on
a
kind
of
general
sense
of
direction.
We
touched
on
quite
a
few
different
perspectives,
so
one
thing
that
came
through
was
that
the
existing
opportunity
data
needs
me
to
be
improved
in
order
to
support
booking
news
cases.
A
Livan
was
there
that
think
it's
important
thing
about
the
developer.
Experience
make
sure
that
we've
got
good
documentation
and
support
for
developers
who
are
building
both
building
api's,
but
also
building
against
them.
So
we
need
some
decent
test
cases.
We
need
test
harnesses,
so
people
can
build
their
client
libraries
or
make
against
known
systems
known
data,
but
also
thinking
about
what
the
onboarding
experience
is
like.
If
getting
a
new
third
party
up
and
running
to
use
the
booking
API
is
for
a
particular
platform
and
that
brought
a
number
of
discretion
points
around
the
commercial
arrangements.
A
What
that
onboarding
process
would
look
like
and
that
there
will
there
make
will
need
to
be
some
support
provided
in
order
to
help
third
parties
get
up
and
running
and
likely
to
be
some.
You
know
contractual
arrangements
around
used
to
those
api's
how
payments
are
handling
handles
approaches
for
reconciliation
around
those
payments,
to
make
sure
that
everyone
is
comfortable
that
you
know
all
the
due
diligence
is
in
place,
around
security
handling
of
personal
data
and
transfer
of
funds,
etc.
A
A
The
fact
that
what,
if
we're
designing
booking
for
what
I'm
calling
here
casual
users
versus
people
who
all
do
it
so
members
or
people
already
registered
with
the
platform,
the
workflows
could
look
quite
different
in
terms
of
how
user
information
is
transferred,
that
all
users
are
authenticated
and
even
how
payments
are
handled,
because
in
the
case
where
people
are
pre
registered
or
what
members?
Much
of
that
information
is
already
in
the
platform.
A
And
it
might
make
more
sense
for
the
platform
to
be
handling
that,
whereas
for
casual
users
who
are
probably
not
known
to
the
platform
and
may
be
more
comfortable
with
making
payments
elsewhere
or
be
reluctant
to
provide
a
whole
bunch
of
personal
information
up
front
and
be
quite
quite
different
and
I.
Think
what
we.
What
we
settled
on
is
that-
and
this
is
in
line
with
the
kind
of
general
objectives
of
the
open
active-
is
that
we
should
be
prioritizing
these
kind
of
casual
users.
A
It's
that
kind
of
very
simple
use
case
of
I
want
to
book
this
event
now
I'm,
not
necessarily
a
member.
It
was
already
known
to
the
platform
and
that
simplifies
I
think
a
lot
of
the
workflow.
It
simplifies
some
of
the
data
that
needs
to
be
collected
and
I
think
is
in
line
with
what
we've
heard
from
data
users
intending
to
use
these
api's
in
their
in
their
apps
and
services,
and
so
I
think
was
really
really
useful
to
have
their
discussions
a
bit
draw
like
that
kind
of
common
common
direction.
A
You
know
what
was
the
absolute
minimum
that
would
be
required
in
order
to
make
a
booking
whether
it's
to
an
event
or
facility,
but
that
versus
what
existing
platforms
collect
in
some
cases,
there's
a
there's
a
whole
raft
of
information
about
attendees
that
are
collected
for
various
reasons.
Some
of
it
I
think
might
well
be
justifiable
under
you
know,
what's
required
from
the
organizer,
some
of
it
seemed
to
be
more
about
reporting
than
kind
of
tracking.
A
You
know
tracking
the
usage
on
different
types
of
participation,
so
that
there's
some
there's
some
kind
of
discussions
to
be
had
there
and
I
think
what
I
took
away
is
that
the
probably
is
a
like
the
minimum
set,
but
we
just
need
data
that
will
help
support
the
use
case
and
we
just
need
to
get
to
a
level
understanding
across
the
sector
of
what
that
is,
but
that
whatever
we
do
within
the
API
needs
to
be
extensible,
to
allow
individual
platforms
to
collect
more
information.
If
and
when
it's
useful.
A
A
So
again,
I
think
it
was
useful
to
have
that
discussion,
mm-hm,
but
I
think
what
I
took
away
again
was
that
there's
a
recognition
that
we
needed
to
start
from
the
simplest
thing
of
just
offering
a
simple
by
either
a
single
price
or
a
simple
set
of
pricing
options
that
a
third
party
can
use
to
actually
make
make
that
booking
much
of
their
complexity.
You
know
seem
to
come
spring
up
from
around
members
and
existing
users
of
platforms,
which
we
do
kind
of
already
put
on
the
list
of
priorities.
A
There's
lots
of
complexity,
around
kind
of
upsells
other
options
which
could
be
included
later,
but
is
probably
not
on
the
critical
path
for
getting
something
done,
and
so,
when
we
got
into
the
requirements
again,
there's
a
lot
more
detail
in
the
write-up
I'll
circulate,
but
I
think.
The
key
things
that
I
wanted
to
get
out
of
that
discussion
was
a
sense
of
what
the.
A
The
other
thing
that
was
important
was
agreement
that
separating
the
booking
from
from
payment
handling
was
probably
the
best
way
to
go.
So
long
as
there
was
some.
You
know
there
was
a
clear
process
for
how
funds
will
lend
transferred
from
their
parcel
to
the
to
the
platform
and
whatever
kind
of
reconciliation
need
to
happen
behind
the
scenes.
A
So,
based
on
that
I
think
we
can.
We
can.
We
can
start
to
kind
of
refine
what
the
use
cases
are
and
start
to
quickly
work
on
a
design
for
a
relatively
straightforward
API
that
will
cover
those
those
arrangements
by
moving
by
moving
payment
and
in
two
separate
set
of
API
calls
with
existing
payment
providers
and
by
simplifying
pricing.
It
does
I
think
greatly
simplified
that
what
we
actually
needs
to
be
designing.
C
Think
our
commercial
drive
at
there
in
the
first
sense
is
very
much
not
about
the
simple
opportunity
booking
requirement,
because
this
account
driven
by
our
customers
and
it's
more
about
kind
of
apps
and
extended
websites.
So
that's
just
us
and
I
do
agree
that
the
consensus
was
that
certainly
most
people,
they
were
very
keen
to
have
the
ability
to
sell
their
excess
sports
all
court
capacity
through
through
third
parties
and
more
that
than
classes
classes.
They
said
we
can
sell
those
ourselves.
We
fill
them
up,
it's
just
having
empty
rooms.
We
don't
like
so
I.
C
A
There's
a
good
point:
it's
useful
to
draw
that
I
think
we
need
to
bear
that
in
mind
as
we
move
forward
that
that
they're
kind
of
the
approach
that
we're
taking
makes
it
easier
to
layer
on
you
know
kind
of
member
based
workflows
on
top
of
what
we're
doing,
I
think
there
should
be
ways
to
do
that,
but
we
just
kind
of
need
to
be
bearing
in
mind
that
some
of
those
things
might
need
to
evolve
as
we
take
a
look
at
those
other.
Those
are
the
requirements.
D
We
may
need
to
be
revisiting,
as
you've
said
earlier,
certain
aspects
of
the
of
the
of
the
actual
opportunity
data
for
us
to
find
a
way
for
us
to
publish,
publish
opportunities
that
are
not
necessarily
a
a
a
sports
event
as
such,
because
they
there
is
that
need
for
us
to
for
us
to
notify
space.
That's
available,
you
know,
and
if
it
it
may
well
turn
out.
A
Yeah,
so
I
I'm,
not
sure
you
were
on
the
call
couple
weeks
ago,
Raymond,
but
we
did
so.
We
like
them
I,
ran
a
proposal
by
everyone
about
how
to
make
that
extension,
see
the
opportunity
model
to
deal
with
facilities,
so
I
think
there's
some
fairly
small
changes
to
both
the
paging
spec
and
the
current
data
model.
That
will
allow
us
to
do
that.
A
A
D
And
then
yeah
and
then
further
to
that
really
was
one
of
the
other
points
which
I
had
was
and
that
the
bookings
would
be
driven
by
data
that
had
been
surfaced.
Out
of
you
know,
out
of
the
actual
out
of
the
physical
opportunity
data
rather
than
just
being
a
you
can
go
and
book
something
randomly
and
it
would
offer
methods
for
you
to
find
other
other
products,
and
things
like
that.
You'd
have
to
start
off,
navigating
navigating
opportunity
data
and
using
a
reference
that
you
got
from
that
data.
D
A
Yes,
that
that's
yeah,
that's
a
good
point,
yeah
revisit
the
report
and
make
sure
that
that's
a
bit
clearer
because
I.
That
was
certainly
my
assumption,
but
I
realized
that
that's
not
you
know,
there
are
other
ways
that
you
could
have
gone,
but
I
think
that's
we're
trying
to
make
the
the
open
opportunity
data
book
able
I
think
is
the
way
that
we
should
be
framing
it.
A
A
A
You
know
events
facilities,
but
also
members,
but
what
we'll
do
is
we'll
prioritize
that
so
we're
focusing
on
the
bits
that
everyone
agreed
with
the
starting
point,
because
the
use
cases
will
help
I
think
make
sure
that
we
don't
lose
track
of
some
of
those
other
requirements
and
then
I
think
I.
Think
everyone
felt
it
was
important
to
quickly
identify
what
the
minimum
set
of
user
data
is
required
in
order
to
support
booking
that.
A
We
have
that
conversation
I
think
there's
quite
different
views
on
direction
where
that
should
go
in,
but
also
a
minimum
set
of
data
fields
that
need
to
be
in
the
opportunity
data
to
support
booking
but
also
better
discovery.
And
so
we
know,
we've
already
been
doing
a
little
bit
of
work
on
that
I
present
some
work
a
couple
of
calls
ago
where
I
was
looking
at
what
what
data
people
were
publishing
and
in
the
API
dashboard.
We
started
to
surface.
A
It's
just
another
way
to
to
help
kind
of
communicate.
What's
going
on
with
the
rest
of
the
community,
we
need
to
get
more
people
on
board
as
well,
so
engage
people
beyond
this
group
get
involved
in
providing
feedback
on
the
specifications,
but
also
being
able
to
quickly
identify
some
early
pilot
implementations.
So
again
we
know,
through
our
engagement
work,
that
there
is
some.
There
are
some
active
projects
that
are
looking
where
people
looking
to
start
integrate
different
platforms
and
systems
around
looking.
A
We
want
to
make
sure
that
we're
working
in
the
open
there
so
that
we're
sharing
any
kind
of
drafts
as
early
as
possible
to
get
as
much
feedback
as
possible
and
then
start
to
work
on
getting
some
implementation
experience
around
those
drafts.
It's
always
useful
to
have
you
know
not
just
test
cases,
but
also
real-world
code,
that
it's
time
to
test
that
these
these
api's,
you
know
in
specific
pilots
I,
think
I
gives
other
opportunities
for
people
to
provide
feedback
and
suggestive
improvements.
A
At
some
point,
we
also
need
to
get
into
some
discussion
around
where
the
extension
points
might
be.
I
think
the
only
one
that
we've
identified
so
far
is
how
we
allow
additional
user
information
to
be
captured.
So
if,
in
the
workflow
you
users
need
to
be
prompted
to
answer
a
few
more
questions
and
that's
seen
as
a
important
requirement,
then
we
need
a
way
to
communicate
that
as
part
of
the
the
kind
of
API
love
the
interaction
with
the
booking
API
then
kind
of
future,
like
everyone
was
when
we
did.
A
A
Some
platforms
would
be
more
interested
in
that
than
casual
casual
book
and
I'm
going
to
kind
of
digest.
This
I
put
together
a
Trello
document.
What
I'm
going
to
be
looking
for
next
really
is
who
wants
to
be
involved
and
how
I
think
this
is.
This
piece
of
work
is
going
to
be
stronger,
the
more
the
more
input
and
involvement
we
have
from
the
community,
both
in
terms
of
shaping
up
the
design
if
the
API
is,
but
also
in
getting
into
developing
prototypes
and
pilots.
E
So
our
parks,
good
Jim
thanks
so
yeah.
That's
that's
kind
of
an
initial
implementation
of
something
don't
know
what
that
is
yet
I
guess
it
were
very
much
and
on
this
initial
drafting
process,
what
what
the
kind
of
MVP
of
cooking
looks
like
so
that
all
these
different
people
can
implement
some
end
point
or
end
points
to
allow
this
functionality
to
work
and
then
weak
in
the
hole.
The
time
scale
is
about
a
pretty
tight.
Those
implementations
are
happening
by
the
end
of
this
month.
E
F
E
Latest
is
that
we,
where
we're
trying
to
figure
out
the
best
way
of
getting
the
data
confusion
in
the
format
that
we
needed
to
be
in
which
conforms
to
the
spec
that
Lee
was
talking
about
last
time,
so
we've
got
kind
of
a
rough
plan
to
do
that,
and
now
it's
just
a
case
of
executing
that.
So
you
can
pick
up
the
detail
if
you're
interested
in
being
kind
of
getting
all
of
the
data
when
it
comes
out.
E
E
C
Not
be
the
first
drop
first,
the
first
intent
we've
got,
which
is
strong
demand
for
markers.
A
particular
group
of
five.
The
gang
of
five
which
you
saw
last
week,
is
very
much
about
member
bookings
in
websites
and
in
apps,
and
then
the
stage
after
that.
That
would
actually
provide
us
with
the
essential
functionality,
give
it
to
some
tweaks
and
when
you
are
the
opportunity
feed
to
be
able
to
do
the
third
party
bookings.
C
So
we
do
have
some
thinking
to
do
about
the
opportunity
feed,
because
one
thing
we
found
was
with
our
biggest
customer
and
there
are
20,000
changes
to
the
class
record
or
records
at
Loretto
classes
in
half
a
day.
So
you
can
imagine
the
kind
of
resource
overhead
that's
going
to
give
us.
So
we
need
to
think
quite
carefully
about
what
we
actually
want
to
track
on
that
so
needs
a
bit
of
analysis
before
we
can
start
think
through
the
implications
that
oh,
it's
a
problem
with
having
a
mature
sit
and
complex
and
very
sophisticated
system.
E
E
C
Let's
say
yes
and
no
I
think
we
possible
to
emulate
that
effectively
yeah,
but
we'd
probably
want
to
think
about
making
a
distinction
there.
So
we
I
mean
it
would
be
a
few
days
work
to
kind
of
make
that
a
specific
thing
saying
it
does
this
third
party
member
exists
yeah
and
then,
if
not
create
them
and
put
the
back
into
that
there's
this
you
know,
we've
got
all
the
tools
for
that.
C
It's
just
a
question
of
doing
that,
but
just
to
set
expectations,
I
mean
we're
looking
at
me
now
to
deliver
at
least
the
technology
for
pilots
to
our
customers,
our
customers
and
their
integrators
in
the
next
eight
weeks.
I
would
not
expect
to
have
a
feed
in
that
time,
for
it.
Okay
and
I
need
to
kind
of
go
through
with
my
superiors
to
work
out
when
that's
going
to
happen
and
therefore
put
into
it,
but
firstly,
to
find
out
how
much
effort
that
is,
you
know
how
it
goes.
We
are
not
masters
around
distantly.
E
C
E
C
Will
will
have
an
API
which
can
certainly
provide
a
framework
for
doing
things
like
that
and
they're
practically
API,
with
some
with
the
start
of
people
using
it
and
implementing
it
again.
Get
experience
with
it,
and
we've
got
something
like
three
four
five
participants
for
that.
So
hopefully
that
will
give
us
a
practical
experience
and
they
can
come
back
to
was
rubbish
and
so
great
train.
E
A
Okay,
so
that
that
kind
of
covers
what
I
wants
to
just
review
with
everyone
today,
I've
if
you've
got
just
no
comments
and
FEMA
then
jump
in.
But
one
thing
I
wanted
to
ask
you
about
was
the
how
we,
how
we
what's
the
best
way
for
us
to
start
to
produce
drafts
of
the
api's.
So
we
think
the
standards
that
we
produced
so
far
we
producing
those
in
a
kind
of
formal
web
template.
A
A
C
Now
that's
in
a
swagger
environment
at
the
moment
and
I'm
not
suggesting
that
that
becomes
the
template
for
the
booking,
API
I'm,
just
suggesting
that
I'm
quite
happy
to
put
that
out
there
and
anyone
else.
Of
course,
we've
got
some
ones
like
that
can
do
so
to
provide
a
point
around
which
we
can
try
and
accrete
or
move
away
from,
but
I'm
not
going
to
give
25
people
access
to
a
swagger
system
because
it'll
cost
a
fortune,
so
I
mean
I,
don't
if
we
can
produce
that
as
a
as
a
as
a
Word
document.
C
A
I
knew
you'd
mentioned
swagger
at
the
workshop,
and
that
was
a
member
of
my
other
suggestion
is
that
you
know
we
use
a
shared
Google
Doc
for
just
very
early
drafting,
and
then
we
switch
to
a
kind
of
a
formal
specification
template
because
that's
kind
of
what
we
need
to
reduce
the
w3c
group
which
we've
got
to
a
stable,
but
that
we
also
create
new
ideas,
swagger
or
something
similar
to
create
a
set.
The
version
of
the
API
specs
that
are
easy
for
developers
to
kind
of
navigate
and
use
okay.
So.
C
I
think
we
can
probably,
if
you
have
a
swagger
account,
you
can
give
us
all
access
to
I
think
we
can't
think
it'd
have
multiple
api's
in
it.
So
I'm
quite
happy
to
I'm
sure
there's
some
way
of
copying
that
onto
the
the
legend
account
and
so
the
ODI
account,
and
if
there
is
then
we
can
just
do
that
and
say.
Here's
a
snapchat
point
in
time,
I'm
happy
to
get
comments
back:
okay,
okay,.
E
C
Okay,
that's
interesting
I
need
to
think
about
that
because
I
don't
mind
sharing
where
we
are,
which
is
unfinished
with
a
group
of
geeky
people
and
customers,
but
I,
don't
particularly
want
to
discuss
the
world
for,
for
a
whole
variety
of
reasons.
Yeah,
it's
very
early
days
for
us
yet
so
I'm
not
particularly
keen
on
that
to
be
honest,
but
if
we
can
find
some
way
of
sharing
within
the
open
active
group
that
we
delighted.
A
A
Okay,
but
so
people
broadly
happy
with
just
using
Google
Docs
as
a
there's,
a
first
point
of
reference,
yep
yeah
right
all
right.
Well,
we'll
do
that
then
I
mean
some
of
the
the
best
practice,
guidance,
etc
is
already
in
Google
Docs.
So
we're
probably
gonna
share
it
like
that
for
convenience
to
begin
with,
but
I'll
probably
transfer
about
I.
A
Good,
okay,
anyone
I've
got
anything
else
they
wanted
to
raise
on
the
call
today,
No.
Okay,
in
that
case
I'm,
probably
winders
up
in
terms
of
the
next
calls
and
I'm
going
to
circulate
an
updated
schedule
for
over
the
next
few
weeks.
A
What
I'm
proposing
is
that
we
we
focus
probably
for
the
next
two
or
three
months
purely
on
facilities
and
booking,
to
make
sure
that
that
moves
forward
the
pace
that
everyone
is
happy
with,
just
so
that
yeah
just
so
much
for
them
and
actually
got
to
get
some
useful
milestones
so
I'll
put
together
I
was
going
to
call
schedule
around
that,
but
the
one
that
we
will
be
having
in
two
weeks
time
what
I'd
like
to
be
doing.
There
is
actually
look
started
to
look
at
some
drafts
of
endpoints.
A
E
A
A
Great
some
documentation
not
actually
gonna,
do
not
going
to
do
a
reference
implementation
yet
because
it's
really
I
think
just
start
to
transfer
that
thinking
of
okay,
we're
gonna
have
to
face
neat.
Look
exactly
going
to
look
in
terms
of
some
some
end
points
we
can
have
debates
around
naming
and
what
the
paths
look
like
and
formats,
but
at
least
start
to
look
at
what
what
the
workflow
is
going
to
be,
and
so
we
can
get
a
better
sense
of
what
what
data
we
need.
I
guess.
E
C
On
that,
I
was
just
going
to
say:
we've
got
a,
we
included
the
best
practices
comments
and
they
think
about
you,
giving
us
in
the
latest
swagger
implementation,
and
it's
been
four
helpful
that
she's.
So
thank
you.
It's
the
first
thing
to
say,
but
if
you
cover
to
the
look
at
that
and
just
see
any
of
the
feedback
you
want
to
give
us
that'd
be
great.
Absolutely.