►
From YouTube: OpenActive W3C Community Group Meeting / 2018-11-21
Description
A public hangout for members of the OpenActive W3C Community Group.
https://w3c.openactive.io/meetings/2018-11-21
A
A
A
A
A
Essentially,
we've
identified
a
an
open
source
tool
for
managing
taxonomy
and
similar
controlled
vocabularies,
which
we
have
set
up
as
a
demo
and
populated
it.
With
a
current
version
of
the
activity
list
and
the
outcome
of
the
meeting,
which
was
really
just
a
kind
of
demo,
the
features
was
I
think
everyone
feels
comfortable
that
that
will
allow
us
to
share
the
work
of
managing
the
list
across
community
so
to
move
that
forward.
A
We're
going
to
go
ahead
and
set
up
a
live
version
of
the
tool
and
identify
a
few
people
who
conform
part
of
the
initial
editorial
team.
So
that's
people
from
a
few
different
organizations
across
the
sector
who
have
already
provided
some
help
on
curating
the
initial
list
and
then
we're
going
to
look
slightly
wider
and
get
some
input
from
other
people
on
the
content
of
structured
list,
but
I'm
pretty
confident
now
that
we
can
move
that
forward
quite
quickly
and
that
the
community
kind
of
manage
the
content
and
publication
schedule
of
that.
A
So
I
will
do
some
more
updates
on
that
over
the
coming
weeks
as
things
move
forward,
but
I
just
want
to
make
sure
everyone
was
aware
of
those
discussions
and
any
any
questions
on
that
before
I
move
on
to
the
booking
stuff:
nope.
Okay,
but
shout
if
there
is
okay.
So
that's
that's
progress
on
the
activity
list,
so
the
last
call
we
were
talking
about
the
revised
the
revised
kind
of
workflow
for
the
booking
API,
which
Nick
and
I
have
discussed
since
then,
and
our
plan
for
moving.
That
forward
is
to
do
some.
A
So
that's
that's
promising,
but
a
bit
we
didn't
really
get
time
to
discuss
was
how
we
handle
provider
initiated
cancellations.
So
we
have
a
requirement
so
at
the
moment,
within
the
the
booking,
API
and
a
broker
can
cancel
a
booking
on
behalf
of
the
user.
So
there
is
a
mechanism
to
do
that,
but
in
reality
there
will
be
occasions
where
provider
needs
to
cancel
a
booking.
A
Perhaps
somebody's
ill
or
an
event
has
to
be
rescheduled
or
cancelled
father,
and
so
there
needs
to
be
a
way
for
brokers
to
be
to
track
whether
those
cancellations
have
happened
outside
of
their
application.
So,
on
the
on
the
platform
side
and
that's
important
because
then
they
can
issue,
initiate
refunds,
do
any
customer
updates
that
they
need
to
do.
We
have
the
current
API
draft.
A
The
first
is
a
kind
of
simple
polling
setup,
so
that
would
require
brokers
to
regularly
check
or
so
reg
Lee
do
a
request
to
a
booking
platform
to
see.
If
there
have
been
any
cancellations,
if
they,
if
they
see
that
there
is
a
been
a
status
update
for
an
order,
then
they
can
get
the
any
extra
information
they
need
by
doing
the
requests
to
the
to
the
individual
order.
A
But
the
the
owners
here
will
be
on
the
broker
to
monitor
and
keep
polling
just
in
case
there
are
any
notifications
and
then
they
can
take
appropriate
action.
So
the
requirement
would
be
for
the
booking
platforms
to
expose
an
extra
API
endpoint
to
make
this
or
similar
information
available
to
brokers.
C
Can
I
ask
a
question
that
is
Ross
for
Mike
son
ledger?
Yes,
sure
so
would
be
the
response,
be
any
cancellations
from
bookings
that
that
broker
has
made.
So
would
it
be
a
list
or
would
it
be
an
individual,
a
polling
for
a
particular
person
or
just
anything
that
they
have
booked
that
has
been
cancelled?
Is
there
a
time
frame
on
that
yeah.
A
It's
just
a
good
question,
so
my
assumption
would
be
and
I've
got
not
a
full
proposal,
but
this
item
would
heat
up
the
motor
cover
afterwards,
but
the
my
assumption
is
that
the
broker
would
be
requesting
to
a
generic
endpoint
and
they
would
just
get
a
list
of
updated
orders
that
are
relevant
to
them.
So
it
wouldn't
be
all
orders
in
the
platform.
It
would
just
be
a
list
of
orders
that
have
been
placed
by
that
particular
broker:
right:
okay,
but
in
terms
of
windowing,
etc.
A
Something
that
we
can
we
can
discuss
and
but
soap
owning
is
one
option.
The
other
option,
which
is
what
we've
documented
so
far,
is
webhook.
So
here
it
kind
of
changes
things
around
a
little
bit,
so
the
booking
platform
notifies
the
broker
every
time
either.
Every
time
an
order
is
cancelled,
or
perhaps
it
does
it.
You
know
once
an
hour
or
once
a
day
and
you
get
a
update
for
it
for
a
batch.
But
basically
it's
a
push
model
most
of
the
platform
pushes
notifications
to
the
broker.
A
So
we've
had
had
some
feedback,
both
in
earlier
calls
and
on
github,
just
to
kind
of
summarize
that
whatever
we
choose,
there's
some
extra
implementation
required,
but
I
think
the
feeling
was
that
the
web
hooks
were
slightly
more
complicated
and
added
extra
overhead.
Both
sides,
because
a
for
example,
a
broker
will
need
to
expose
an
API,
probably
a
secure
API,
that
a
platform
can
make
requests
to.
So
they
will
have
to
be
offering
a
Bezier
managed
API
for
the
platforms
that
they're
working
with
the
other
bits
of
feedback
we
had
with.
A
A
Yeah
I
mean
looking
around
as
well
other
other
bits
of
feedback
where
people
have
been
implementing
web
hooks.
They've
been
lots
of
concerns
over
you
know:
failure
that
brokers
were
brokers
or
people
who
were
supposed
to
be
receiving
note,
webhook
notifications
not
properly
managing
or
scaling
their
endpoint
to
deal
with
notifications
as
they
come
in,
but
that
I
mean
there
are
some
positives
to
web
hooks.
Firstly,
the
notifications
can
be
faster
because
they
could
be.
A
You
know,
potentially,
as
stasis
updates
take
place,
and
there
may
be
other
types
of
notification
that
we
need
to
pass
between
brokers
and
platforms.
Any
be
a
web
could
provide
a
generic
mechanism
for
that,
and
but
you
know
it
felt
I
think.
On
the
whole,
it
felt
like
people
were
bit
more
concerned
about
using
web
hooks
in
terms
of
overhead
failure
modes,
et
cetera,
so
I
think
what
we're
going
to
do
is
revise
the
specification
to
focus
on
and
polling
as
a
third
option.
A
D
Can
I
just
ask
a
quick
question
on
this
yeah
so
just
in
terms
of
implementation,
I'm,
just
thinking
that
it's
you
can
actually
get
in
standards
queues.
So
if
you're
gonna
send
a
whole
chunk
of
things
off
to
a
web
hook
and
it's
not
reliable
deliver
it,
then
you
can
put
it
in
a
qm
smq
or
something
like
that,
and
that
makes
the
architecture
very
simple.
If
how
are
we
going
to
poll,
then
I
think
you've
potentially
got
to
build
quark
of
architecture
in
to
make
that
to
make
that
work.
A
Yeah,
so
so,
if
we
think
about
what
you
would
need
for
a
web
hook,
then
I'll
know
on
the
on
the
platform
side,
then
using
a
queue
to
manage
outgoing
requests.
It
seems
fine,
you
know
be
a
way
to
to
handle
that
you
will
need
to
handle
I
mean
I
know
some
queuing
systems
will
do
retry
as
of
deliveries,
but
I
think
you
would
also
need
to
have
a
fallback
of
somebody
being
able
to
check
for
missed
mister
updates,
I
think
for
polling,
I.
A
Think
there's
only
two
bits
of
information
you
need
in
order
to
be
able
to
generate
a
list
of
notifications.
It's
the
I
guess
three.
The
current
state
is
of
the
order
which
I
think
you'll
be
tracking
anyway
date
of
last
update
to
the
order
or
state
change,
depending
on
the
granularity
you
want
to
capture
and
which
probe
broker
place.
That
order,
which
I
think
you
will
need
anyway
in
order
to
monitor
who's,
placing
orders
in
your
system.
A
So
I,
don't
think,
there's
an
extra
requirement
in
terms
of
your
big
extra
comment
in
terms
of
data
for
either
option
really
with
a
web
hook.
You'll
also
have
to
manage
know
what
the
end
point
is:
we'll
have
to
also
standardize
what
the
security
or
some
recommendations
about
how
those
endpoints
are
secured,
as
well.
All.
E
E
Based
on
that,
that
could
get
quite
big
I
mean,
so
my
initial
response
would
be
one
month
if
somebody
can't
process
so
both
of
broken
process,
those
within
a
month
or
maybe
or
maybe
two
months
just
to
account
for
things
like
people
checking
credit
card
details
and
that
sort
of
thing
you
know
you
can
see
if
it
ran
for
a
few
months
and
there's
been
a
few,
can
take.
You
know
quite
a
few
cancellations
over
certain
periods,
but
that
list
is
gonna.
E
F
F
That's
it
but
you're,
obviously
filtering
per
broker,
and
what
that
gives
you
is.
It
means
you
can
retrieve
the
latest
state
of
all
as
they
come
through
and
choose
to
only
pick
up
on
those
orders
that
have
a
state
change
that
you
care
about
or
or
whatever
it
was
thinking
about.
If
we
did
it
in
an
extensible
way,
so
that
you
basically
have
an
orders
endpoint
rather
than
like
a
like
I
polled
you,
you
hold
the
orders
and
point
rather
than
pulling
a
notifications
endpoint.
F
F
The
same
is
what
people
do
for
our
PDE
feeds,
where
they
have
the
orders
table
and
just
the
simple
sequel
carriers
you
know,
filter
where
broker
equals
x
and
date
is
less
than
whatever,
and
that
gives
you
just
a
slice
of
the
orders
that
changed
since
then.
So
there
are
very
simple
implementation,
whereas
if
we
have
notifications
that
requires
us
to
build
another
walk
Rochus
to
a
certain
booking
assistants
build
another
table.
D
E
F
F
Yes,
factory
would
allow
the
broker
to
synchronize
its
state
with
with
the
booking
system,
in
the
same
way,
whether
suppose,
the
question
there
is,
if
we
did
use
our
PDA
and
I
think
I
think
yeah,
that
the
main
thing
is
everyone's
gonna
be
familiar
with
it
and
have
implemented
it.
So
they'll
know
what
they're
doing,
as
you
say,
whether
we
would
include
the
payload
in
there
as
well,
whether
we
would
just
include
the
ID
and
then
have
call,
but
you
know,
have
the
consumer
then
call
back
to
get
the
latest
order.
F
So
basically
do
we
do
we
because
at
the
moment,
I
don't
think
the
from
the
last
proposal?
Revision.
I,
don't
don't
know
if
we
have
a
get
order,
I,
don't
think
we
have
a
get
order.
End
point:
oh,
we
don't
have
the
need
to
have
one,
because
when
you've
posted
the
order,
you
get
the
order
back
straight
away,
but
you
don't
necessarily
need
to
then
get
it
subsequently,
although
we
could
have
it
no.
A
F
A
So
for
the
for
the
opportunity,
API
we're
going
to
need
to
have
lists,
be
able
to
share
lists
of
things
as
well.
So
I
was
lean
toward
making
it
consistently
what
we
might
use
there,
rather
than
our
PDE,
but
the
basic
mechanism
of
having
a
list
of
items
and
then
a
next
page
link
would
be
consistent
across
them.
There
just
be
some
slight
differences
in
the
list.
Why
I
would
originally
thinking
around
what
the
Jason
structure
would
look
like,
because
our
PD
currently
is
not
json-ld.
F
Wonder
there's
an
opportunity
here
to
improve
our
PDE,
maybe
or
I'm
just
thinking
in
terms
of
the
next,
because
if
we
do
paging
without
using
modified
date
and
ideas,
our
PD
does
we're
going
to
be
in
well.
It
was
all
the
problems
of
having
to
page
through
and
create
pages
and
maintain
them
all
that
stuff,
whereas
if
you
just
have
like
our
PD,
that's
just
the
windows
defined
by
those
parameters.
Then
you've
got
a
really
simple
query
and
to
return
the
page
yeah.
A
A
F
Well,
I
guess
what
I'm
thinking
is:
we've
already
got
validators
for
our
PD
and
people
will
be
have
have
their
own
implementations.
So
I,
don't
know
if
this
stage
in
in
booking
1.0,
whether
it's
worth
are
we
basically
doing
too
much
by
trying
to
bump
our
PDE
I.
Think
you're
right,
we
probably
do
need
to
look
at
I,
think
is
even
already
a
proposal
in
the
aqua
DM
github
about
it,
a
bumping
it
to
the
HSN,
LD
compliant
and
there's
a
bunch
of
considerations
about
how
we
would
do
that.
B
A
Lines
a
json-ld
kind
of
paged
set
of
collections
and
that's
what
we
were
discussing
using
for
the
opportunity,
API,
that's
kind
of
what
I've
borrowed
from
here.
My
assumption
was
that
our
PD
would
go
in
that
same
direction
as
well,
so
I'm,
less
concerned
that
we'll
end
up
with
slightly
different
mechanisms.
F
Well,
for
example,
our
PDE
has
the
items
in
the
collection
have
modifydate
an
ID
as
particular
properties
and
they're.
Quite
they
have
a
particular
meaning.
So
there's
discussions
to
have
about
what
they
look
like
in
json-ld
land,
whether
they
still
exist
in
the
same
object,
whether
they,
whether
there's
a
parent
object
like
the
current
ears,
which
is
the
item,
and
then
then
the
data
exists
within
the
item
and
also
some
considerations
about
the
modified
date
and
how
we
make
that
consistent
across
the
various
places
you
might
get
deciding
from.
F
So
you
might
get
an
item
you
might
get
an
update
from
the
our
PD
feed.
You
might
also
get
one
for
the
opportunity
API.
You
might
also
get
one
from
notifications,
whatever
different
places
so
making
that
consistent,
so
that
you
can
resolve
when
you
have
a
new
object
from
one
of
those
places.
You
can
tell
it's
a
newer
version,
so
you
could
do
something
with
that.
You
know,
compare
it
to
the
others,
etc.
F
But
I
guess
what
it
probably
comes
down
to
is
that
yes,
I
think
Hydra
is
a
good
good
thing
to
use
and
I
think
that's!
That's
almost
what
some
of
that
early
work
you
already
uses,
but
again
it's
the
same
question:
if
what
is
it
the
right?
Is
it
the
right
way
around
to
do
it
like
this?
Basically,
our
we
we
and
why?
If
so,
why?
What's
the
what's
the
reasoning
for
trying
to
get
this
in
here,
rather
than
doing
it
across
the
piece
so.
A
My
rationale,
I,
would
be.
We
tried
to
scope
the
changes
to
the
thing
that
we're
actively
working
on
so
rather
than
try
to
get
booking
over
the
line
and
then
get
a
new
edition
of
our
PDE
and
people.
Adopting
that
that
we
focus
on
keeping
the
book
expect
as
self-contained
as
possible
and
introduce
the
the
end
point
into
here.
F
I
suppose
but
I
I
guess
what
I'm
wondering
is.
Is
that
does
the
half-way
work
so
isn't?
Isn't
options
really
use
our
PDE,
as
is
for
everything,
and
because
it's
it's
known
and
we've
got
that
you
know
everyone
will,
will
have
that
they've
already
built
some
stuff
to
implement
that
and
process
that
on
the
but
on
both
sides
or
or
change
RPG,
so
that
it's
improved
but
using
something
that
isn't
our
PDE
right
now
and
isn't
yet
either
our
PD
to
is
using
a
isn't
that
kind
of
divergent
from.
A
A
There
is
some
wording
in
the
spec
about
how
to
consistently
order
that
list
and
the
behavior
of
the
items
in
that
list
of
when
statuses
change
and
which
bits
were
people
think
we
should
be
using
to
inform
this
particular
piece.
Is
it
just
that
we've
got
a
simple
paging
mechanism,
or
do
we
think
that
everything
that's
currently
specified
in
our
PD
will
also
apply
here.
D
C
D
D
It
may
well
be
that
we
want
to
just
put
the
RG
r
DB
pagination
protocol
wrapping
around
something
in
the
booking
api,
and
one
thing
I
am
concerned
about,
is
that
you
know
we
don't
need
to
just
jump
off
and
get
more
complexity
and
because
we're
struggling,
I
say
stripping
us
the
wrong
word.
I
mean
the
whole
process
is
taking
a
while
and
I
think.
If
we
keep
it
simple.
D
As
far
as
we
can,
then
that's
better,
but,
as
I
said,
I
was
seeing
the
the
what
Nick
suggests
meant
was
having
a
using
the
syntax
that
page
protocol
to
pull
things
back
and
what
the
payload
was
would
be
kind
of
cancellations
or
changed
orders
or
whatever
I'm,
not
quite
sure.
If
that
made
sense.
But
that's
that's
what
I
thought
you
meant.
F
So
I
guess
I
guess
the
simplicity
point
I
think
there
would
be
I
definitely
agree
with
that
and
yes,
I
think
I.
Think
for
me
from
an
implementation
perspective
using
the
schema
that
exists
from
our
PD
is
probably
the
simplest
way
forward
without
defining
anything
new
at
this
stage,
just
in
terms
of
basically
using
it
using
a
thing
like
that,
we
have
the
snow
in
the
works
and.
F
Yeah
and
then
I
think
in
the
future.
We
should
we
should
absolutely.
We
should
look
to
change
change
that
and
change
that
all
together,
I
expect
I
suppose
if
we
are,
if
we
do
do
that,
what
we
should
do
that
when
we
do
that,
what
that's
going
to
impact-
and
so
everyone's
gonna
have
to
do
an
update
across
quite
a
bit
of
well
I
mean
everyone's
gonna
have
to
change
their
feeds,
I'm
a
booking
as
part
of
that
kind
of
makes
sense,
because
most
people
will
be
using
both.
A
I'm,
like
yeah
I,
guess
I
guess
they
will
possibly,
but
though
I
can
also
see
systems,
they
won't
only
be
just
using
the
opportunity,
API
and
booking
so
I
think.
The
reason
why
I'm
hesitating
a
little
bit
about
saying
use
our
PD
is.
It
means
that
we'll
have
a
API
that
will
be
using
json-ld
throughout
user
consistent
model
and
then,
for
one
end
point
will
be
right,
relying
on
it
on
a
spec
of
which
I
think
a
chunk
of
it
is
not
relevant.
A
F
So
the
only
there
there's
a
there's
only
one
reference
to
the
events
stuff,
which
is
which
is
in
the
payload
recommendation,
but
I
think
generally,
when
we
get
into
looking
at
how
paging
works,
you
do
need
to
use
modified
date
and
ID
together
if
you're
doing
paging
in
the
same
way,
because
if
you
have
multiple
notifications
at
exactly
the
same
time,
they
won't
have
a
deterministic
ordering
otherwise
and
then
and
then
the
same
arguments
follow
so
ok.
So
right
we
need
to
minister
ordering.
F
Therefore
you
have
modified
an
ID,
but
what,
if
you
have
an
incrementing
integer
such
as
is
the
case
in
some
systems
like
sequel
server,
then?
Can
you
use
that,
in
which
case
the
change
number
comes
in,
so
that
you
can
use
that
instead
to
simplify
your
implementation
further
and
deleted
items?
It's
the
same
when
notifications,
you
probably
want
to
remove
them
at
some
point
from
that
feed,
so
you
probably
wanna
delete
items.
There's
not
this
spec
is
quite
light,
so
I
don't
know
what
else.
F
There
is
really
that,
where
there's
a
last
page
required
because
you'd
need
a
spec
to
say
when
you'll
get
to
the
end
of
the
feed,
what
happens?
Next?
How
do
you
deal
with
that?
That's
in
there
I
think
everything
in
stream
filtering,
which
is
which
is
a
bit
of
a
minor
thing,
is
for
the
only
thing
that
is
edge
case
here:
content
type
news,
Jason,
yeah,
how
to
poll
recommendations
about
polling
and
all
that
stuff.
The.
A
Whole,
it's
got
the
whole
payload
section,
which
is
potentially
not
relevant,
which
is
where
we're
sorry
there
well
all
of
the
stuff
around
date
and
time
formats,
all
of
this
extra
stuff,
which
is
not
really,
which
is
which
was
designed
originally,
where
to
rely
or
the
other
adjacent
structures
in
there.
Well,
the
date
and
time.
F
Formats,
probably
the
only
one
really
if
you
go
to
the
example,
I
think
there-
probably
that's
pretty
easy
thing
for
point
7,
so
you
can
see
there
there's
data
inside
which
there's
the
json-ld
and
outside
date,
so
there's
state
kind,
ID,
modified
and
items,
and
next
so
really.
What
we're
really
talking
about
here
is
next
items.
Stay
kind,
ID
modified.
F
What's
in
data
is
wealth,
potentially
an
order
object
with
an
ID,
I
guess
or
whatever,
whatever
Jason
LD
we
want
to
put
in
there,
but
this
spec
doesn't
explicitly
doesn't
include
nothing
to
do
with
what's
in
data,
speckies
is
all
it
talks
about.
Is
the
items
aren't
stay
kind
ideas,
modified
stuff,
yeah.
A
F
A
I
understand
that
the
bit,
though,
was
that
wasn't
wasn't
convinced
that
we
needed
even
this
payload
option,
because
I
think
the
model
that
we
were
going
talking
about
from
the
opportunity
API
was
to
have
more
of
a
link.
You
get
a
list
and
then
you,
you
do
further
requests
to
get
extra
information.
Rather
than
embedding
things.
F
Like
that,
in
the
data
right
of
the
previous
side,
you
on
the
on
the
side,
you
could
put
the
order
notification
object
in,
and
that
would
be
with
the
order
in
order
status,
and
that
would
be
that
you
don't
need
modified,
because
that's
already
in
the
in
the
items
block
outside
just
be
stay
kind.
Id
modified
data
would
then
contain
those
three
properties.
A
F
Know
you
don't
like
it
is
it's
not
json-ld.
That's
that
I
I
get
that
totally
get
that
and
I
think
we
do
need
to
update
it
to
be
json-ld
a
combined
at
some
point,
but
that's
I.
Suppose
it's
the
question
of
whether
we
have
two
divergent
things
now
that
do
you
something
similar
or
whether
we
have
the
same
thing,
and
so
it's
always
consistency
versus
style,
I,
suppose
and
I
totally
see
your
style
point
on
the
importance
of
you
know,
Jason,
Aldean
and
and
that
working
obviously
the
blocks
inside
there
are
Jason
LT
still.
A
A
F
Page
data,
but
in
the
opportunity
of
guide,
there's
there's
no!
This
is
a
notifications,
there's
a
synchronized,
safe
problem,
all
the
rest
of
the
opportunity
API
from
what
we
discussed
at
least
will
be
query
based
they'll
get
me
the
activities
near
here
or
get
me
the
instructors
whatever
this
is
at.
This
requirement
is
actually
not
opportunity.
Api
court
requirement,
there's
unlikely
to
be
other
things
in
the
opportunity
of
you.
Are
that
involved
notifications?
F
D
B
C
A
F
F
Sure,
yes,
so
thanks
Jamie
and
you
provided
a
really
great
opportunity
to
have
a
discussion
with
an
accountant
yesterday
and
from
that
discussion.
In
addition,
thanks
Melanie
for
helping
with
some
of
the
research
with
other
api's-
and
we
did
a
little
bit
of
so
I-
can
give
you
an
update
on
where
we
got
to
I.
F
Don't
know
if
this
is
where
we
don't
know
yet
landed
on
the
final
decision,
but
it's
also
becoming
clear
that
there
doesn't
seem
to
be
a
single
right
answer
and
even
if
we
talked
to
the
HMRC,
that
only
represents
one
view
in
there
in
the
world
of
different
ways.
This
can
work,
and
so
what
we've
kind
of
landed
on
after
that
and
looking
at
the
other
API
is
and
what
they
do
is
it
seems.
F
F
So
you
you
might
write
as
pretty
sure
to
put
actual
example
in
here,
but
you
might
write
dat
20%
in
the
name
and
in
the
price
you
would
put
the
amount
and
what
that
means
you
can
do
is
in
countries
and
jurisdictions
where
you
have
multiple
tax
codes.
You
can
in
the
name
you
can
put
the
percentage
and
the
type
of
tax
in
there
and
it's
a
string,
so
it
can
use
to
be
literally
whatever
and
then
the
price
is
there,
and
so
that
the
the
amount
that
matters
is
available
as
a
decimal.
F
C
F
F
F
Basically,
the
the
it's
it's
about
line
items
in
the
invoice
so
part
of
the
the
the
earlier
parts
of
the
conversation
as
if
you
just
click
on
the
stripe,
that's
ER
and
if
you
go
down
to
order
somewhere
other
they
go
perfect
order.
Item
and
you've
got
a
description,
see
a
tax
with
a
number
of
tax
and
the
amount
and
currency,
and
so
what
this
is
basically
is
on
the
receipts.
F
So
part
of
the
discussions
I
skipped
over
is
that
the
only
place
the
tax
seems
to
be
required,
at
least
from
our
initial
conversation
is
actually
at
the
receipt
stage
and
even
in
in
the
UK,
you
can
ask
for
a
v80
receipt
separately,
an
out-of-band.
So
the
system
doesn't
necessarily
have
a
requirement
to
produce
it.
F
And
so
that's
what
this
proposal
is
basically
saying
that
we
just
have
line
items
on
the
receipt
and
rather
than
trying
to
over
specify
rates
and
things
like
that
and
does
it
include
v80
or
not
include
v80,
it's
just
the
ability
to
add
tax
line
items
that
means
that
anyone
can
to
connect
them
according
to
what
their
system
is.
Recording
and
yeah.
Sorry
yeah.
C
F
So
we
also
covered
that
topic
and,
although
it's
not,
it
doesn't
appear
to
have
an
impact
on
the
specification
as
such
and
the
difference
between
being
an
agent
and
being
a
tree
seller
in
the
context
of
a
third
party.
Making
a
sale
is
an
important
distinction
and
from
the
conversation
in
most
cases,
it's
it's
the
it's.
The
agent
scenario
that's
likely,
so
the
the
third
party
site
would
be
facilitating
this
transaction,
but
they
wouldn't
be.
So
what
makes
a
reseller
a
reseller?
Is
they
buy
the
squash
court?
F
C
F
G
F
That
question
sorry,
so
the
proposal
at
the
moment
in
from
what
we
talked
about
would
loosely
when
you
make
the
order
or
the
order
quote,
you
basically
say:
I
want
to
buy
these
items
at
the
point.
Where
you
create
the
order
or
order
quote
you
get
back
or
sorry,
you
submit
the
items
you
would
like
to
be
in
the
order
when
you
get
the
order
back.
You
then
have
these
these
v80
line
items
in
that
response,
and
so
for
customers
that
are
not
v80
registered.
F
D
D
F
G
A
Than
C,
it's
a
NIC
to
make
sure
that
understanding
terms
of
the
revised
flow
and
I'm
as
a
breaker
if
I
am
creating
an
order
quote
and
I
need
to
tell
you
whether
I'm
a
person
or
an
organization,
and
then
what
pops
additionally
is
going
to
be.
Some
extra
information
you'll
need
to
know
about
the
user.
At
that
point,
whether
they're
in
the
UK
and
whether
they're
that
registered
and
what
they've.
F
So
the
reason
that
this
yes,
oh
that's,
a
good
point
to
bring
us
to
this
bullet
point.
The
other
thing
that
it
raised
was
that,
of
course,
organizations
are
purchasing
as
well
as
people
and
I.
Think
the
previous
booking
spec
only
really
allowed
the
customs
to
be
a
person
while
in
organization.
But
of
course,
if
you're
an
organization
you're
purchasing
as
local
PTAs
customers
are
and
then
we
should
probably
have
the
ability
to
to
state
your
organization.
F
Get
that
I
kind
of
got
the
sense
from
yesterday.
I,
don't
know
what
you
think
Jamie
that
a
lot
of
this
is
a
kind
of
edge
cases
and
that
they're
kind
of
the
basic
case
is.
We
probably
just
need
of
that
line.
That
says
how
much
has
been
charged
and
then,
if
we
use
a
person,
an
organization
object
that
provides
scope
to
extend
in
the
future
to
include
other
properties
such
as
that
number
and
things
like
that.
But
they
don't
necessarily
it's
unlikely
to
be
there
from
day
one
to
get
something
working.
G
Yes,
I
think
we
spoke
about
that
point
around.
It's
not
a
required
feature
to
issue
the
the
virus
seeped
into
every
booking.
That's
made
I
think
with
respect
to
how
you
could
do
it
through
the
through
the
API.
As
such,
you
would
need
to
say
those
kind
of
the
amount
that's
being
added
on
as
fat
and
that
bat
number
so
it'd
be
quite
good.
Maybe
to
see
what
what
that
response
would
look
like.
F
Leave
you
just
jump
to
that
third
tab.
A
setting
like
this
and
I
started,
putting
together
there's
a
few
options
and
probably
reviews
within
schema,
which
don't
quite
quite
have
this.
Unfortunately.
But
if
you
look
at
line
19
and
if
we
did
something
like
this,
where
we
had
a
order
item
which
could
be
a
v80
inside
that
it
had
currency,
description,
yeah
thanks
amount
and
we
could
have
multiple
of
those
for
a
particular
receipt.
F
F
F
D
A
Yeah
I
have
to
say
Thursday
I,
quite
like
the
fact
that
they've
called
these
I
as
separate
things
just
in
there's
a
model
because
I'm
just
thinking
like
in
the
way
that
stripe
have
it
we'd
have
to
also
just
if
we
went
that
way.
We'd
have
to
make
sure
that
the
things
like
being
able
to
patch
or
update
and
order
you
know.
So
we
can't
just
remove
the
tax
item
that
there
are
some
things
that
I
just
not
beautiful.
F
F
D
F
F
D
F
C
D
E
D
F
A
Okay,
thank
you.
I'm
gonna
wrap
up
the
course
tonight.
I
think
he's
already
gone
the
we
our
next
call
is
on
the
fifth
of
December
wants
to
check
out
what
people
would
like
to
discuss
there.
Should
we
continue
further
on
the
booking
spec
or
are
there
other
bits
of
standards
work
that
we
should
make
some
time
for
so
maybe
small
time
for
activity
lists
any
preferences.
F
Think,
speaking
for
the
people
not
present
I
think
I
think
booking
is
is
the
thing
that
people
are
usually
care
less
of
the
attacks.
Hence
the
lack
of
attendance
today,
because
obviously
sorted
no
one
actually
cares
that
much
about
how
it
sorted,
I.
Think
if
we,
if
we
have
another
call
in
the
fifth
and
if
we
aim
to
get
a
proposal
for
them
ready
we're
sorry,
a
revised
spec
ready,
which
includes
the
new
flows,
includes
the
new
approach
for
cancellations
and
a
suggestion
on
tax
and
then
so.
It
sounds
like.