►
From YouTube: OpenActive W3C Community Group Meeting / 2018-04-25
Description
A public hangout for members of the OpenActive W3C Community Group.
Agenda: https://lists.w3.org/Archives/Public/public-openactive/2018Apr/0011.html
For more information visit: https://www.openactive.io/w3c-community-group.html
A
There's
too
many
things
I
want
to
go
through
today
in
bulk
of
it
was
focusing
on
the
review
of
the
the
edges,
just
aft
for
the
one
version
of
the
opportunity
model
just
go
through
the
open
issues.
Do
a
bit
of
an
update
there
just
give
a
quick
update
on
plans
to
move
forward
from
version
0.4,
the
booking
spec
and
there
anything
else
that
we
want
to
cover
in
the
any
remaining
time.
A
So
what
I
wants
to
make
sure
is
that
everyone
knew
where
to
find
the
editors
draft
other
than
just
kind
of
me
sending
updates.
So
whenever
you
go
to
the
with
any
of
the
open
up
to
specifications
in
the
metadata
at
the
top
of
the
spec,
there
should
be
a
clear
link
to
the
latest
editors
draft.
So
currently
the
published
Beck
is
1.0
from
August.
Last
year
you
click
through
and
you'll
get
to
what
is
described
as
1.1,
which
is
the
draft
that
I
published
last
week.
A
The
other
thing
that
I've
been
doing
is
tidy,
trying
to
tidy
up
the
issues
there
process
of
making
a
proposal
in
line
with
some
of
the
revised
government's
and
process
that
we
talked
about
on
the
last
call
and
just
hopefully
make
it
clear
to
people
what
stage
the
different
proposals
are
at
so
I've
put
together
a
project
board
project
backlog
in
github.
So
if
you
go
to
the
modeling
opportunity,
data
get
a
project
under
the
projects
there.
A
The
stuff
that's
under
discussion
is
the
things
that
we've
been
actively
discussing
either
in
these
calls
or
in
discussion
via
emails
or
on
github,
and
then
there's
a
separate
column
for
those
things
that
are
now
in
the
editors
draft.
So
currently,
the
edges
draft
I
just
shown
has
got
changes
for
the
facilities
proposal,
the
age
range
proposal
and
the
updates
to
gender
restriction
I'm
intending
to
make
some
more
changes
for
the
amenities
work
to
put
that
in
there's
special
requirements.
A
Proposal,
I'm
not
sure
that
will
make
it
into
the
release.
Next
week,
I've
had
some
feedback
from
Jade
via
email
yesterday,
which
I
still
need
to
incorporate,
but
I
need
to
get
some
kind
of
wider
feedback
from
the
rest
of
the
group,
so
I'm
going
to
go
through
these
kind
of
four
full
proposals.
Now,
just
so
you
can
see
just
does
a
recap
essentially
just
to
send
a
check
of
what's
in
spec
and
give
people
chance
to
show
if
they
think
anything
is
wrong.
A
So
I've
been
doing
some
work
off.
The
back
of
the
recent
call
around
virtual
events,
so
started
to
work
that
up
into
a
proposal,
but
there's
still
some
investigation
were
there
before
we
can
finalize
the
best
way
forward.
So
hopefully
this
will
start
to
being
a
little
bit
of
clarity
to
where
we
are
at
with
updating
each
of
the
specs,
so
I'm
going
to
go
through
each
of
the
proposals
now
very
briefly.
Just
so,
you
can
give
me
any
feedback
or
when
your
thoughts,
you
have
so
the
first
one.
A
You
might
presume,
is
getting
in
the
way
of
me
changing
the
browser
to,
but
hopefully
you
can
see
that
age
range,
so
this
is
issue
68.
So
the
proposal
here
was
that,
based
on
looking
at
how
people
are
currently
using
the
aged
Range
property,
there's
a
lot
of
inconsistencies
and
it's
the
feedback
we
had
from
the
community
was
that
the
current
way
that
the
property,
especially
for
specify,
which
is
as
a
basically
as
a
number
or
a
number
range,
is
a
bit
fiddly
to
work
with.
A
So
we
discussed
on
a
recent
call
about
changing
this,
to
use
a
more
explicit,
min
and
Max
value
for
the
age
ranges.
So
the
you
can
see
the
example
here,
which
is
what
the
the
revised
specification
now
recommends.
So
the
age
range
property
will
be
a
have
type.
45
value
will
have
min
value
than
a
max
value.
So
this
is
all
stuff
that
comes
from
schema.org
there's.
No
new
new
properties.
A
A
A
If
max
value
is
not
specified,
there
was
no
maximum
age
so
just
to
try
and
make
sure
that
we're
very
excited
to
very
clearly
define
some
of
these
properties,
so
I
think
that's
pretty
uncontroversial
when
we
discussed
at
everyone
university
seem
to
be
happy
with
that
kind
of
more
explicit
approach.
Any
comments
on
that.
Always
everybody
happy.
A
Yeah
I
think
I
did
wonder
about
that.
I've
got
a
date
in
here
in
the
in
the
proposal.
So
if
something
is
suitable
for
all,
you
would
kind
of
have
to
put
that
explicit
number
range
in,
but
I
couldn't
think
of
any
other
way
to
do
that
without
providing
a
kind
of
sensible
default.
If
people
haven't
haven't
specified
one.
F
D
E
A
A
But
looking
at
the
existing
data
for
gender
restrictions,
people
are
using
male
female
and
mixed
as
values,
which
is
all
the
spec
recommended,
so
just
a
literal
value,
but
this
variation
in
spelling
casing
and
some
people
are
using
men,
women
rather
than
female.
So
when
we
discuss
this
as
a
group,
the
suggestion
was
that
we
should
switch
to
using,
but
rather
than
literal
values,
we
should
have
a
URI
and
we
decided
to
you
have
three
your
eyes
in
the
open,
active
namespace
one
for
male
one.
A
For
me,
female
and
one
for
mixed
nick
has
pointed
out
already
in
the
comments
that
there
is
a
typo
in
these
URLs.
They
should
be
HTTP
and
it
should
be
a
hash,
a
splash
at
the
end
there
so
I
need
to
fix
that
up,
but
essentially
you
would
have
to
use
one
of
these.
Your
eyes,
so
again,
there
needs
to
be
some
defaults.
If
it's
not
specified,
we
need
to
be
clear
about
how
to
interpret
it.
So
if
gender
restriction
is
not
supplied,
then
consumers
should
assume
that
it
is
mixed.
A
A
Female
likewise
I
checked
the
kind
of
language
and
it
seemed
to
fit
what
des
have
been
recommending
around.
You
know
use
of
the
words,
gender
and
some
of
the
terminology
there,
because
I
wanted
a
kind
of
society
check
that,
but
again
it's
kind
of
a
relatively
simple,
simple
change,
with
changing
the
gender
restriction
property
from
a
literal
value
to
namespace.
A
So
the
only
thing
that
I
was
worried
about
is
the
fact
that
it
would
invalidate
these
these
free
feeds,
but
a
couple
of
them
are
invalid
anyway,
because
they're
using
long
values,
the
the
minimal
change
would
have
been
just
just
to
be
more
explicit
about
what
value,
what
literal
values
to
use
but
I,
think
on
the
whole.
Using
your
eyes
is
better
and
I
think
it's
consistent
with
what
what
we
are
doing
or
plan
to
do
in
other
areas,
and
so
that's
that
one
does
anyone
have
any
comments
or
thoughts
on
that.
C
A
So
here
in
the
case
where
we
have,
we
know
that
there
are
values
out
there
that
don't
that
don't
meet
these
requirements,
we've
got
I,
think
probably
two
options.
We
could
say
that
consumers
could
support
of
the
values
and
it's
up
to
them
to
define
you
know
what
they
for
the
process
or
we
could
say
that
an
invalid
value
should
be.
We
should
assume
it's
mixed,
but
I
don't
either
those
are
ideal.
A
A
D
On
the
way
that
filtering
works,
whether
having
a
default
of
mixed
is
sensible,
I
I
would
recommend
actually,
given
the
lack
of
data
in
in
general,
that
we've
got
14
issues.
I
would
suggest
that
null
and
not
specified
is
taken
as
not
known
rather
than
mixed,
because
otherwise,
you
might
end
up
returning.
A
A
B
D
A
D
A
C
C
Would
you
ignore
the
whole
that
doesn't
make
an
invalid
record,
because
you
know
some
learning,
some
API
specs
will
just
pick
up
the
whole
thing
and
say
no
I
can't
deal
with
that,
and
others
are
much
more
tolerant
about
I,
don't
know
what
that
means,
so
I'm
just
gonna,
because
it's
through
do
you
strip
it
out
and
what
happened?
How
does
nature
to
poach
records
that
contain
some
invalid
data?
But
all
these
are
well-structured.
A
So
I
think
I'm
just
going
to
check
see
what
we've
got
in
the
specification
either
me
yeah,
so
that
I
mean
this.
It's
not
explicitly
spelled
out
in
the
way
that
you
just
stated
it,
but
in
their
kind
of
extent,
in
the
model
section
it
says
that
consumers
should
be
liberal
in
what
they
accept.
So
is
that
would
argue
for
I'm
not
invalidating
the
like
a
whole
event,
just
because
one
property
was
invalid.
It
just
means
that
you,
you
can't
necessarily
adequately
describe
that
for
some
for
some
consumers.
A
So
you
know
if
gender
restriction,
missing
or
meeting
point
is
missing,
there's
no
reason
not
to
provide
what
to
you
know
to
provide
what
you
can
to
a
user
or
to
aggregate
what
you
can
and
that
approach
is
inconsistent
with
people
being
able
to
add
custom
properties
almost
to
be
able
to
evolve
the
model
in
future.
To
add
new
things
in
without
requiring
everybody
to
have
to
agree
to
you
know,
process
them
they'll
be
ready
to
process
them
at
the
same
time.
C
A
It
is
a
good
question,
and
we,
though,
is
we
need
to
tighten
up
some
of
this
stuff
over
time,
so
that
we
can
improve
the
quality
of
the
data
we.
We
do
have
some
stuff
in
here
already
about
what
we
consider
to
be
required
or
recommended
fields.
There's
no
tolling
at
the
moment
to
enforce
that
and
I'll
I
separately
filed
an
issue.
A
A
It
probably
has
and
highlights
a
little
bit
better,
so
we
of
adding
a
new
new
type
to
the
model
which
we're
now
calling
facility
use
rather
than
amenities,
which
was
a
previous
suggestion
that
I
made-
and
this
is
a
basic
product-
it's
an
it's
an
offer
to
use
some
facility
at
a
particular
place
point
in
time.
So
a
facility
would
be
associated
with
the
location.
A
It
would
say
what
what
type
of
activity
would
be
taking
place
there
and
then
have
a
number
of
slots
associated
with
it
to
allow
somebody
to
decide
if
they
want
to
book
that
facility
at
a
particular
point
in
time.
So
we've
had
a
couple
of
calls
already
to
review
this.
The
last
bit
of
feedback
that
I
had
was
to
change
the
naming
from
immunity
used
to
facilities.
A
We
discussed
about
pricing
models.
Sometimes
there
might
be
a
single
price
for
the
use
of
the
facility,
regardless
of
the
time
of
day
other
times
there
might
be
pricing
for
individual
slots.
So
we've
already
got
support
for
that
in
the
model,
because
we
can
associate
offers
with
the
facility
use
or
for
the
individual
office.
A
There
was
some
suggestion
that
it
would
be
useful
to
be
able
to
indicate
how
many
facilities
were
available,
so
how
many
football
pitches
or
table
tennis
coats
are
available
on
these
tables
or
tennis
courts
were
available
at
10:00
a.m.
and
there
is
already
support
for
that
in
schema.org.
There's
an
inventory
level
property
that
allows
you
to
say
how
many
available
with
that.
So
that
supports
that
without
having
to
go
into
all
of
the
detail
of
describing
all
of
those
individual
facilities,
and
the
other
thing
that
we
discussed
at
length
was
that
the
proposed
model
work.
A
Facilities
like
facilities
that
are
primarily
single-use
and
there's
lots
of
there's
potential
for
some
churn
in
the
paging
in
in
the
feeds
that
people
are
publishing
for
multi-use
facilities,
so
we're
a
sports
all
can
divided
up
in
sixteen
different
ways
for
different
activities.
Booking
one
of
those
things
will
immediately
change
what
configuration
is
left
available
for
other
people
to
book,
which
requires
a
lot
of
update
and
feeds
where
we
got
to
on.
A
That
is
that
we
we
said
we
would
go
ahead
with
the
current
proposal,
but
we
would
put
a
note
into
the
specification
to
say
that
we
want
to
get
some
feedback
from
implementers
on
the
level
of
churn
level
of
overhead
that
actually
results
from
using
this
patchy
means
in
practice.
So,
rather
than
guess
on
the
impact,
we
won't
see
what
what
happened
and
then
decide
whether
we
wanted
to
deal
with
multi-user
location,
not
use
facilities
in
a
different
way
or
rethink
what
we're
doing
so.
E
A
D
Well,
one
comment
would
be
that
I'm
part
of
the
work
that
we're
doing
in
fusion
right
now
is
to
implement
this
I.
Don't
know
whether
it's
worth
holding
off
by
including
it
in
this
back
until
at
least
one
person
was
tried
to
implement
it
to
test
it
kind
of
it
works
overall
or
feel
that
it's
better
to
just
get
it
in
this
back
and
then
change
it
once
and
then,
because
I
I
know
we
haven't
really
tested
it
in
anger.
A
Yeah
I'm
inclined
to
just
to
go
ahead
with
with
publishing
it,
because
some
of
the
remedies
that
we
talked
about
weren't
actually
going
to
involve
changes
to
the
model
it
was
going
to
involve
changes
to,
for
example,
how
some
of
this
data
might
get
surfaced
in
in
feeds.
You
know
we
talked
about
splitting
out
some
of
that
into
separate
feeds,
so
they
can
be
aggregated
separately.
A
We
talked
about
different
approaches
to
surfacing
the
availability
data,
which
is
the
actual
thing
that
the
churn,
so
all
of
that
necessarily
meant
a
change
to
the
data
model,
anything
that
we
might
do
to
special
case
multi-use
facilities
would
end
up
adding
to
the
model.
I
think
but
I'm
kind
of
worried
about
that,
because
there's
a
whole
bunch
of
complexity
about
describing
I
wasn't.
D
Talking
so
much
about
Marty's
necessarily
was
more
just
just
having
some
moment
in
practices
at
all,
but
yeah
that
make
sense
something
getting
in
and
then
changing
it
now
previously,
we've
we've
been
a
little
bit
more
instance.
A
A
D
They
guess
percent
you
are
proposing
is
easy.
You
have
copied
a
bit
of
respect
that
it's
in
there
or
something
in
turn
into
the
proposal
and
have
people
in
so
if
they're
people
one
and
then
we've
got
something
working,
we
could
I'm
just
thinking
in
basically
the
second,
you
start
coding.
These
names
and
they'll
be
you'll
notice,
something
right
that.
B
D
A
A
D
A
Yeah:
okay,
if
we
can
get
some
feedback
this
week,
because
I
mean
broadly
won't,
you
I
think
you're.
Just
there
guess,
there's
a
couple
of
potential
issues,
one
that
it's
not
well
documented
enough
people
to
implement,
which
is
not
necessary.
Blocker,
the
other
one
is
just
that
the
model
itself
doesn't
work
but
I
based
on
feedback
from
Jamie,
Tom
and.
B
A
The
that's
kind
of
what
what
we're
doing
with
the
editors
draft
spec
has
been
an
editor's
draft
for
two
months
with
the
previous
version
of
this.
So
their
proposal,
like
we've,
been
discussing
for
a
while.
The
proposal
that
I
put
in
in
the
end
of
Feb
was
in
an
editor's
draft.
We
discussed
that
editors
draft
in
github
and
on
previous
calls
and
then
I
released
that
update
a
week
ago.
D
A
A
So
the
the
government's
top
governor's
document
I
circulated
recently
just
says
that
we
it's
okay
to
move
forward
as
long
as
there's
agreement
that
we've
had,
we
felt
like
we've,
had
sufficient
debate
and
discussion
in
the
community
there's
agreement
from
different
different
groups
of
people,
and
that
was
enough
to
go
in.
We
haven't
been
explicit
about
having
an
implementation
requirement.
D
D
D
A
So
the
next
issue,
so
this
hasn't
been
entered
into
the
spec
yet
but
again
we
talked
about
it
months
ago
is
about
describing
amenities
available
at
a
place
and
for
the
most
part,
this
is
just
agreeing
to
use
existing
features
of
scheme
dog.
So
if
there
was
already
a
way
within
scheme
to
say
that
a
here.
B
A
A
place
immunity
feature
which
is
an
array
of
features,
so
you
say
give
it
a
name.
You
say
a
value
of
true
or
false
to
say
whether
it's
provided
the
the
only
thing
that
we
are
I
think
we
are
changing
or
suggesting
as
an
addition
is
what
schema.org
does
he
say
that
I'm,
an
amine
and
C
feature
is
what's
called
a
location,
feature
specification
which
has
been
of
a
mouthful,
and
it
has
a
name
and
this
true
or
false
value.
A
What
what
I
didn't
want
to
do
is
to
recommend
use
of
this,
and
then
people
just
have
lots
of
used
lots
of
different
values
in
the
name.
So
you
know,
a
changing
facility
could
be
change
facility,
changing
facilities,
changing
room,
changing
rooms,
so
it
wanted
to
have
some
more
specific
types
to
make
it
easier
for
people
to
aggregate
and
filter
on
the
data
consistently.
A
So
what
the
specification
will
include
once
I've
revised,
it
is
define
some
new
subtypes
of
location
feature
specification.
The
list
that
we
discussed
on
the
call
was
to
do
the
other
type
for
changing
rooms,
showers,
rubber,
toilets,
lockers,
towels
crash
parking,
maybe
change
equipment
hire
and
then
floodlights.
Although
there's
been
a
feedback
for
Nick
that
maybe
for
the
lights,
he
should
be
handled
separately.
This
is
more
of
a
feature
of
the
place
rather
than
a
separate
II.
A
A
What
I
was
leaning
towards
is
to
go
with
this
list
start
with,
because
we'd
at
least
I
think
we'd
like
three
or
four
people
on
the
call
kind
of
reviewing
that
start
with
that,
and
then
we
can
always
add
more
types
later,
because
this
is
a
pretty
light
by
change
the
specification,
because
this
is
all
existing
schema,
dialog
stuff.
Apart
from
finding
those
new
types
where
the
spec
doesn't
define
type,
then
you
can
still
use
this
style.
You
can
just
still
say
it's
a
location,
feature
specification
and
free
Wi-Fi.
It's
not
like.
A
D
F
D
A
Okay,
the
so
those
are
the
ones
that
have
been
in
the
spec.
There
is
there's,
there's
a
number
of
other
open
proposals,
this
one
that
came
from
AMD
in
special
requirements,
I
need
to
put
in
the
I.
Don't
we
can
immediate
aside
to
stay
because
we
don't
have
the
relevant
people
here,
but
I've
got
I'm
going
to
update
the
issue
with
that
we're
getting
close
to
end
of
time
but,
as
I
said,
I
said,
I
would
show
the
issue
around
tightening
up.
F
A
Won't
because
we,
because
we
touched
on
it,
I
wanted
to
briefly
just
draw
your
attention
to.
We
don't
have
to
kind
of
discuss
all
of
it
now,
but
draw
your
attention
to
issue
78,
which
is
about
as
a
proposal
to
restrict
the
usage
of
some
of
the
properties
to
be
more
consistent.
So
there
are
a
number
of
properties
in
the
spec
at
the
moment
that
can
have
different
values.
They
can
be
string,
they
can
be
an
object,
they
can
be
array
of
strings
array
of
objects.
A
Some
people
are
using
strings
when
another,
so
using
numbers
so
that
all
of
that
flexibility
comes
from
schema.org
and
today
we've
been
happy
to
use
that,
because
it
provides
people
with
some
flexibility
in
how
they
publish
their
data.
However,
we
know
that
we
need
to
improve
data
quality
over
time,
and
the
only
way
to
do
that
really
is
to
start
to
restrict
those
values
to
be
a
bit
more
prescriptive
about
what
we
expect
people
to
to
do
so
like,
for
example,
moving
to
always
using
an
array,
even
if
it's
got
a
single
value
for
properties.
A
That
might
reason
you
have
multiple
values
makes.
You
means
you
can
access
it
consistently
in
code,
so
what
I've
done
in
this
proposal
is
I've
identified.
Ten
suggested
ten
changes.
These
aren't
two
specific
properties,
the
ten
things
that
we
can
put
into
into
the
specification
to
start
styling
this.
A
Properties
with
with
multiple
that
will
have
multiple
values
must
always
be
a
raise,
so
activity
would
always
been
array.
If
a
property
can
have
different
values,
string
or
objects,
then
we
should
say
what
a
preferred
default
is.
So
we
don't
just
leave
it
open
to
anyone
to
choose
we
kind
of
say
this
is
what
you
should
do.
A
Including
time
zones,
duration
properties
should
be
durations,
emitting
null
values,
admitting
empty
arrays,
meeting
empty
strings,
making
sure
the
type
is
always
required
and
there's
stuff
around
URL
and
ID.
Now
each
of
these
we
can
probably
have
a
whole
debate
around
so
I'm
just
drawing
attention
to
it
and
it'd
be
good
to
get
some
feedback
on
general
principles
on
here
and
then
I've
got
a
to
do
in
the
proposal
to
indicate
which
properties
we
start
to
apply
this
to.
D
A
A
A
So
in
just
we've
got
last
couple
of
minutes
and
that's
just
the
things
people
want
to
raise
on
the
booking
work.
So
we've
been
given
regular
updates
to
that.
That
haven't
really
been
any
substantial
changes
to
the
specifications
since
we
spoke
at
last.
What
we
are
in
the
process
of
doing
is
moving
from
the
Google
Doc
that
is
currently
holding
version
0.4
in
I'm,
going
to
move
that
into
our
standard
specification
template.
So
it's
a
web
page
as
part
of
doing
that.
A
We
then
will
also
have
a
separate
issue
list
in
github
so
that
we
can
stay
on
top
of
discussions.
There
is
already
a
set
up
a
project
board
in
the
github
repo
we'll
be
using
to
hold
the
spec,
which
is
the
open,
API
repo
start
to
file
a
bunch
of
issues,
tasks
and
things
to
do
in
order
to
leave
that
forward.
So
in
future
calls
we'll
be
focusing
on
that,
and
the
other
thing
that
I
wanted
to
highlight
is
we've
been
as
well
as
the
gable
dot.
We've
been
sharing
a.
A
Swagger
specification
we'll
keep
that,
but
it
will
be
a
won't,
be
the
normative
version
of
the
spec
which
I'm
poor
everything
in
the
main
spec.
But
this
is
useful
for
people
to
navigate
so
we're
going
to
try
to
keep
up
to
date,
but
within
here
there
is
now
much
more
than
just
booking
and
I
want
to
make
sure
that
the
booking
specific
bits
are
clearer.
A
So
there
is
mixed
in
amongst
the
end
points,
arounds,
customers,
orders
etc.
This
stuff
is
what
I've
been
calling
a
opportunity:
data
API,
it's
a
API
endpoints
to
get
lists
of
locations
to
get
to
search
for
sessions,
to
search
for
activities
that
is
going
to
get
broken
out
into
a
separate
spec,
because
it's
not
about
booking
so
will
end
up
having
a
separate
opportunity
to
API
spec
that
will
cover
those
endpoints.
We'll
probably
just
keep
one
swag
a
document.
A
That's
got
all
of
this
stuff
in
it
just
to
make
it
easy
reference,
but
in
terms
of
kind
of
specifying
the
behavior
around.
That
is
too
much
to
do
in
one
document,
so
moving
that
make
that
bit
more
manageable
and
also
how
people
kind
of
focus
people's
attention
on
the
bits
that
they're
most
interested
in
so
the
goal
is
to
have
the
what
will
be
0.5
of
the
booking
expect
in
a
template
by
4th
of
May.
It's
not
gonna,
be
any
substantial
changes
to
the
content.
Just
probably
some
just
minor
revisions
to
the
structure.
A
I
didn't
mean
the
second
for
mayhem
in
four
nights
a
week
usually
fixed
the
9th
of
May.
It
clashes
with
the
elevat--
Kampf,
so
I
need
to
reschedule
it.
So
I'll
send
an
email
around
to
the
mailing
list
and
see
if
people
people
can
would
prefer
to
do
the
call
earlier
or
later
in
the
week
or
whether
we
just
choose
to
skip
one
just
see
what
works
for
people
and
just
confirm
the
focus,
because
we've
got
a
couple
of
different
threads
of
activity.
We'll
have
to
decide
the
best
way
to
organize.
A
These
calls
ongoing
whether
we
want
to
trying
to
cover
a
bit
of
both
in
each
one
or
whether
we
want
to
more
closely
themed
each
corner
edge.
For
example,
booking
versus
opportunity
model
I
suspect
that,
because
there
are
lightly
different
audiences
that
we
might
want
to
just
focus
the
cause
but
I'm
keen
to
make
sure
that
we
get
into
the
process
of
doing
this
kind
of
review
before
we're
doing
point
releases
of
specifications
to
make
sure
that
we're
giving
everybody
up
as
many
opportunities
as
possible
to
feed
in
before
stuff
gets
into
them
released
versions.