►
From YouTube: OpenActive W3C Community Call / 2020-11-04
Description
Documentation Review
- Standards
- Developer.openactive.io
- GitHub repositories
- Open booking SDK
A
A
A
A
A
A
And
the
point
of
the
grand
unified
theory
of
documentation
is
really
to
divide
up
documentation
into
four
separate
types.
I
think
this
is
pretty
frequently
used
in
in
software
development,
so
you've
got
the
idea
of
essentially
learning
oriented,
tutorials
problem.
Solving
how-to
guides
reference
documentation,
so
yeah
where
you
just
look
up
stuff
very
quickly
and
then
explanation,
which
is
the
wider
contextual
piece
and
reviewing
all
of
our
documentation.
A
A
Is
that
a
fair
summary
of
what
we've
got
right
now
on
the
ground
and
I
feel
like
nick's,
had
a
hand
in
nick
has
commented
to
comp
is,
is
qualified
to
comment
because
he's
written
so
much
of
the
documentation
and
nathan
is
qualified
to
comment
because
he's
presumably
read
so
much
of
it
and
had
to
wade
through
it.
So
we've
got
both
ends
of
the
equation
here.
B
Yeah
sure
I
can
pick
this
up,
so
I
do
I'd
not
heard
of
the
grand
unified
theory
of
documentation
before,
but
I
do
like
the
approach.
It
seems
fairly
sensible
that
does
kind
of
gel
up
with
a
lot
of
the
problems
that
we
had
when
we
were
implementing
it,
and
we
started
with
for
reference,
which
I
think
was
a
mistake.
B
So
we
essentially
started
from
the
specifications
and
then
built
things
out
from
there,
and
that
meant
that
we
missed
a
few
things
that
weren't
in
the
parts
of
the
specification
that
we
were
reading,
but
were
in
other
parts
or
would
have
been
in
kind
of
like
a
more
top-down
level
like
tutorial
or
explanation
about.
What's
going
on,
I
feel
like
if
there
was
come
some
kind
of
step-by-step
on
how
to
be
able
to
feed,
especially
the
bookings,
feed
kind
of
from
the
ground
up.
B
That
would
be
very
helpful
for
new
people
implementing
system.
I
think
it
would
also
be
quite
helpful
to
have
a
separate
tutorial
for
people
who
are
consuming
the
feed.
Obviously,
that
fee
about
tutorial
is
a
lot
simpler,
because
consuming
is
a
lot
simpler,
especially
with
vrpte
foods,
but
just
some
kind
of
like
common
pitfalls
and
things.
You
can
notify
a
lot
easier
in
a
tutorial
aspect
than
you
can
in
the
specification.
Just
by
saying
your
implementation
should
do
this.
For
example,.
A
Yeah-
and
I
think
I
think
sometimes
we
have
jammed
kind
of
specific
problems,
we've
run
into
into
the
how
to's
or
into
the
references
and
sometimes
that
makes
it
a
little
bit
confusing.
That
there'll
be
a
sort
of
note
attached
to
one
of
the
specification
cells
saying
you
know
never
do
this
and
it's
you
know
it's
unclear
what
particularly
motivated
that
particular
comment.
But
nick
do
you
have
any
reflections
on
that.
C
Yeah
that
sounds
yeah.
I
agree
with
that.
I
think
we,
funnily
enough,
unsurprisingly,
starts
down
with
the
ground
unified
theory
of
documentation
when
initially
kind
of
doing
the
docs
way
back
when
and
so
yeah.
Definitely
that
that's
a
good,
that's
a
good
point.
Those
gaps
definitely
exist.
From
my
perspective,
there's
like
a
big
list
of
documents.
We
should
probably
have
that
I've
kind
of
been
like
have
been
in
my
head
for
a
while
at
least,
and
I
haven't.
I
don't
think,
we've
really
translated
that
into
well.
C
It's
been
on
the
on,
like
a
what's
been
required
for
basis
like
a
lot
of
the
documentation,
is
kind
of
sprung
up
in
response
to
demand.
So
there
was
a
period
of
time
and
kind
of
still
doing
this.
Really,
when
some
question
comes
up,
I
try
to
answer
it
with
documentation
rather
than
just
a
direct
email
and
that's
what
has
created
some
of
the
kind
of
more
specific
documentation
around
areas
where
and
and
as
implementations
have
kind
of
come
along,
then
filling
that
out
further.
C
So,
for
example,
the
activity
list
documentation
is
now
really
detailed
because
we
had
so
many
people
implementing
the
activity
list
and
problems
that
came
out
of
it.
The
libraries
that
were
related
to
all
that
stuff-
and
I
think
that
even
includes
a
video
of
someone's
implementation,
includes
screenshots
of
someone
else's
implementation.
It
includes
all
the
different
ways
that
you
could
do
that
thing.
So
the
activity
list
section,
I
think,
is
probably
one
of
the
better
documented
sections
of
of
all
the
documents
that
we've
got
and
yeah.
C
It's
accurate
and
it's
got
relevant
examples,
etc.
So
so
that's
great
from
reference
from
that
point
of
view,
but
we
don't
really
have
something
similar
from
the
booking
specs
kind
of
end
points.
For
example,
you
could
imagine
having
a
page
per
endpoint
with
kind
of
detail
about
what
kind
of
things
that
you
would
expect
to
have
to
implement
to
do
that
and
then,
like,
I
said,
linking
off
to
other
things.
C
C
What's
that
checking
rate,
what
the
error
conditions
are
there,
so,
obviously,
not
everyone's
going
to
want
to
read
the
dot
net
code
base
to
figure
that
out,
but
maybe
there's
an
opportunity
to
to
pull
some
of
that
stuff
out
when
that
implementation
is
done
and
and
make
it
a
bit
prettier
and-
and
I
guess
add
some
of
the
explanation
in
there
as
well
there's
a
lot
of
that
is
in
the
comments
in
the
dot
network
as
well.
But
why
is
this
there?
C
You
know
what
what's
the
rationale
for
certain
types
of
things
so
yeah,
so
I
think
yeah.
I
think
we
maybe
have
like
40
of
the
surface
area
of
documentation.
We
probably
ideally
need
to
remove
any
consultative
process.
I
think
the
current
way
it's
set
up,
because
we
now
have
a
test
suite.
I
think
you're,
probably
gonna,
have
a
situation
where
people
are
kind
of
getting
failing
tests.
C
I'm
getting
a
few
of
these
questions
from
from
some
of
the
influencers
from
the
pilot,
who
are
still
going
actually
like
kind
of
getting
a
failing
test
and
going.
Why
is
this
failing?
You
know
and
then
having
to
have
the
conversation
about?
Why
that's
failing,
because
this
is
the
reason
for
blah
and
obviously
yeah
so
spec
plus
test
suite,
probably
gets
you
to
a
working
implementation
ish,
but
yeah
it'd
be
better
to
do
it.
C
Yeah
I
mean
I,
I
was
implementing
something
to
do
with
oauth
for
the
for
the
test
suite
today
and
obviously
oauth
another
standard.
It's
got
a
lot
of
documents
around
it
and
that
exists.
So
we're
not
the
test.
We
isn't
testing
oauth.
It's
testing
that
the
thing
has
it
was,
which
is
a
nice
level
up
to
be
testing,
especially
when
all
the
tooling
exists
for
that.
But
it's
interesting.
C
It
struck
me
when
looking
at
the
airwolf
docks
that
actually
yeah
there's
a
lot
of
really
easy,
getting
started
like
copy
paste
this
bit
of
code
in
and
this
bit
of
code
in
this,
and
then
you
get
that
and
a
lot
of
the
time
when
I've
been
looking
for
issues
on
the
oauth
documentation,
because
it's
like
basically
reading
specs
and
other
people's
guidance
on
it.
It's
been.
It's
been
interesting
to
to
get
that
kind
of
contrast
where
you've
got
an
easy
kind
of
copy
paste
stuff
in.
A
So,
just
so
just
to
just
to
rewind
a
bit
there,
because
we've
got
quite
detailed
there
and
I
think
I
think
that's
already
where
the
center
of
gravity
is
on
our
on
our
documentation
and
yeah.
Obviously,
leveraging
well-written
nicely
refactored
code
into
into
documentation
is
a
great
place
to
start,
but
it's
looking
at
a
lot
of
detail
there.
A
So
if
you
started,
I
guess
when
you
say
back
in
the
day,
that
means
with
with
lee
and
yourself
when
you
started
thinking
about
documentation
in
that
grand
unified
theory
way.
Was
there
a
particular
reason
why
explanation
and
tutorial
got
a
little
bit
sidelined
or
was
it
just
a
natural
evolution
that
that's
how
it
turned
out.
C
We
started
with
a
backlog
of
all
the
with
with
ideas
of
things.
There's
someone
brilliant
a
lady
called
sally
who
was
involved
as
well,
who
wrote
some
of
it
and
we
had
yeah.
I
think
I
think
I
think
we
focused
on
reference
to
start
with
just
because
that
was
essential
and
try
to
get
the
kind
of
the
core
in
there,
but
the
yeah
the
reality
is
we
just
never
resourced
this
properly,
and
I
mean
this
is
talking
from
the
point
of
view
of
the
odi
project
it
was.
It
was.
C
C
So
if
you
like
start
start
with
the
grand
unified
theories,
we
all
understand
what
we're
doing
and
then
just
ad
hoc
do
the
stuff
we
can
do
to
make
it
slowly
more
like
that
yeah
and
therefore
it's
entirely
demand
driven,
which
starts
with
which
then
results
in
what
we've
got
right
now,
yeah,
okay,
fair
enough,
there's
been
a
couple
of
times
when
one
major
implementer
has
started
the
journey
and
I've
got
I've
got
to
the
point
of
going.
Oh,
my
goodness!
C
This
is
a
perfect
time
when
you
know
they're
about
to
embark
on
having
never
looked
at
it.
We
could
literally
think
from
their
perspective.
What
docs
do
they
need
and
try
and
service
them
through
that
that
that
journey,
but
just
time
constraints
it's
never
materialized
like
it
would
be,
for
example,
if
you
think
about
someone
coming
in
like
fit
fit
solo.
C
If
it's
remember
their
names
but
yeah
the
folks
from
emd
that
we're
going
to
do
we're
going
to
do
a
bunch
of
stuff
with
virtual,
but
it
never
really
came
off,
but
when
they
were
looking
at,
it
was
kind
of
an
obvious
thing
that
they'd
started
from
from
the
very
beginning:
no
open
active
knowledge
at
all,
and
you
could
easily
see
there
that
they
were
asking
some
of
the
very
basic
questions
that
everyone
asks.
You
know
I've
got
events
in
this
shape.
How
do
they
fit
within
your
format?
C
I
mean,
if
you're,
not
if
you're,
not
if
you're
down
facilities-
and
you
have
events
then
there's
a
very
specific
kind
of
decision
tree
you
go
through
where
you
start
off
with
I've
got
events
and
you
decide
whether
they're
session
series
and
scheduled
sessions
or
are
they
events?
Are
they
and
then
their
courses?
And
then
you
understand
all
the
options
over
those
feeds
and
then
the
challenges
around?
Do
I
use
schedules,
or
do
I
not
so?
Yes,
so
there's
a
question
of
partial
schedules
versus
schedules.
C
There's
a
question
of
how
do
I
do.
I
have
a
url
that
I
can
point
to
for
each
page
and
what
does
it?
What
does
an
event
represent
in
my
system
to
my
users,
where,
where
are
the
prices
and
how
they
set
adult
junior
et
cetera?
So
you
go
through
all
these
questions
about
how
that
what
does
that
look
like
and
then
yeah,
and
then
they
usually
come
up
with
the
feeds
and
then
there's
there's
kind
of
further
questions.
How
does
the
activity
list
work?
C
What's
the
value
of
that
you
know,
I've
got
I've
got
some
data
that
doesn't
fit
with
the
model.
Where
do
I
put
that?
Do
I
leave
it
out?
Do
I
keep
it
in?
Obviously
we
want
to
keep
it
in
so
then
you
start
explaining
the
beta
properties
and
how
that
works,
and
all
this
stuff
is
in
reference
implementation,
but
you
could,
you
could
easily
see
that
is
in
sorry
in
the
reference
documentation
like
how
does
beta
work
etcetera,
but
you
could
easily
see
a
flow
there
through.
C
You
know
from
zero
to
decision
tree
of
what
have
I
got,
and
how
do
I
implement
that
through
to
okay?
Now
I
know
which
you
know
what
what
kind
of
event
structure
I'm
going
to
use
and
how
match
goes
to
my
database.
This
is
where
how
I'm
going
to
link
the
activity
list
in
this
is
where
I'm
going
to
put
the
detail
on
the
other
fields
yeah
and
then
obviously
through
to
booking.
C
A
So
the
the
the
gut
kind
of
idea
of
what
a
tutorial
is
is
that
it's
really
handholding
that
it's
not
sort
of
I've
got
this
data.
How
do
I
shape
it?
It's
like.
Let's
pretend
you
have
this
data
and
you
need
to
get
all
the
way
through
right,
so
it
really
is
like
if
you
type
all
the
keystrokes
that
are
on
the
page
in
front
of
you
or
in
the
video
in
front
of
you.
You
know
you
will
get
to
that
end
point.
It's
rare!
It's
very,
very
hands-on!.
B
A
A
A
C
B
A
B
B
A
B
B
I
I
remember
when
I
was
looking
into
the
rpd
feeds,
you
got
some
sequel
examples
of
how
to
pull
out
a
specific
page,
so
something
like
that
would
be
helpful,
but
I
kind
of
feel
like
you.
Don't
really
need
to
worry
yourself
too
much
about
what
the
dobos
scheme
is
going
to
be
because
everyone's
going
to
be
different
and
it's
probably
going
to
be
attaching
it
to
an
existing
scheme.
So
just
kind
of
a
general
example
of
what
kind
of
query
you
need
to
write
should
be
enough.
A
Yeah
I've
been
surprised
by
the
number
of
questions
I've
had
that
have
been
a
bit
like.
I
have
a
lot
of
tables
where's
my
data
and
I'm
I'm
left
a
bit
like
well
yeah,
but
yeah.
I
suppose
a
very
simplified
kind
of
idealized
sql
representation
should
should
cover,
should
be
legible
to
most
developers.
I
suppose
yeah.
A
B
C
Although
it
might
be
worth
having
a
how-to
related
to
that
on
the
benefits
of
materializing
data
and
caching,
it
in
a
table
versus
using
a
join
because
of
performance-
and
you
could
you
could
cite
different
examples
where
this
is
back
to
the
decision
tree.
How
do
I
structure
where
I
store
my
data
pros
and
cons.
C
Of
issue,
but
yeah
sorry,
that's
definitely
how
to,
but
I'm
just
thinking
like
that's
where
you
link
off
in
the
tutorial
to
those
how
to's
so
people
going
through
the
tutorial
and
they
get
stuck
at
that
certain
point
they
have
somewhere
to
go.
That's
not
kind
of
like
oh
gosh.
This
doesn't
look
like
my
database
yeah.
A
A
A
A
A
A
They
probably
don't
need
a
lot
of
explanation,
I'm
not
sure,
but
if
you're
an
agency
who's
been
hired
by,
you
know
the
equivalent
of
open
sessions
or
something
like
that.
Maybe
you've
got
a
different
kind
of
need,
but
I
don't
have
a
sense
of
where
developers
are
starting
from
actually
in
the
open,
active
ecosystem.
B
B
B
C
Yeah,
I
guess
I
guess
building
on
that,
maybe
maybe
some
of
the
specifics
that
would
be
useful
to
explain
a
lot
slightly.
More
conceptual
would
be.
Why
are
there
feeds?
Why
not
an
api?
Where
is
my
api
where's,
my
one
big
api?
I
can
plug
into
you
to
get
all
the
open,
active
data.
Why
isn't
that?
One
and,
and
then,
like
you,
know,
the
activity
list?
C
What
is
that
like?
Because
there's
almost
like
a
very
you,
can
imagine
like
a
very
rough
diagram
which
is
like
one
activity
list,
lots
of
feeds
from
different
providers,
consumer
consuming
feeds
and
then
like,
underneath?
Why
this
is
so
like?
There's
there's
a
lot
of
really
good
rationale
behind
the
design
of
that
ecosystem
and
like
laying
out
the
reasons
for
it
so
that
someone
doesn't
come
in
and
goes
well
hang
on.
C
A
A
I
think
that's,
I
guess.
The
final
question
then,
would
be
despite
the
fact
that
we're
small
in
number,
I
feel,
like
you
guys
on
this
call-
are
actually
fairly
informed
about
what
it
looks
like
to
be
a
developer
approaching
this
for
the
first
time.
But
I
guess
the
question
is
who's
not
on
this
call,
who
would
have
a
different
view?
B
And
then
I
guess
someone
else
that
would
be
helpful
is
someone
who
is
more
recently
implementing
a
consumer
because,
of
course,
we've
had
this
in
the
pipeline
now
for
about
six
or
eight
months,
so
we're
quite
a
long
way
away
from
when
we
first
kind
of
said.
Oh,
let's
look
at
open,
active
and
see
if
we
can
implement
that
as
a
feed.
A
Right,
okay,
so
consumers
are
underrepresented,
but
is
there?
Is
there
a
kind
of
because
I
feel
like
even
even
schools
plus
is
an
organization
kind
of
similar
to
other
organizations
that
we
deal
with?
I
mean
they've
got
some
specific
problems,
but
they're
not
they're,
not
really
outliers
in
terms
of
what
they
do.
B
Yeah,
I
guess
the
the
main
kind
of
company
that
I
imagine
maybe
exists,
but
might
not
is
the
kind
of
the
smaller
scale
single
event
type
people,
because
I
feel
like
they're,
probably
underrepresented
by
probably
just
not
having
development
teams
right.
Yeah
they're,
not
that
scale,
but
they
might
in
the
future,
want
to
be
able
to
put
something
like
that
in
their
website.
A
C
A
C
Although,
in
fairness,
some
of
the
wordpress
sites
actually
include
a
large
number
of
events
coming
from
a
wordpress
databases
as
the
source,
so
it's
not
necessarily
a
one
event
thing
yeah.
I
I
did
think
there
was
a.
There
was
a
point
where
working
with
emd
a
wordpress
plugin
was
looking
like
an
interesting
thing,
but
the
problem
then
that
actually
comes
next,
because
we
did
investigate
that.
C
Is
that
there's
a
number
of
different
plugins
actually
that
people
actually
already
use
for
events
in
wordpress,
and
so
it
becomes
not
a
plugin
to
wordpress,
but
actually
in
addition
to
the
plugins
that
exist
but
yeah
and
then
you're
into
kind
of.
What's
the
most
popular
events,
wordpress
plugin,
and
can
we
get
that
to
adopt
open,
active
spec
and
it
turns
out
there
isn't?
Well,
it
didn't
seem
to
be
from
our
loose
research.
There
wasn't
like
one
events
plug-in
everyone
was
using.
It
was
like
everyone
was
using
just
whatever
they
found
on
google.
A
B
So
I
guess
that's
probably
the
most
complicated
bit
that
I
found.
I've
noticed
that
when
I
was
working
with
schools,
plus
they
were
having
deaf
difficulty
with
the
rpd
feed
and
essentially
a
confusion
that
they
found
was
the
after
timestamp
being
the
current
timestamp,
rather
than
the
timestamp
of
the
last
item.
In
the
page.
B
A
Right,
yeah
yeah.
I
think
I
think
conceptually
rpg
is
kind
of
interesting
again,
that's
that's
the
kind
of
explanation
level
I
suppose
is
that
I
think
where
I've
hit
the
buffers
with
in
correspondence
that
you've
seen
nathan
yeah
trying
to
explain
what
that
works
and
why
you're
doing
it,
I
guess,
is
sort
of.
Despite.
B
C
C
C
Oh,
it's
definitely
this
almost
before
finishing
reading
yeah
and
then
they
kind
of
stop-
and
I
don't
know
how
yeah,
especially
as
like
that
thing
about
using
the
query
correctly,
which
must
be
written
in
like
15
different
places,
definitely
check
the
query.
As
you
know,
the
right
brackets
on
the
right.
C
This
is
the
most
common
issue
and
every
time
yeah
one
in
five,
maybe
implementations
have
that
query
wrong.
So
I
I
feel,
like
we
probably
got,
I'm
not
sure
how
we
organize
the
documentation
such
that
that
stuff
is
maybe
clearer
or
or
maybe
it's
just
that
developers
tend
to
have
a
tendency,
as
I
have
been
with
the
award
stuff
to
just
dive
in
and
just
get
it
working
and
so
yeah.
B
B
A
B
B
B
I
feel
like
until
we
have
that
you
would
be
able
to
point
to
one
of
the
book
tech
feeds,
because,
unlike
a
lot
of
implementations,
I
see
we
do
have
very
very
big
pages.
So
we
limit
our
pages
to
a
thousand
items
so
that
normally
gets
through
all
of
the
deleted
stuff
and
then
hits
match
with
slots.
You
can
kind
of
scroll
through
and
see.
What's
going
on,.
C
And
there's
also
worth
saying
that
the
reference
implementation
that
exists
well,
there's
two
actually
there's
one
in
net
and
one
node:
no
one's
called
lorien
fitzson
randomly
generates
sessions
and
then
with
the
net
one
similar
but
less
kind
of
bulky
data,
and
they
are
public,
accessible
urls.
So
I
mean
you
could
imagine
I
mean
if
there's
if
there's
cause
on
those
endpoints,
you
could
imagine
like
a
very
simple
little
little
javascript
page,
which,
like
one
of
those
embeds,
jsfiddle
things,
but
you
just
press
next.