►
From YouTube: OpenActive W3C Community Group Meeting / 2018-07-18
Description
A public hangout for members of the OpenActive W3C Community Group.
Agenda: https://lists.w3.org/Archives/Public/public-openactive/2018Jul/0005.html
For more information visit: https://www.openactive.io/w3c-community-group.html
A
A
So
it's
just
general
states
of
things,
so
those
have
been
on
the
mailing
list.
Just
like
we've
seen,
we
published
an
updated
after
the
booking
spec
point
six
draft,
which
now
has
a
few
more
details.
In
a
few
places
there
was
some
missing
content
around
refunds,
cancellations
which
is
now
there,
though,
is
know
about
booking
free
events
and
some
initial
proposals
around
how
we
clarify
what
terms
or
conditions
applied
during
booking.
So
that's
they're
ready
for
comment
about
a
couple
of
minor
bits
of
feedback
on
the
spec
so
far,
but
it
needs
more
review.
B
A
Think
that
others
can
pitch
in
on
that.
The
next
round
of
work
is
to
just
check
to
see
how
facilities
fit
in
with
the
API
I
think
it's
going
to
be
fairly
straightforward,
but
Chris
who's,
leading
that
spec
work
is
this
week
and
then
the
other
thing
I
realized
that
we
need
to
think
about
is
how
a
criminal
defense
book
abour.
So
there's
a
pozer
that
I
circulated
a
while
ago
about
how
we
URL
templates
into
schedules
so
that
people
can
front
build
the
URLs
and
also
the
API
endpoints
for
those
events
from
those.
A
A
B
Luke,
sorry,
is
it
worth
you
just,
and
it's
just
doing
a
brief
thing
about
the
conformer
that
we're
planning
to
what
you're
planning
to
create
so
that
everyone's
aware
of
that
yeah,
so
I
mean
hasn't
been
much
designed
yet,
but
yeah
we
do
intend
to
build
a
something
on
top
of
the
validator
that
is
presently
being
built.
That.
B
B
B
B
A
A
B
A
A
A
Some
of
the
work
that's
gone
about
booking,
so
it
felt
like
it's
a
kind
of
meaningful
chunk
of
things
to
try
and
move
move
forward,
so
I
want
to
try
and
get
some
revisions
full
of
these
things
into
the
respect
of
next
week,
and
what
I
wanted
to
focus
on
today
was
this
first
proposal,
which
is
issue
78.
So
far,
this
a
little
while
ago,
I
haven't
had
any
detailed
feedback
yeah.
A
Well
tell
people
well
clearly
what
they
need
to
fix
feed,
rather
than
presenting
them
with
further
options.
So
the
the
meat
of
the
proposal
is
a
set
of
basic
rules
that
wanted
to
inform,
rethinking
through
bits
of
the
spec,
so
I
was
going
to
do
is
kind
of
go
through
those,
so
we
can
have
a
chat
about
them
and
then
separately
I've
got
a
spreadsheet
which
has
some
detail,
changes
to
the
data
model
in
light
of
these
rules,
but
also
a
few
other
revisions
as
well.
A
So,
let's,
let's
go
through
those
screens
slightly
larger,
so
it's
easier
to
read
so
give
me
feedback
as
we
go.
Some
of
them
are
pretty
uncontroversial.
Some
of
them
a
lot
needs
a
bit
more
thought.
So,
first
one
is
removal
of
null
values,
so
no
empty
properties
right
so
just
like
having
a.
If
you
can't
fill
in
a
property,
don't
include
it.
A
A
We
know
that
I
think
there's
some
some
foods
that
have
this
any
push
back
on
that
should
I
keep
reading.
Until
you
have
a
you
disagree,
a
bit
way
to
next.
One
I
think
he's
on
controversial
number
should
be
numbers
not
strings,
so
coordinates
attendee
numbers
prices,
everything
there's
numeric
should
be
adjacent
number
rather
than
a
string.
B
The
number
four
sorry
prices
are
then,
if
you've
seen
that
the
issue
on
prices
about
the
TDP
situation,
with
the
string
and
some
back
and
forth
on
that
I
think
so.
I
agree
with
what
four
says:
I
just
wanted
to
acknowledge
that
issue
and
the
comment
that
was
made
on
it
about
the
different
languages
from
different
perspectives.
So
I
know
that
some
people
find
it
difficult
to
well
I'm,
not
difficult,
but
it's
a
it's.
A
Yeah,
all
right,
so
I
think
there's
the
uncontroversial
ones
so
number
six,
a
number
of
properties
there
that
can
have
either
single
values
or
could
be
arrays
and
I.
Think
what
we
should
do
is
say
that
they
should
always
be
arrays,
so
anything
so
things
like
activity
image
organizer
could
be
leader
that
all
of
those
should
be
just
say
it
should
be
an
array.
Even
if
the
array
only
has
one
entry
and
then
code
can
be
consistent
in
was
expecting
rather
than
checking
for
a
string
array.
Sure.
B
A
A
So
the
next
one,
the
other
area
of
variation,
is
that
sometimes
we
allow
properties
to
have
a
value
which
is
a
string.
So
obvious
example:
there
is
a
activity
name,
and
sometimes
we
say
it
could
be
an
object.
So
we
can
describe
an
activity
from
an
activity
list
as
only
present
objects.
The
same
is
true
for
image
as
well.
Sometimes
we
just
provide
a
URL
to
the
image
or
you
can
just
use
a
scheme
that
org
image
objects
and
then
include
more
information
about
it.
A
So
what
I
propose
here
is
that
we
should
just
be
clearer
about
what
the
preferred
default
should
be.
So
we
could
keep
the
variation
but
say
we
prefer
objects
over
strings,
so
we
prefer
you
to
use
a
concept
or
an
image
object,
but
it's
fine
to
use
a
string
value
and
personally
I
wrote
this
personally
I'm,
actually
leaning
towards
saying
objects
everywhere,
just
to
again
full
consistency,
and
it
just
becomes
easier
to
new
fields
in
that
would
be
obviously
be
a
stronger
change.
B
B
Larger
than
they
need
to
be
I
mean
I
think
that's
probably
a
bigger
discussion
than
this
yeah
yeah.
The
other
thing,
the
other
angle
on
this
is
I,
know
that
leave
the
opportunity.
Api
stuff
sounds
go,
but
we've
looked
at
it
a
little
bit
because
of
the
facilities
stuff
and
we've
seen
some
issues
on
the
opportunity.
Stuff.
There's
basically
a
question
about.
When
we
come
to
do
filters,
you
want
to
be
able
to
reference
things
consistently
so
that
you
can
filter
on
them
in
the
consistent
way.
B
So,
for
example,
image
dot
URL
contains
something
could
be
a
filter
or
obviously,
if
image,
dot,
URL
or
image,
because
it
could
be,
should
I
mean
like
I,
guess,
there's
that
is
there
a
is
that
the
other
side
of
it
like
it
would
be
bigger.
The
objects
would
be
bigger,
but
at
least
the
values
would
be
inconsistent
places
so
that
things
like
filters
could
reference
them
consistently,
but
I
know.
Is
that
trade-off?
I,
don't
know
if.
A
B
A
B
A
B
B
We
could
do
to
chop
stuff
down,
but
if
you
were
so,
let's
say
that
we
did
that
and
like
there
was
a
there,
was
a
mobile-friendly
part
of
the
opportunity
API
that
gave
you
back
something
without
types,
because
you
don't
need
them,
then
actually
the
number
of
characters
difference
we're
talking
about
for
an
object
with
an
embedded
name,
versatile
preferable.
This
is
not
I
wonder
if
it's
best
to
just
have
objects
for
consistency,
because
otherwise
things
like
filters
are
more
difficult.
A
B
A
A
A
10
is
not
quite
worded
clearly
type
yeah,
so
the
mo
I
think
well.
We
can
look
at
a
spreadsheet,
but
I
think.
Maybe
everything
has
a
title
at
the
moment
which
required
field
there's
only
a
couple
of
subsidiary
objects.
That's
been
used
as
proving
useful
at
the
moment
for
for
some
of
the
validation
stuff,
because
it
provides
a
hook
for
being
clear
about
what
object
he's
been
described
and,
as
we
add
more
types
like
types
of
event,
I
think
it
could
be
more
useful.
B
Yeah
again
in
the
opportunity,
API
and
there's
an
issue
raised
about
field
spec,
so
you
could
request
certain
fields
for
an
object,
which
would
then
mean
that
you
could
request
promising
to
it,
not
include
type,
but
this
isn't
about
validating
and
that
subset.
This
is
about
validating
the
overall
object.
So
yes,
yeah.
A
11
or
12
are
kind
of
related
there's
looking
at
the
spec
I.
Think
generally,
were
we
there's
a
few
inconsistencies
around
use
of
idea
in
URL
and
I
just
wanted
to
try
and
be
clear
about
what
the
rule
was
so
for
ID
I
think
there's
some
key
objects
in
the
data
model
events
places
offers
etc.
That
need
an
ID,
partly
because
we'd
be
useful
to
have
as
a
somebody
harvesting.
A
feed,
for
example,
is
useful
to
have
a
reliable
identifier.
A
You
know
to
merge
data
from
different
sources,
but
also
the
ID
field
is
where
we
are
linking
into
the
api's.
So
the
idea
of
an
offer,
for
example,
the
idea
event
is
being
used
as
part
of
the
booking,
so
I
think
we
just
need
to
be
clear
about
we're.
Expecting
those
there's
only
a
few
lot
of
called
subsidiary
things
like
postal
addresses
or
quantitative
value,
where
I
think
they're
unlikely
to
have
API
endpoints,
so
they
probably
don't
need
that
requirement.
A
But
I
think
this
will
and
similarly
for
URL
things
that
we
expect
to
be
on
the
web
or
need
to
be
on
the
web
should
have
a
URL
set
events,
places
organizations,
image
objects,
there's
a
couple
of
a
couple
of
places
where
they're
not
required
so
I
know
nesib's
I.
Think
I
can
look
at
this
spreadsheet,
but
I
think
for
organization.
I
think
it's
recommended
for
a
person.
People
don't
always
have
the
URL
so
make
it
optional.
B
A
Yeah
so
me,
let
me
jump
over
to
the
spreadsheets
off
those,
so
it
doesn't
like
there's
any
major
issues
with
those.
So
what
I've
done
is
I
just
for
my
my
benefit,
so
I
can
make
sure
I
track.
Everything
I
need
to
revise
in
the
spec
I've,
just
put
all
of
the
tables
of
properties
on
spec
into
a
spreadsheet,
and
then
I've
worked
through
that
and
all
of
the
issues
and
these
proposals
to
see
what
needs
to
be
changed.
So
I've
linked
this
from
the
proposal.
A
So
there's
all
of
the
different
object
types
in
here
along
the
way,
I've
noticed,
there's
a
few
properties
that
I
think
we're
in
common
use,
but
we
haven't
referenced
properly
in
the
spec,
so
I've
included
those
to
make
sure
that
we
revised
them
and
then
I've
gone
through
and
apply
some
changes
so
I
just
filter
it
down
to
what's
changed.
Quite
a
few.
B
A
Think
we're
where
we
are
defining
there's,
so
we
don't
want
our
respective
necessary
end
up
with
it
being
a
complete
clone
of
scheme.
No
productive,
but
I
think
where
we
want
to
be
clear
about
how
we're
using
some
of
them
the
profile
has
properties
and
if
we
are
putting
a
tighter
set
of
requirements
around
formats
types
etc.
A
Then
I
think
we
need
to
document
that,
and
so
the
probably
I
think
the
best
place
to
do
that
is
in
spec
great
so,
but
other
things
we
might
just
put
those
into
the
developer,
documentation
or
other
guidance,
and
they
can
make
their
way
into
spec.
If
and
when
it's
useful
to
do
it
so
for
each
of
the
things
in
the
spreadsheet
I've
marked.
If
it's
changed,
then
I've
put
a
note
about
what
has
changed
and
step
through
it.
A
I'll
come
back
to
the
location
bit
in
a
minute,
so
you
can
see
like
the
first
line
here
for
image,
I'm
saying
that
that
would
be
an
array
now
and
it's
an
array
of
image
object.
Yeah.
This
is
about
strings
if
we
go
to
activity
so
based
on
what
we
were
just
discussing,
then
that
should
always
be
an
array
of
concept.
A
If
you
look
at
say
organizer
and
contributor,
those
can
I
be
an
array
of
the
person,
objects
or
organisations
or
mixed,
and
this
so
that's
an
example
of
where
it'd
be
useful,
to
have
the
types,
because
you
need
to
be
a
distinguish
between
those,
particularly
as
they've
got
quite
a
few
fields
in
common,
just
like
name
URL
ID.
That
kind
of
thing,
so
quite
a
lot
of
these
changes
are
just
based
off
that
always
an
array.
A
There
are
a
few
thing.
A
few
properties
like
age
range
that
I've
bumped
from
being
optional
to
recommend
it,
because
I
think
we
for
the
purposes
of
encouraging
some
consistency,
including
age
range
where
you
have.
It
is
a
good
thing
rather
than
just
saying
off.
You
know
you
don't
have
to
worry
about
it,
because
I'm
just
conscious
that
people
might
just
skip
over
immediately
things
that
are
optional.
So.
B
B
As
in
ads
in
that
there's
I
think
we've
got
two
different
implementations
as
the
enums
right
now.
Some
providers
are
already
using
the
equivalent.
So
schema.org
are
all
HTTP
colon,
slash,
slash,
schema.org,
slash
like
the
minimum
minimal
string
as
a
prefix,
and
we
have
two
different
implementations.
We
have
HTTP
colon,
slash,
slash,
open,
active
dos
slash.
This
is
the
equivalent
of
schema
and
we
also
have
HTTP
colon
slash,
slash,
WWE
active
die.
B
A
A
B
Something
else
sorry
of
13-14
organizer
is
generally
organization
and
contributors
generate
person.
I,
don't
know
if
we
want
to
recognize
that
as
a
preference,
as
you
were
suggesting
with
others
and
also
leader,
is
generally
a
person
because
of
how
what
those
things
are
in
those
contexts.
But
I
don't
and
I'm,
not
sure
if
that's
useful,
to
recognize
that.
A
B
It's
almost
like,
if
there's
a
leader
of
the
event
at
the
event,
then
that's
where
they're
a
leader
there
are
more
people
so
generally,
if
there
are
several
other
people
responsible
for
the
event,
then
their
contributors
and
there
so
there's
one
leader
or
sometimes
two
and
then
there's
several
contributors,
but
they're
all
people,
and
then
the
organization
I
think
the
way
it's
defined
in
the
spec
actually
in
the
words
are
that
the
organization
are
ultimately
responsible,
for
the
event
is
what
the
organizer
field
is
she's.
Obviously,
a
specific
thing.
B
It's
just
Pro,
it's
just
organizer
and
then
I
guess.
The
question
for
organization
is:
is
organize
that
always
an
organization
I
suppose
you
can
have
it
their
events.
So
maybe
we
do
want
to
have
a
person,
but
then
my
question
would
be
semantically.
Is
that
person
then
the
leader
rather
than
the
organizer,
if
there's
just
it?
So
if,
basically,
the
only
situation,
you
wouldn't
have
an
organizer
as
an
organization
running,
it
is
a
kind
of
jumpers
for
goalposts
style.
B
You
know
ad-hoc
event
but
find
the
right
find
a
player
create
or
something,
and
in
that
case,
would
you
actually
not
put
an
organisation
in
I,
just
wonder
whether
it
would
be
yeah
we?
Basically,
if
you
have
a
if
you
have
a
badminton
session,
that's
been
set
up
by
Joe
Smith
using
fine
to
play,
find
a
player
is
Joe
Smith,
then
the
leader
of
the
session,
rather
than
the
organizer.
B
Yeah
I
can't
see
what
you
mean,
because
it
may
be
that
you
could
say
that
technically
someone
a
person
has
organized
and
that
person
is
slightly
different
from
a
leader
or
a
contributor.
But
in
terms
of
the
state
of
being
useful,
there's
a
there's,
perhaps
anonymous
enough
that
the
type
is
a
more
important
thing
to
have
specified.
A
Yeah
so
so
other
than
obviously
that
mistake
I
had
there
what
I,
hadn't
done
anywhere
is
changed
their
semantics
of
any
of
these
properties.
So
we
had,
we
had
a
back
and
forth
around
what
leader,
organizing
and
tributon
were
and
felt
that
there
was
a
leader
role
that
was
different
to
the
organizer.
So
then
we
had
this
in
the
discussion
on
previous
calls.
So.
B
So
I
want
what
I
guess
I'm
wondering
is
I'm.
Just
looking
down
that
list,
there's
only
one
property
left
on
the
list.
That
could
be
two
different
object
types.
Everything
else
is
consistently
one,
and
so
if
this
is
the
only
one
left
that
is
just
just
two,
maybe
it's
worth
as
part
of
signing
up,
given
that
no
one
has
yet
used
it
as
a
person
in
all
the
data
sets
being
opened
or
planned
to
be
opened,
it's
always
an
organization.
Maybe
it's
worth
us
taking
the
opportunity
to
tighten
it.
A
Well
me
yeah.
The
other
thing
to
know
is
that
at
the
moment,
in
the
spec,
we
only
talk
about
having
the
only
differences
between
a
person
organization
is
organizations
have
a
logo,
otherwise
we're
only
asking
for
a
name,
and
you
know
they
identifies
in
the
next
name
in
description.
So,
even
though
it
is
two
types,
they're
kind
of
default
set
of
information,
there's
actually
similar
between
the
two
right.
B
Yeah
I
think
I
think
what
some
people
have
started
to
do
is
use
things
like
job
title
and
image
in
leader
to
talk
about
the
kind
of
role
of
the
person.
That's
there
I
suppose.
The
other
issue
is
that,
of
course,
a
person
has
gdpr
implications,
whereas
an
organization
doesn't,
and
so
someone
was
playing
safe,
they
might
want
to
ignore
the
leader
fields
if
that
data
users,
whereas
the
organization
organized
a
field,
is
a
organization,
you
wouldn't
expect
to
be
the
same
rules.
B
But
if
it's
worthless
yeah,
maybe
maybe
starting
an
issue
for
it
and
just
just
checking
if
I
don't
think
I
think
open
sessions
might
be
only
people
that
would
have
a
view
on
it.
Maybe
maybe
play
ways
would
about
it
as
well.
You
could
try
and
get
some
more
opinions,
because
if
it's
that,
if
that
is
the
only
thing,
stopping
us
from
going
full
full
tightness
on
respect
a
meaning
that
we
can
reference
everything
reliably,
then
maybe
it's
worth
getting
my
input.
A
A
A
So
just
the
time,
so
most
of
these
are
kind
of
things.
Making
change.
There's
a
few
changes
things
like
blushing
on
shootin
the
decimals
Millions.
There
were
a
couple
of
things
that
aren't
in
the
current
spec
that
need
to
be
so
actions.
Entry
points,
potential
action,
it's
just
if
that's
coming
through
from
looking
spec
there
needs
to
be
in
here.
A
The
only
other
changes
are
smaller.
Things
like,
as
I
said,
where
I've
just
marked
things
as
being
recommended
and
I've
got
higher
marks
in
red,
something
that
we
could
maybe
have
spent
a
few
minutes
talking
about.
There's
in
the
current
spec
there's
quite
a
bit
of
flexibility
around
how
location
is
specified.
A
A
I
was
I
had
in
mind
things
from
the
kind
of
long
tail
of
publishing
where
people
might
not
actually
be
coming,
bringing
in
stuff
from
a
structured
database,
and
they
might
just
have
you
know
we're
gonna
meet
in
the
park
by
the
by
the
pond
to
kind
of
think
all
right.
So
that's
where
we
got
that
variation,
so
I'm
wondering
whether
we
want
to
keep
that
or
whether
we
should
be
timing.
It
up
yeah.
B
Yeah,
it's
definitely
used
in
all
three
of
those
different
ways
by
various
people:
the
various
organizations
it.
There
are
quite
a
lot
of
there's
quite
a
bit
of
data
that
we've
seen
that
does
have
the
ad
hoc
location,
an
ad
hoc
address
field
and
I
need
it
in
the
location
in
the
place
object.
You
can
have
a
postal
address
within
that
yeah.
A
B
A
A
B
And
so,
if
that
same
field
was
able
to
be
used
for
that
purpose,
then
potentially
some
aggregators,
for
example,
that
trying
to
create
uniform,
accessible
accessibility
across
all
the
different
data
sources
could
just
be
pulling
stuff
out
of
the
place
and
pulling
it
into
that
field.
To
ensure
that
there's
a
consistent
field,
but
also
that
same
field
could
be
used
to
dump
stuff
in.
A
A
A
B
B
I'd
say
that
at
least
in
all
the
use
cases
we've
seen
as
I
meant,
we've
only
ever
used
the
full
address
address
as
a
string
before
I'm
sure
that
there
are
so
the
benefits
to
having
the
structure
components
of
the
postal
address.
But
not
all
providers
can
provide
that.
So
is
there
somewhere
that
the
address
just
as
text
can
be
required
and
then
the
a
more
structured
postal
address
just
be
an
optional
thing,
see
it's
not
quite
clear
how
you
do
that
on
the
schema
door,
object.
B
B
I
think
this
is
already
a
note
somewhere
in
one
of
the
validated
things,
but
if
they
just
published
without
the
components
they
just
won't,
take
it
and
so
there's
quite
a
strong
incentive
there,
given
the
scale
of
Google
to
the
publishers
to
start
doing
that
and
if,
whenever
we've
been
working
with
publishers,
recently
I've
been
advising
them
of
that
and
often
they've
actually
been
managing
to
pull
components
out
of
someone,
it's
amazing
at
you.
When
you
ask
the
question:
suddenly
they
can
can
do
that.
B
Not
in
all
cases
absolutely-
and
there
are
cases
like
book
when,
where
those
address
is
just
a
massive
three
text
field
with
multiple
lines
and
lines
can
be
entered
and
people
right,
like
you
know,
turn
left
at
the
tree
in
it
and
the
stupid
thing
about
that
is
in
book.
When,
if
that
free
text
field
isn't
a
possible
address,
then
you
can't
geo
locate
it,
and
so
it
just
ends
up
literally
being
a
Cathy.
B
B
A
So
we
had
so
we
had
some
discussion
around
this.
So
there's
this
meeting
point
field,
which
is
intended
to
be
more
specifically
so
for
larger
locations,
where
my
possible
meeting
points
being
clear
about
where
you
actually
need
to
turn
up
at
the
location,
that's
specified,
so
that
wouldn't
mean
yeah.
You
could
say
the
location
is
the
park
and
then
that's
really
good
stuff
we're
gonna
meet
by
the
pond
kind
of
thing.
A
It
could
be
that
we
recommend
that
if
all
you've
got
is
completely
unstructured
free
text
field
and
not
even
sure,
if
it's
a
an
address,
then
use
meeting
point
yeah
it
specify
location
and
then,
if
you
have
something
you
have
anything
else,
then
use
a
place
and
do
your
best
to
extract
the
address,
concise.
B
It's
an
interesting
point.
You
know
I,
wonder
because
the
people
that
are
just
publishing
meeting
point
in
that
scenario
just
won't
get
their
stuff
listed,
I
mean
no
one's
gonna,
be
able
to
geocode
it's
just
not
gonna
appear
on
any
maps
or
any
location,
searches
and
it's.
This
is
a
global
database.
It's
not
useful
to
have
data
which,
without
a
pin
on
it,
because
it's
hyper
local
information,
so
I
feel
like
there
is
a
thing
about.
You
know:
I
mean
people.
People
just
need
to
sort
the
data
out
to
an
extent.
A
A
B
B
So
you're
basically
saying
postal
address
and
then,
rather
than
trying
to
extract
address
components
which
can
be
difficult
if
there
isn't,
if
it's
just
generally
not
componentized.
However,
it
does
contain
a
postcode
and
if
geocode
Abul,
then
you
put
it
in
as
a
name
in
the
postal
address
and
and
what
we're
basically
saying
in
our
guidance
is
anything:
that's
got
a
postal
address.
We
expect
VG
of
codable.
If
you
don't
already
have
geo
coordinates
specified.
A
A
B
I
think
what
we're
saying
is
I,
don't
think
places
ever
I
don't
have
any
data
sets
where
places
are
string.
I
think
it's
more,
that
the
address
object
is
a
string
inside
the
location.
Sorry
location
is
never
a
string.
It's
the
address
object
inside
location
in
the
place.
That's
a
string
sometimes
again.
A
A
A
B
B
B
A
B
For
our
the
use
cases
I'm
just
thinking
you
know
in
in
the
I
mean
use
case,
where
there's
a
address
that
someone
wants
to
render
into
a
single
string
intelligently,
but
but
not
compromise
on
providing
the
full
data
for
those
that
want
it.
The
name
seems
like
a
natural
fit.
In
that
scenario,
yeah
I
mean
having
having
a
field,
does
make
sense.
The
name
names
a
bit
of
a
strange
one
because
with
other
fields,
I
feel
like
it
tends
to
have
a
different
meaning.
Oh.
A
B
A
B
I
think
I
was
going
to
say
is
that
that
use
case
we
just
talked
about
where
an
aggregator
might
want
to
create
a
a
user
friendly
address
really
was
what
it
is
to
be
printed
on
a
GUI,
because
a
lot
of
time
people
don't
want
to.
You
know
print
components.
They
just
want
a
string
there.
That
field
essentially
is
the
same
requirement
as
the
stuffing
field.
A
Gonna
have
to
wind
up
a
call
that
she's
I'm
late
from
the
one
thing
I
know
is
that
if
you
were
in
a
position
of
wanting
to
enrich
or
fix
data
being
able
to
identify,
ok,
this
address
is
text
string
rather
than
a
structure.
Value
gives
you
some
of
there's
a
key
off
where,
as
if
people
are
just
starting
to
put
text
into
a
name
property,
you
don't
know
what's
in
there,
they
could
that
you
know.
A
B
Thank
you
me.
You,
my
driver
that
really
everyone
can
actually
I.
Think
home
is
that
some
people
might
start
structuring
it
using
reg
X's.
You
might
have
a
string
and
then
go.
Maybe
the
locality
is
the
last
thing
if
you
come
as
a
string
yet,
which
will
lead
to
stuff
totally
and
and
the
Google
reserve
requirement
should
compel
people
to
change
their
field
structures,
but
you're
right,
there's
no
point
and
forcing
that
prematurely.
B
A
Okay,
that
was
useful
review.
I'm
gonna
have
to
jump
on
another
call
and
what
I
didn't
get
to
there's
the
second
tab
here.
Conformance
criteria
are
a
list
I'm
trying
to
pull
out
all
of
the
must
should
must
not
etc
from
the
spec.
We
we
started
to
be
a
bit
more
explicit
about
some
of
these
additional
requirements
in
the
last
spec
Iran
stuff,
like
age
range,
where
we
you
know,
we
started
to
describe
how
to
use
the
min
and
Max
values.
A
A
A
A
Raise
an
issue
I'm
using
this
as
a
kind
of
support
tool
for
me
doing
the
Edit
changes,
okay,
because
in
some
cases
some
of
the
things
you
file
they've
ended
up.
You
know
this
means
I
need
to
change
some
stuff
here
and
that's
what's
good
here
and
I,
just
like
to
have
oversight
of
what's
going
in
cool,
okay
and
I
thanks
both
that
is
useful.
I'll
do
some
follow
up
with
everybody
else
after
it's,
and
hopefully
we
can
get
to
a
nice
tidy
r-spec
nice.
Oh
thanks,
guys.