►
From YouTube: OpenActive W3C Community Group Meeting / 2018-08-15
Description
A public hangout for members of the OpenActive W3C Community Group.
Agenda and summary: https://lists.w3.org/Archives/Public/public-openactive/2018Aug/0002.html
For more information visit: https://www.openactive.io/w3c-community/
A
A
A
Chris
has
done
some
really
good
work
on
moving
that
spec
forward
to
getting
us
closer
to
a
state
where
we
can
feel
confident
about
putting
a
label
on
it.
I
we
haven't
had
a
huge
amount
of
feedback
since
over
the
last
few
weeks,
which
I'm
not
sure
to
take
positively
that
there
are
no
major
issues,
all
that
we
need
to
do
more
to
come
to
a
bit
of
outreach.
A
So
if
all
of
you
can
you
know
reach
out
to
people
that
you
know
who
have
expressed
interest
in
this
be
useful,
because
I
think
the
more
the
more
feedback
we
get,
the
more
confident
we
could
be
about
kind
of
drawing
a
line
under
this,
the
next
couple
next
version,
or
so
this
spec
and
moving
on
to
some
other
things.
So
let
me
just
share
my
slides
so.
A
A
couple
of
issues
I
want
to
talk
about
today,
but
in
terms
of
coverage
of
the
requirements
that
we
captured
a
few
months
ago
back
in
the
original
workshop
and
in
the
discussions
that
we've
had
so
far,
I
think
reasonably
confident
that
this
covers
the
essential
parts
of
third-party
booking.
We
know
there's
a
whole
range
of
other
requirements
that
people
have
around
booking
customer
management,
payments,
waiting,
lists,
etc.
A
A
What
the
booking
flow
looks
like
so
just
to
kind
of
jump
to
the
diagram,
just
to
kind
of
summarize
how
we've
gone
ahead.
Yeah,
we
are
in
the
specification.
We
are
not
dealing
with
issues
like
authentication
and
security,
because
we
expect
every
platform
to
have
their
own
preferred
way
of
doing
this.
A
So
the
basic
flow
which
we've
talked
about
on
previous
calls
is
the
client
will
be
able
to
query
to
get
the
current
status
of
an
event,
so
they
can
get
the
current
currently
available
offers
and
get
the
current
availability
of
the
event.
So
these
are
actually
a
space
to
booked
so
that
they
can
provide
a
customer
with
a
list
of
options
to
allow
them
to
book
a
place
so
purchase
a
spot
to
participate
in
the
activity.
A
A
Any
subsequent
kind
of
flow
around
how
a
user
is
notified
or
kept
informed
about
updates
to
an
event
is
kind
of
out
of
scope
for
the
API.
So
there
are
certain
things
that
we
know
that
will
need
to
happen
to
you,
know,
engage
with
or
customers
and
participants
for
those
aren't
really
part
of
the
core
booking
workflow,
and
we
have
documented
in
the
latest
iterations
support
for
cancellations,
and
that's
one
of
things.
I
wanted
to
just
briefly
touch
on
in
the
discussion,
so
that
workflow
we
say,
we've
talked
about
that.
A
Quite
a
bit
nobody's
really
had
any
major
issues
with
that.
The
the
it's
not
read
deviated
from,
the
prototypes
number
of
people
have
been
doing
against
the
early
draft
specification.
The
only
things
that
we've
refined
is
some
of
the
details
around
which
HTTP
methods
were
using
to
interact
with
the
API.
A
B
A
A
Currently,
so
the
the
crudest
way
is
that
if,
if
the
platform
doesn't
provide
any
office,
so
any
information
on
pricing
or
availability,
then
the
events
workable,
but
we
also
allow
them
to
advertise
and
offer
but
indicate
when
the
offer
is
available
from
so
start
an
end,
so
that
this
is
deal
with
requirements
such
as
you
know,
there's
an
event
on
Friday,
but
you
can't
start
booking
and
so
like
Thursday
afternoon,
for
example.
So
there
we
would
be
a
set.
A
You'd
still
indicate
somebody
what
the
price
would
be,
but
a
client
will
be
able
to
see
that
actually
they
can't
take
a
user
through
that
workflow
until
that
point,
so
user
would
have
to
come
back
with
that.
At
that
stage,
there's
an
opportunity
there
for
application
to
you
know,
send
a
reminder
to
the
user
that
the
offer
they're
interested
in
is
available.
So
I
think
we
have
have
some
support
for
that
cool.
C
The
the
think
couple
things
I
would
stir
kind
of.
Oh
sorry,
I
was
just
I
mean
that
just
on
that
one,
just
a
quick
one,
water
talking
of
that
and
there's
also
balance
from
advisories,
which
are
similar
to
the
availability,
starts
and
ends.
I,
don't
know
if
we
want
to
just
check
we
using
the
Rhine
property,
because
I
think
I
thought
that
frog
to
or
what
do
what
you
just
described
with
schema.org
in
there,
both
on
the
offer.
So
it's
okay.
A
Okay,
good
catch
thanks
yeah,
so
the
things
that
we
haven't
really
talked
about
are
the
terms
conditions
bit
and
the
cancellations
and
refunds,
and
so
I,
just
kind
of
threw
that
just
to
just
make
sure
everyone
is
what
we
need
to
cover
and
the
kind
of
how
strong
the
language
needs
to
be
in
the
specification
around
support
for
this
this
kind
of
stuff,
and
then
we
took
extension
points
and
then
the
only
real
open
issue
description
we
have
is
around
how
we
about
free
events
and
currency
displays,
which
is
Nick
and
I,
have
been
discussing.
A
Forget
time.
We
can
talk
about
that,
otherwise
we
can
do
carry
on
so
for
terms
of
conditions.
There's
I
think
broadly,
there's
two
things
that
we
need.
You
need
to
better.
Do
somebody
who's,
placing
a
booking
needs
to
be
able
to
see
read
any
in
terms
of
conditions
that
apply
to
the
booking
that
they're,
placing
with
the
platform.
So
there
will
be
some
kind
of
Terms
of
Service
terms
of
use
that
will
govern
their
booking
from
a
GDP.
A
Our
point
of
view,
a
user
also
needs
to
be
aware,
beside
posted
to
any
privacy,
notices
or
policies
that
are
might
apply
or
the
will
apply
to
handling
of
their
personal
data.
So
we
minimized
the
amount
of
information
that
has
been
passed
around
about
a
user,
but
there's
still
a
name.
An
email
address
that
goes
is
going
via
the
broker
to
the
booking
system.
So
I
think
we
need
to
be
able
to
surface
that
information
somewhere
in
workflow
I.
A
So
in
the
specification
at
the
moment,
it's
we're
proposing
to
use
a
schema.org
property
called
Terms
of
Service,
which
is
a
pending
property.
So
it's
something
that's
still
under
discussion
which
allows
allow
somebody
to
point
to
the
Terms
of
Service
that
apply
to
well
broadly
any
application.
So
it
seems
like
it's
potentially
applicable,
to
capturing
that,
but
linking
to
the
Terms
of
Service
information
that
applies
to
an
offer.
So
in
the
specification
at
the
moment
we
say
that
an
offer
could
have
a
Terms
of
Service
property.
A
A
In
terms
of
the
current
data
model,
those
seem
to
fit
more
closely
in
office,
although
my
suspicion
is
that
these
Terms
of
Service
and
Privacy
notices
will
be
consistent
across
a
booking
system
and
that
will
apply
to
every
offer
or
you
know
every
event-
every
use
the
facility
that
is
going
from
that
booking
system.
So
there
is
a
little
bit
redundancy
in
in
including
these
in
every
single
offer,
but
we
don't
have
another
kind
of
useful
hook
to
provide
that
information
without
providing
say.
C
A
Expect
them
to
change
between
offers
necessarily,
but
it
it
feels
that
it
feels
like
from
a
semantic
kind
of
modeling
point
of
view.
It
feels
like
it's
more
aligned
with
an
offer
than
an
event
or
a
facility
use,
because
it
because
everything
around
eligibility
or
the
kind
of
contexts
that
applies
the
offer,
is
also
part
of
the
model
if
it
didn't
fit
at
the
offer
level.
I
would
say
that
is
probably
at
the
service
level,
which
we
don't
actually
describe
anyway.
At
the
moment,.
A
So
an
alternative
approach
would
we
end
up
having
an
endpoint
somewhere
that
describes
a
service
which
is
the
booking
system
you're
interacting
with,
and
we
use
that
as
a
hook
to
provide
this
system
level
information.
So
you
do
a
get
request
on
the
on
a
service
URL,
and
it
would
say
this
is
the
Terms
of
Service.
This
is
a
privacy
notice.
Maybe
who
is
this
running
this
this
system?
There
might
be
other
metadata
that
we
want
to
put
in
there.
For
example,
like
default
lease
duration.
A
C
Need
play
ways
and
booking
book
when,
in
this
conversation,
actually
I
imagine
they'll
have
it
specifically
the
reason
that
they're
interesting
is
because
they
both
have
a
single
feed
which
contains
multiple
customers,
and
they
also
provide
the
ability
to
specify
terms
of
conditions
for
your
per
on
a
per
customer
basis
within
their
configuration.
So
that's
thinking
a
good
examples
where
you
would
have
yeah
you,
your
feed.
Would
the
Terms
of
Service
would
change,
it
doesn't
seem
feel
like
there
must
be
another.
A
The
other
thought
was
was
to
actually
do
something
with
the
potential
action,
but
that
is
still
just
some
foolish
planting
point
of
view.
He
doesn't
seem
to
make
sense
to
say
that
an
event
has
a
term
of
search
terms
of
service
is
that
that
probably
applies
to
you
know
your
rights,
around
refunds,
etc,
rather
than
participating
in
the
event.
Sorry.
C
C
A
D
Think
one
of
the
reasons
I
removed
potential
action
on
to
an
offer
is
that
there
was
a
possibility.
You
might
be
able
to
get
an
offer
via
a
URL.
So
there
might
be
a
URI
for
that
particular
offer,
and
you
might
actually
need
all
of
the
information
about
how
you
would
book
it
from
from
that
particular
endpoint,
rather
than
from
within
an
event.
C
Yeah
I
guess
there
was.
There
was
a
thought
before
about
that,
only
being
the
offer
only
being
useful
in
the
context
of
an
event
due
to
the
kind
of
metadata,
that's
in
the
event
itself,
like
title
and
description
and
an
offer
on
its
own
tends
to
be
junior,
something
you
know:
junior
member,
30,
30
pounds
so
calm.
C
It
doesn't
necessarily
give
you
enough
information
to
fully
describe
it
to
then
proceed
with
the
booking.
I
see
I
can
see
where
that's
kind
of
come
from
I
guess,
there's
a
I
suppose
it's
probably
the
same
there,
maybe
as
an
overall
principal
here
with
sub
events
and
with
offers
where
there
we've
got
things
in
the
tree
that
have
lots
of
stuff
in
them.
If
you
should
be
able
to
inherit
that
of
stuff
from
the
parent
really
because
otherwise,
we'll
you
know
just
for
the
sake
of
semantics,
be
massive
objects.
Okay,.
A
A
A
So
there
should
be
some
you're,
not
saying
how
they're
displayed,
or
you
know
when
it's
a
checkbox
or
what
interaction
there
is.
But
the
broker
should
be
doing
something
with
that
information
when
it's
available
so
there's
some
must
there
also
that
the
application
should
be
allowing
a
user
to
click
through
and
look
at
the
document.
That's
at
the
end
of
that
URL
as
part
of
the
workflow.
You
know
whether
it's
pop
it,
whether
it's
going
to
try
and
grab
the
HTML
or
pop
up
a
frame
or
something
you
know
it's
up
to
the
client.
E
B
Mean
this
is
kind
of
like
maybe
just
beyond
the
realms
of
what
we
need
to
think
about
realistically
right
now,
if
that
data
was
being
held
outside
of
the
EU,
is
there
something
you
need
to
kind
of
agree
to
I
mean
obviously
I
keep
getting
these
like
pop-ups,
I
I'm,
never
quite
sure.
If
it's
just
because
people
don't
know,
gtp
are
very
well
or
something
else
of
it.
I
think.
A
A
You
know
that
you
know
the
ICO
guidance
for
what
you
should
be,
including
your
privacy
notice
should
be
things
like.
Is
your
danger?
Gonna
go
outside
the
EU,
so
I
think
we
don't
not
sure
that
we
need
to
detail
in,
but
it
might
be
worth
adding
a
link
in
the
specification
to
say
you
know
we
don't
have
we'll
just
add
a
note
somewhere
to
say
you
know
we're
not
going
to
tell
you
what
to
put
your
privacy
notice
is
what
his
I
cuz
guidance,
no
just
to
encourage
best
practices.
Yeah.
B
A
C
So
pulling
fusion
and
everyone
activist
requirements
into
this
for
Gladstone
they
actually
that's,
don't
have
as
part
of
their
GDP
are
probably
did
I,
don't
know
people
over
complicating
it.
Who
knows
it
is
he's
going,
but,
and
they
have
a
thing
that
you
can
do
where
you
make
when
you
create
the
member
in
the
system
which
is
effective.
C
This
person
has
ticked
the
box
to
consent
to
marketing
blah
blah
blah
blah
and
they
provide
a
beloved
text
for
the
marketing
tick
box.
And
then,
when
you
tick
the
box,
you
can
say
this
has
been
ticked
and
the
reason
that's
something
that
they
were
active
in
fusion
particularly
care
about.
Is
that
they're
really
interested
in
talking
to
these
people
in
the
context,
rather
than
just
for
the
use
of
the
service,
as
are
their
kind
of
core
business
or
the
reason
they're
interested
open
data
is
to
upsell
members
membership
to
people.
C
If
someone
comes
into
the
center,
they
want
to
even
think
from
through
my
little
pitch
or
somewhere
else.
They
want
to
be
able
to
say
that
they
can
email,
those
people
and
targeted
marketing
or
what
kind
of
stuff
so
that
that
requirement
looks
like
a
string
that
is
able
to
be
put
somewhere
and
then
some
positive
action
that
we
can
record.
Okay,.
A
C
It's
you
can
imagine.
This
is
something
that
they
spent
a
lot
of
time,
money
on
figuring
out,
because
that's
the
the
the
question
of
whether
their
emails
are
service,
emails
or
marketing.
Emails
has
big
implications
and
all
of
their
cut
up
selling
and
they're
their
view
misses
I'm.
Talking
Ben
leave
is
everyone
active
specifically
now
Ben's
view
is
that
he
wants
to
make
sure
that
they'd
maximize
the
opportunity
to
engage
with
these
people
and
doesn't
think
that
having
just
yeah
a
service
email,
whether
with
a
subscribe
button?
No
one
clicks
that
so
it's
not
so.
A
C
I
mean
potentially
that
yeah
I
guess
Jamie's
yeah,
it's
it's!
It's
almost
like
it's
a
it's
a
should
technically,
but
if
Ben
makes
it
a
must
for
whatever
contract
get
signs,
then
obviously
the
broker
will
have
to
make
it
a
master,
but
not
because
it's
technically
a
must,
because
it's
part
of
the
agreement
yeah.
E
Go
ahead.
Our
experience
of
this
is
that
yes,
operators
are
now
starting
to
ask
that
and
they
have
the
right
to
ask
that
because
they're
also
the
data
controller,
but
they
can't
make
it
a
required
opt-in
to
proceed
with
the
booking.
So
you
know
they
can
ask
the
question,
and
if
the
user
doesn't
opt-in,
then
that
is
fed
through
the
API
and
tells
the
system
that
they
hadn't
given
their
consent.
And
then
things
like
those
emails
you
mentioned
are
actually
not
allowed
by
all
there's
a
court
case
around
the
car
manufacturer.
I.
E
Think
who
did
that,
and
it
was
proven
by
the
course
of
time
that
they
weren't
actually
allowed
to
ask
how
their
service
was
if
they
didn't
have
the
positive
up
ten
if
it
includes
any
marketing
communication
in
it.
So
why
don't
you
come
back
next
time
or
but
next
week
is
counted
as
a
marketing
communication.
E
E
It's
whether
people
want
to
get
kind
of
wrapped
up
an
illegal
conversation
with
the
operators
with
both
sides,
arguing
different
points
and
it's
bit
of
a
gray
area.
So
I,
don't
think,
there's
any
concrete
answer
at
the
moment.
The
advice
for
you
were
given
is
that
they're
not
able
to
you
had
a
conversation
with
an
operator
who
says
they
are
able
to
and
given
the
sign-up
rates
tend
to
be
pretty
small
for
the
second
pair,
the
second
marketing
communication
email.
It's
quite
often
just
not
worth
arguing
that
much
about.
E
Oddly
with
the
operator,
we
did
have
the
conversation
about
it,
we've
got
a
higher
rate
of
return
than
any
other,
so
it's
kind
of
often
a
overstated
point
at
this
stage
and
I
think
when
there's
a
little
bit
more
guidance
from
the
EU
etc
on
whether
people
are
allowed
to
go
back
without
marketing
communication.
I
think
that'll
be
made
more
clear
over
the
coming
months.
Okay,.
A
You
know,
whatever
their
contract
or
agreement
is
with
booking
system
should
be
following
whatever
privacy
marketing
best
practices
are
with
regard
information
correct.
So
the
other
thing
to
think
about,
then,
is
if
we
is
how
we
also
indicate
back
in
the
booking
I'm
taking
out
of
the
lease
that
somebody
has
opted
in
for
that
marketing
information.
A
E
Okay,
I'm
just
gonna
duck
out
at
this
point:
okay,
just
to
say
that
we
have
given
a
really
good
review.
The
the
spec-
and
it
looks
great
from
our
perspective
and
I-
know
that
hardly
one
of
our
guys,
who's
really
knowledgeable
about
booking
api's
I
thinks
it's
extremely
well-written
and
she
was
about
bringing
me
so
yeah.
It's
the
kind
of
thumbs
up
from
us
excellent.
G
A
Okay,
so
cancellation
on
refunds.
So
again
this
seems
like
it's
relatively
one
of
those
things
where
it
seems
like
relatively
no-brainer,
but
there
will
be
some
wrinkles
in
it
somewhere.
So
it's
worth
talking
through.
So
you
know,
I
would
I
think
broadly
user
should
be
able
to
cancel
and
then
get
a
refund
for
something
in
the
big
books.
A
We've
said
in
the
specification
that,
because
the
broker
is
handling
payments,
then
the
broker
should
also
be
handling,
cancellations
and
refunds,
and
then
we'll
be
updating
the
booking
system
of
canceled
orders
and
there's
an
API
endpoint
to
cover
that
okay,
so
that
that's
kind
of
the
features
there
to
cover
it,
but
I
think
there's
a
couple
of
things
that
we've
discussed
around
the
performance
language.
So
here's
the
start
of
a
ten
so
broker
must
allow
used
to
cancel
and
receive
refund.
A
Now
after
I
wrote
that
I
immediately
thought
that
it's
like
to
be
caveats,
the
platforms
will
say
you
can
cancel
up
to
maybe
48
hours
or
two
hours
or
something
before
an
event.
It's
quite
common
for
hotel
bookings,
for
example,
that
there
will
be
a
time
limit
on
it.
We
haven't
really
specified
a
way
to
do
that
at
the
moment.
A
A
D
A
A
Well,
you,
where
there's
a
good
question
right,
so
there's
there's
two
ways
to
indicate
it.
If
there's
no,
there's
no
cancel
action
on
the
on
the
order,
it
can't
be
canceled,
so
it's
kind
of
implicitly
there
through
that
it
is,
but
you'd
only
see
there
after
you've
created
an
order.
Yes,
that
is
true,
so,
whether
so
any
rules
about
whether
you
can
cancel
or
whether
there's
a
time
window
for
cancellations
might
need
to
be
made
available
elsewhere,
yeah
the.
C
D
C
A
A
The
full-back
would
be
if
there's
no
cancel
action
within
the
in
terms
of
how,
in
terms
of
the
window
in
which
you
can
do
the
cancellation,
that
feels
like
information
that
should
be
available
on
the
order
that
there
should
be
some
properties
on
that
to
say
you
can
cancel
until
on.
Maybe
your
dates
would
date
time
to
indicate
that.
C
A
C
Other
thing
is
that
often
because
of
those
limitations,
you
can
counsel
you
just
can't
do
online.
So
for
a
fusion
you
can
actually
call
up
the
site
because
I
has
a
manual
go
process,
pretty
sure
it's
paper-based,
and
then
they
will
initiate
a
bank
transfer
which
will
then
go
back
when
you
put
your
banking
selves
in
the
back
in
your
account.
Obviously
that's
totally
out
of
band,
but
it
does
mean
that
it's
council,
you
can
cancel
the
thing
you
just
can't
click
on,
but
then
do
it.
A
A
C
No
look
at
the
current
weights
working
is
that
the
cancellations
just
not
allowed
the
number
a
number
of
brokers,
actually
don't
have
cancellation
anyway,
it's
just
a
policy.
Okay,
obviously,
that's
not
ideal.
We
want
to
move
towards
a
place
where
these.
This
is
a
feature.
That's
in
there.
We
want
to
encourage
people
to
adopt
it,
so
yeah
I,
think
making
it
a
sugar
or
a
must,
as
an
implementation
point
is,
is
a
really
good
idea,
because
what
why
can't
you
do
that
over
the
API?
You
can
do
it
within
the
interface,
but
well,
if
but.
A
D
Yeah
I've
looked
at
schemer
and
knowing
that
offer
all
order
has
anything
about
cancellation,
so
he'd
probably
have
to
extend,
and
it
feels
it
feels
kind
of
to
the
user
to
do
it
at
the
point
of
the
offer,
because
if
they,
if
they
discover
when
they've,
actually
placed
the
order
or
when
they've
created
the
order
that
they
they
can't
cancel
it.
That
might
feel
like
a
bit
of
a
bad
feeling.
Yeah.
A
D
D
B
C
Just
a
random
thought
one
way
to
do
all
of
this,
because
it
sounds
like
we're,
adding
even
more
properties
to
this
little
offer.
That's
to
placate.
As
many
times
have
you
looked
at
a
griot
offer
and
we've
got
offer
can
be
used
in
place
of
offer
and
is
designed
to
pull
together
properties
from
a
number
of
offers
into
one,
and
it
also
contains
offers.
So
that
might
be
a.
C
We
can
specify
offer
with
an
aggregate
offer
bankers
the
booking,
the
cancellation
policy,
the
tenant
service,
all
the
things,
and
then
that
increase
creates
a
bit
of
an
inheritance
model
that
we've
got
with
event.
So
you
can
basically
bung
everything
into
the
aggregate
offer
and
then
only
we
only
have
the
things
duplicated
that
need
to
be
duplicated
across
all
the
offers.
They're
in
there.
A
Like
personally
I
kind
of
lean
towards
pushing
it,
I
hope
I'm
completely
and
just
having
it
having
a
public,
so
a
discoverable
public
service
endpoint
that
has
this
configuration
in
it
and
then
we
can
have.
We
can
have
in
whatever
level
of
detail
we
need
and
we
doesn't
have
to
go
into
the
feeds.
It's
only
going
to
be
useful
for
brokers
that
need
that
as
part
of
booking
workflow,
rather
than
recurring
everyday
to
consumer.
So
cuz
we
have
that
information.
We.
A
I'm,
a
little
bit
hesitant
around
the
kind
of
inheritance
stuff
is
that
it
can
add
a
lot
of
complexity
itself
in
terms
of
how
you
know
how
and
where
things
are
being
inherited
and
what
that
means.
In
terms
of
how
much
information
you
need
to
have
harvested
or
indexed
before
being
able
to
properly
interpret
that
where
something
that
is
just
pointed
at
from
a
regular
location
could
be
easier
on
a
consumer
side.
But
yeah
there's
always
a
trade-off.
D
A
A
A
A
So
I,
just
one
of
the
a
good
kind
of
test
at
this
point
is
to
just
think
about
what
the
what
the
points
of
extension
are
in
the
current
specification
to
allow
us
and
others
to
build
on
it
to
support
these
are
the
requirements.
So
you
know
can't,
can
we
come
any
common
stuff,
so
I
just
wanted
to
list
out
the
ways
that
the
the
API
can
currently
be
extended
to
see
whether
we're
missing
anything.
A
Whether
we
need
to
kind
of
document
this
I
think
we
may
need
some
more
words
inspector
just
to
kind
of
capture
some
of
these
nuance,
because
I've
been
put
in
a
bit
more
information
around
how
to
extend
the
core
data
model,
for
example,
and
we
might
need
that
in
the
book
you
expect
to
so
at
the
moment.
There's
three
broad
ways
that
you
can
extend
the
current
model,
so
we
can
add
new
endpoints,
so
you
can
just
build
out
parallel
bits
of
your
API
to
expose.
A
If
you
want
expose
a
payment
interface,
then
somebody
could
do
that
and
a
broker
could
choose
to
use
that
or
might
be
required
to
use
that
part
of
integrating
with
the
booking
system.
There
can
be
infinite,
separate
end
points
around
customers,
etc,
and
what
we'd
be
recommending
is
that
people
follow
the
same
design
approach
as
we've
been
taking
with
the
core
API
that
they're
building
on
schema.org,
using
json-ld,
etc,
etc,
so
that
it's
consistent
with
the
approach
that
we've
taken.
So
that
means
within
the
within
spec.
A
So
we're
using
the
approach
we're
taking
is
that
URLs
are
discoverable
using
potential
action.
So
currently
we've
got
actions
for
paying
reserving
and
cancelling
so
platforms
could
add
extra
features
to
their
API
by
defining
new
potential
actions
that
point
to
new
custom
endpoints.
So
if
I
wanted
to
implement
a
wish
list,
for
example,
then
I
could
put
define
a
new
custom.
A
Add
add
me
to
wishlist
action
that
is
advertised
on
an
event
that
points
to
my
custom
endpoints.
That
would
hopefully
use
the
same
kind
of
modeling
approach
and
that's
somebody
could
start
experimenting
with
that.
You
know
it
was
having
to
put
it
into
the
speculatively
and
then
oops,
adding
new
properties.
So
actually,
some
of
the
description
just
being
adding
like
adding
more
information
around
offers
more
detail
into
some
of
the
order.
Information,
for
example,
that
is
you
know.
A
People
can
obviously
do
that
in
the
same
way
as
they
are
with
the
current
data
model
and
they
can
define
their
own
custom
properties.
That's
a
little.
That
needs
a
little
bit
more
work
from
their
side
because
they
need
to
document
the
semantics.
So
we
need
to
think
about
what
it
means
for
a
client
who
might
see
client
application
that
might
get
retrieving
off
whether
it's
got
a
whole
bunch
of
custom
properties
on
it.
What
should
its
default
approach
be?
A
Should
you
just
try
to
obey
the
ones
that
it's
can
understand,
do
his
best
effort
or
should
it
ignore
offers,
if
there's
properties
on
it,
that
it
doesn't
know
how
to
apply
and
I
can
see
arguments
both
ways,
but
my
I
think
what
I'm
leaning
towards
is
that
if
you
find
an
offer,
that's
got
custom
properties
on
it.
Then
you
shouldn't,
you
shouldn't,
be
offering
it
as
a
booking
option,
because
those
offer
details
might
be.
A
You
know,
details
around
a
membership
offer
or
some
of
the
more
complex
kind
of
pricing
or
purchasing
scheme
that
you
can't
properly
action.
So
it's
a
good
bit
a
bit
of
a
con
runs
that
kind
of
you
know.
Generally,
we
want
clients
to
do
their
best
effort,
we've
data
but
I
think
because
anywhere
there's
money
involved
being
a
bit
more
cautious
about
what
we
suggest.
People
to
do
is
probably
a
better
for
starting
point.
I.
C
Wonder
if
there's
a
way
of
separating
additional
useful
data
for
a
further
is
optional
to
display,
but
is
nice
to
have
something
here?
Things
like
some
of
the
endpoints
have
got
payment,
frequency
and
or
maybe
not
wait,
yeah
just
or
a
each
range,
which
I
know
we've
had
it
in
now,
but
stuff
that
doesn't
make
any
material
difference
to
their
to
the
processing
versus
stuff.
Like
you
know
something
that
would
have
a
material
difference,
so
the
processing
I
can't
think
of
them.
Example.
You.
A
C
A
Yeah
I'm,
don't
think
how
that
works
in
a
kind
of
schema.org
word
because
I'm
a
bit
wary
about
just
defining
like
naming
conventions,
because
there
can
be
a
bit
brittle.
So
whether
we
maybe
translate
that
into
a
kind
of
structure
that
maybe
there's
a
you
can
pack
in
some
name
value
pairs
attached,
we're
not
further
for
those
things,
but
anything
else
or.
C
A
What
I
meant
by
just
making
it
discoverable
that
I
didn't
finish
the
thought
that
that
it
would
be
in
we
require
them
to
publish
a
context
that
would
have
some
properties
in
it
to
say
my
extension
custom
poverty
has
got
an
annotation
in
it
to
say
it's
fine
to
just
display
the
value
of
this
to
user.
You
don't
need
to
be
able
to
process
it
in
some
way
in
order
to
complete
the
offer.
Sorry.
C
A
A
But
it
would,
it
would
mean
that
every
consumer
would
have
to
be
ready
to
pull
down
the
context
because,
like
whenever
you
find
a
custom
property,
you'd
have
to
pull
down
a
context
to
see.
If
you
had
information
about
it
in
there
and
we'd
still
have
to
have
a
default
processing
rule
of
what
you
do
if
it's
not
properly
documented
or
you
have
an
error
condition
for
fetching
the
context,
this
it's
a
usual
kind
of
pulling
out
a
bit.
Well,
there's
always
there's
always
something
else
to
think
about.
C
A
Yeah
and
we
can
I
mean
like
for
the
purposes
of
getting
to
1.0,
we
could
just
say
like
at
the
moment.
We
reckon
you
know,
here's
how
you
can
add
new
importance.
Here's
how
you
know
actions,
we
don't
recommend
you
and
putting
extra
policies
into
office
for
the
moment
and
for
this
version
of
the
spec
we'd
suggest
not
processing
them.
C
A
B
Is
there
something
around
how
people
are
sharing
this
with,
you
know,
say
someone
who
does
go
away
and
kind
of
create
one
of
these
extension
points.
I,
don't
know
if
again,
apologies
if
that's
kind
of
covered
in
other
things,
or
that's
just
obvious
for
everyone
else,
I'm
cool
but
kind
of.
Obviously,
if,
if
you
put
all
kind
of
creating
those
things,
how
much
would
there
would
be
an
expectation
to
share
that
learning
and
those
kind
of
code
or
whatever
back
in
back
into
the
community?
That's.
A
That's
a
great
question
and
you're
right:
we
should
have
something
to
say:
if
you
are
including
custom
actions,
custom
end
points
in
your
API.
You
should
be
documenting
them.
You
know
you
should
be
I
mean
we
don't
have
to
say
that
there's
one
way
to
do
it,
but
you
should
be
publishing
some
level
of
API
documentation,
some
level
of
information
to
support
your
users
as
part
of
having
a
good
developer
experience
around
your
API,
so
I
think
we
can
include
something
along
those
lines.
C
It's
pretty
important
to
say
at
this
point
that,
based
on
feedback,
we've
had
from
a
lot
of
different
organizations
and
pulling
in
a
call
a
conversation
we
have
with
net
post
earlier.
A
large
amount
of
the
value
from
this
work
is
in
uniformity
of
implementation
across
a
number
of
providers
and
extensions.
C
A
I
think
we've
got
language
around
that
in
the
modeling
spec
and
that
we
could
just
probably
carry
over
here,
but
I
think
it's
kind
of
saying
encouraging
that
this
is
what
we
expect
you
to
do.
You
know
participate,
contribute,
let's
standardize,
but
if
you
absolutely
must
run
ahead,
then
here's
how
to
do
it
in
a
way
that
isn't
going
to
be
completely
inconsistent
with
the
rest
of
what
people
are
doing.
Yeah.
A
Nene
at
the
time,
the
the
last
couple
of
things
I
was
just
going
to
mention
is
just
kind
of
reiterate
people
that
we've
got
a
few
proposals
out
for
the
2.0
version
of
the
data
model
that
could
do
with
some
community
feedback
from
the
team,
but
also
to
team
community.
So
the
300
wants
to
highlight
h.263,
adding
more
specific
types
of
events
will
be
fairly
big
change,
but
hopefully
clarified
the
relationship
between
events
that
are
in
feeds.
A
The
validator
itself,
we'd
still
like
to
get
some
feedback
on
the
UX
and
features
you
can
find
it
at
the
current
working
version
that
validated
I/o.
That
will
be
there.
The
production
location,
although
what's
there
at
the
moment,
you
should
consider
to
be
a
development
server,
so
it
might
get
updated
or
changing
as
we
do
work
on
it.
If
you've
got
feedback,
then
you
can
follow
the
bitly
link
in
the
slide,
find
a
bug,
report
or
just
drop
me
an
email.
A
A
So,
if
you
are
currently
publishing
data,
then
playing
around
the
validator
is
a
good
way
to
get
ahead
of
what
changes
might
need
to
be
coming
down.
The
line,
as
I
said
early
on
in
the
planning
for
2.0,
we
will
do
some
work
to
provide
individual
publishers
with
some
guidance
on
what
they
need
to
do
in
order
to
migrate,
so
that
we
can
try
and
get
everybody
moved
towards
the
2.0
spec
as
quickly
as
possible.
A
After
after
it's
released
in
terms
of
time
scales,
we're
still
planning
to
release
1.0
booking
spec
2.0
the
model
at
the
end
of
the
month,
so
that's
obviously
going
to
be
pending
any
major
issues.
Come
up.
We've
obviously
got
some
stuff
to
work
through
on
booking
I'm.
The
data
model
changes
I
think
are.
We
need
to
get
some
more
feedback
on
those
proposals
again,
I'm
reasonably
I.
Think
I
was
reasonably
robust,
but
I
just
like
to
get
some
more
eyes
on
it.
So
I
think
hitting
the
end
of
the
month
is,
is
achievable.
A
If
we
have
2d
scope.
Anything
then
I
think
the
thing
that
may
drop
from
2.0
is
the
roots
we
work.
We
had
the
call
we
had
a
fortnight
ago.
There
was
quite
a
lot
of
discussion
around
how
that
should
look,
which
might
need
a
bit
of
thinking.
So,
rather
than
rush
that
out,
we
can
wait
for
2.1
to
put
that
in
place.
So
because
I
want
to
focus
on
you
know.
The
main
thing
we
want
to
achieve
with
2.0
was
tidying
up.
Some
of
the
data
quality
related
issues.
A
So
that's
one
thing
that
might
give
and
the
validators
on
track
for
being
complete
as
well,
so
that
that's
where
we
are
today
in
terms
of
schedule
for
next
call
the
one
on
the
29th
will
be
just
looking
at
whatever
major
issue.
If
there
are
any
major
issues
of
blockers
that
we
need
that
are
going
to
stop
us
from
releasing
those
specs,
I
will
be
putting
out
a
kind
of
an
official
as
far
as
we
do
it
a
kind
of
call
to
the
list
for
people
to
raise
objections
with
the
current
drafts.
A
That
would
mean
that
we
need
to
delay.
You
know
in
september
for
finally
addressing
any
outstanding
comments
for
whether
people
are
happy
for
us
to
move
forward
with
those
major
version
changes.
So
I'm
going
to
keep
the
call-in
set.
The
first
call
in
september
open
just
because
we
may
need
to
discuss
any
of
remaining
issues
from
those
point
releases.
But
having
done
that,
then
we
can
start
to
focus
on
some
of
the
things
so
proposing
that
we
rejoin
some
of
the
discussion
around
activity.
A
G
Just
a
quick
one
Lee
all
this
stuff
is
really
relevant
to
what
we're
the
and,
at
the
moment,
no,
it's
good
timing
and
seems
like
a
lot
of
progress
is
being
made
so
good
stuff
from
that
guys.
Just
how
do
I
get
this
presentation?
That's
for
some
reason.
The
mailing
list
is
that
sometimes
it
sends
it
to
me.
Sometimes
doesn't
so
I'm,
not
sure
what
the
easiest
way
to
find
this,
so
I
can
show
up
and
form
James,
okay,.