►
From YouTube: Planning Discussion: Generic Security Reports
Description
Synchronous discussion to breakdown the work required to implement Generic Security Report Schemas per design issue https://gitlab.com/gitlab-org/gitlab/-/issues/267193
A
All
right
we're
here
to
talk
about
the
unified
report
scheme
and
how
we
can
move
forward.
So
we've
got
a
poc
that
was
delivered
to
us
by
james
johnson
like
three
months
ago
and
it's
fairly
large.
It
includes
some
changes
in
you
know
fingerprinting
and
location
identification,
but
what
I
really
wanted
to
focus
on
today
is
around
the
templated
components,
so
I
know
there's
other
back
back-end
work.
That's
involved
in
this
larger
unified
report
schema
and
I
believe,
a
lot
of
that
is
already
defined
under
this
epic.
A
A
That
would
be
my
my
goal
for
this
discussion.
If
there's
other
questions
or
comments
about
some
of
the
other
back
end
work
me
how
we
can
we
can
talk
about
it,
especially
if
it's
something
that
matt
can
help
clear
up,
but
since
we
don't
have
a
lot
of
representation
from
the
rest
of
the
team
here,
I
was
hoping
that
that
would
be
a
good
focus.
A
C
D
A
D
A
Okay,
now
I'm
gonna
just
summarize
what
I
just
said.
So
you
know
the
the
agenda.
The
meeting
topic
says:
unified
report
schema
given
the
audience
and
the
time
and
our
priority
right
now
I
want
to
focus
on
this
templatized
components
for
the
generic
report
schema,
which
is
you
know,
much
more
more
fun
and
heavy,
which
is,
I
think
why
you
came
to
join
us,
because
there's
a
lot
of
considerations
around
the
secure
front,
end
team
here
as
well
for
sure
thank
you.
A
I'm
gonna
go
ahead
and
share
my
screen
just
to
make
sure
we're
all
looking
at
the
same
thing.
So
overall,
summary
of
what
we're
doing
here
is
available
in
the
epic.
I
think
everyone's
pretty
aware
of
the
fact
that
all
the
different
scheme,
all
the
different
scanners
right
now,
have
their
own
schemas.
A
And
this
is
the
larger
epic,
but
andy
was
nice
enough
to
create
a
design
issue
for
us
just
for
the
templatized
components.
So
what
we
would
display
on
the
vulnerability
details
page,
so
I'm
going
to
click
into
that
before
I
move
on.
Is
there
any
questions
about
the
bigger
effort
or
matt
anything
that
you
want
to
add
around
the
priority
or
usage
or
anything
like
that?.
E
I
think
the
urgency
is,
let's
say
it's
increasing,
so
the
one
of
the
main
benefits
of
this
is
a
lot
of
the
scanner
teams,
as
they're
trying
to
mature
and
advance
their
own
areas
of
the
product
are
finding
that
they
have
need
for
more
very,
like
use
case,
specific
information
to
be
displayed
on
the
vulnerability
details.
Pages
right,
like
a
fuzzing
output
has,
it
might
have
like
a
like
a
crash
dump
of
whatever
happened
in
memory.
E
Sast
may
want
to
put
a
snippet
of
the
actual
code
where
something
is
identified
right
now.
We
don't
have
a
good
way
for
them
to
do
that
other
than
each
team,
basically
hard
coding
in
a
conditional
for
if
it
is,
you
know,
a
sas
scanner
then
put
this
block
of
code
in
it's,
not
something
that's
going
to
be
really
scalable.
E
So
the
generic
report
came
from,
I
think,
james,
in
a
roundabout
way,
but
trying
to
address
this.
How
can
we
allow
each
of
the
scanners
to
provide
the
details
it
needs
without
having
the
front
end
or
the
back
end
having
to
have
really
any
logic
around
it
right
we're
not
making
business
decisions?
It's
just.
We
need
to
give
them
a
repeatable
way
to
display
nicely
formatted
content,
and
so
it's
going
to
be
up
to
the
scanners
to
adopt
and
structure
it.
E
What
andy
has
got
in
the
actually
lindsay
you
want
to
open
the
little
or
hold
on
sorry
nevermind
in
the
list.
These
were
guess.
Components
is
probably
a
good
way
to
to
say
that.
So,
if
you
haven't
looked
deeply
at
the
the
poc
report
format,
it
basically
allows
for
recursive
definition
or
recursive
structure.
So
you
can
make
any
combination
of
the
component
types
to
effectively
output
information.
However,
you
need
and
we're
just
going
to
try
to
display
them
what
andy's
design
has
done.
E
He
has
tried
to
account
for
each
of
those
different
components
with
one
of
these
sections.
I
think
there
was
some
confusion
that
this
is
not
what
any
given
vulnerability
detail
page
will
look
like
this
is
sort
of
a
super
set
of
if
you
just
output,
everything-
and
I
actually
we
chatted
about
this
yesterday-
I
think
he's
going
to
try
to
make
a
an
addition
to
this
page
and
apply
the
component
type
labels
on
each
one
of
the
little
pieces.
Just
so,
it's
really
clear
what
we're
looking
at.
Oh.
A
So
we
have
an
issue
under
this
epic
around
creating
this
schema,
like
I
said,
there's
a
lot
of
this
back-end
work.
That's
already
defined
it
defined,
so
under
the
assumption
that
we've
got
a
schema
that
is
supporting
this
and
we
can
take
a
look
at
that
schema.
If
that's
helpful
today,
if
you
haven't
already,
it
might
take
me
a
little
bit
to
navigate
to
it.
The
goal
is
to
determine
how,
if
we're
moving
forward,
how
to
move
forward
of
this
and
break
down
the
issues.
A
I've
heard
different
things
about
what
what
back-end
work
is
necessary
on
this.
So
me
how
I'm
hoping
that
you're
able
to
help
clarify
some
of
that
for
us
today
or
in
the
or
in
the
near
future
or
savage
today.
Do
we
just
get
data
points
and
then
the
front
end
determines
the
display
of
them,
or
is
there
some
sort
of
transformation
that
generates
the
markup
on
the
back
end
and
delivers
that,
to
the
front
end
as
part
of
an
api
call.
C
C
A
C
A
Right
and
so
that's
where
I
think
this
proof
of
concept
comes
in,
because
james
actually
has
something
that
was
working
and
he
was
able
to
show
us
with
a
schema
that
he
had
created.
That
is
part
of
this
poc,
the
the
vulnerability
details
page
displaying
all
of
these
different
items.
So
there
is
the
code
behind
all
of
that
in
here.
It's
not
production
ready,
it
doesn't
have
all
the
tests.
A
C
E
Yes,
so
that's
a
great
question
think
of
this
as
sort
of
net
new.
If
none
of
the
scanners
today
adopt
this,
that's
fine,
this
is
going
to
live
in
or,
I
should
say
it
needs
to
live
in
parallel.
We
need
to
be
able
to
consume
the
current
common
formats
that
each
of
the
scanners
output
and
then
this
new,
unified
schema
type.
E
So
the
long-term
goal
for
this
is,
as
the
scanner
teams
are
able,
they
would
migrate
their
outputs
into
this
new
unified
format,
because
it
gives
them
that
flexibility
to
sort
of
change,
the
information
and
the
presentation
of
the
vulnerability
details
page
as
long
as
they
adhere
to
the
schemas
and
it's
you
know
it's
valid.
We
don't
have
to
do
any
work,
which
is
where
we
want
to
go
on
the
flip
side.
I
see
this
as
being
immediately
useful
for
any
third-party
integrations.
E
We
have
a
limited
number
of
official
integrations
today.
Part
of
it
is
because
it
is
kind
of
a
challenge
as
a
vendor.
I
have
to
first
figure
out
like
okay,
so
I've
got
a
let's
say
a
dynamic
analyzer.
Now
I
have
to
go
to
the
security
documentation.
I
have
to
go
find
the
specific
format,
for
my
specific
analyzer
type
hope
that
it's
got
the
fields
that
I
need
and
it's
not
an
easy
process,
so
this
is
going
to
make
it
a
lot
easier.
E
E
C
Okay,
so
if
we
do
not
want
to
immediately
ask
the
security
to
adopt
the
unified
schema,
then
we
will
have
to
do
some
additional
work
on
the
back
end
to
transform
the
current
schema
employed
by
the
scanners
to
somehow
fit
into
that
unified
schema.
We
just
came
up
with
so
we
will
have
the
old
security
thingy
security
scanners
work
with
no
changes,
and
we
will
have
to
somehow
transform
the
old
input
into
dunya
output
on
the
back
end,
so
we
might
have
additional
work
in
that
case,.
A
And
that's
where
I
think
it
would
help
to
look
at
the
code
behind
this,
because
I
believe
what
you
just
described
is
how
james
approached
that
this
does
currently
support.
Both
the
existing
scanner
schemas
plus
this
new
one
in
parallel,
and
I'm
not
100
sure
about
whether
it
was
doing
a
transformation
or
if
there
was
just
the
dual
code
in
place.
C
A
A
A
Okay,
so
if
the
goal
out
of
this
discussion
is
to
try
to
at
least
determine
the
some
of
the
planning
breakdown,
you
know
I
would
like
to
come
out
of
this
with
a
bullet
pointed
list
of
like
here
is
here,
is
where
the
or
plan
to
do
this
here
is
where
the
front
end
issues
what
they
would
need
to
look
like
and
maybe
hear
some
of
what
the
missing
back-end
issues
would
be
so
savage.
You
would.
B
A
You
know
the
big
outstanding
question
in
my
head
is
still,
and
I
don't
know
if
it
was
answered
just
now
where
the
styles
are
applied
today.
Is
that
all
done
on
the
front
end
or
is
that
markup
generated
on
the
back
end
today
to
take
the
schema
and
turn
it
into
the
markup
for
the
vulnerability
details
page.
B
So
I
think
first,
we
need
to
understand
what.
So,
if
we
look
at
the
design
that
andy
prepared,
there
are
some
some
fields
there.
We
need
to
understand
which
fields
we
want
to
display
and
probably
create
a
component
for
each
of
them,
so
that
dynamically
they
can
be
displayed
because,
right
today
we
don't
have
these
components,
we
will
so
we
will
need
to
prepare
them.
So
that
will
be
the
first
starting
point,
at
least
for
the
front
end.
E
And
savage
so
when
I
talked
to
andy
about
this,
he
said
he
pretty
much
put
this
together
almost
entirely
with
existing
gitlab
styles
for
things,
so
there
should
be
both
like
the
diff.
That's
an
existing
component
like
on
the
mr
and
many
of
the
other
styles,
or
things
he's
just
pulled
from
our
ui.
So.
B
B
A
So
if
there
were
cases
where
there
wasn't
one,
there
would
be
some
additional
development
there
and
that
would
be
identified
from
this
first
issue
that
or
the
first
bullet
point
that
I
just
wrote
down,
they
seem
pretty
standard.
You
know,
I
don't
think,
there's
anything
that
we're
trying
to
display
here.
That's
really,
you
know
out
of
the
box
new,
but
we
should
leave
the
possibility
open
that
we
might
have
to
put
some
custom
code
around
that.
B
So
the
thing
is,
for
instance,
if
we
have
this
this
component,
I
think
we
will
need
to
work
closely
with
the
back
end
so
that
they
know
what
what
properties
this
component
takes
and
they
need
to
prepare
the
json
accordingly
to
decrease
the
amount
of
work
that
we
needed
to
in
the
in
the
front
end
like
to
map
them
or
to
create
these
wrappers.
So
I
think
the
the
first
bullet
point
identifying
the
the
components
this
can
be
done
together
with
the
beckon.
B
A
And
some
of
this
again
this
goes
back
to
having
the
validation.
So
once
we
do
this
once
and
we,
we
are
confident
that
we've
got
the
right
properties
associated
with
each
element
or
component,
that
there's
validation
in
place
to
make
sure
that
we
don't
have
to
handle
a
whole
bunch
of
weird
edge
cases
of
things
not
being
as
we
expect.
A
And
again,
there's
a
separate
issue
already
today
around
schema
validation.
So
I
think
this
is
just
you
know
during
that
development,
making
sure
that
we've
defined
like
just
to
repeat
what
you
said
that
we've
defined
all
the
properties
that
are
required
to
display
the
element
as
the
design
expects
it,
which
could
result
in
changes
to
what
that
schema
looks
like.
A
A
C
News
I
took
a
look
at
the
like
total
changes
in
the
proof
of
concept.
Merge
request
by
james
and
the
back-end
changes
in
this
proof-of-concept
are
minimal.
He
exposes
two
additional
fields
in
addition
to
what
we
currently
expose
in
the
helper,
which
means
that
this
proof
of
proof
of
concept
consumes
what
we
currently
export
from
the
back
end.
C
But
I'd
like
a
proper
front-end
opinion
on
how
viable
the
code
is,
because
I
I
don't
consider
myself
worst
enough
to
say
this
is
good
code
or
this
gold
is
going
to
require
much
more
work,
but
backhandwise
the
changes
are
minimal.
So
we
could.
This
proof
of
concept
allows
us
to
keep
using
the
existing
schema
without
changing.
A
C
C
C
No
with
regards
to
the
unified
schema
report
schema
what
magmat
did
is
basically
the
most
flexible
approach
we
can
employ
in
this
case,
so
it
makes
perfect
sense
this
one
excellent.
The
question
is:
how
do
we
structure
the
schema
in
a
way
that
it
requires
no
or
minimal
transformations
for
the
front
end
to
display.
A
Yeah,
so
that
goes
back
to
what
we're
trying
to
define
right
now.
So
no
that's
perfect.
So
I'm
great,
that's
great
news.
Thank
you
yeah.
So
what
you
just
described
does
that
make
sense
to
make
a
bullet
point
here,
savage
around
that
transformation,
or
is
that
inherently
part
of
this
first
item
I
think,
do
we
need
a
separate
issue
around.
A
So
I'm
curious
if
the
transformation
of
the
schema
data
types
to
the
ui
data
types
I
mean
is
that
is
that
handled
here
in
this
first
bullet
point,
or
is
this
just
the
identification
like
we've
identified
that
the
components
are
out
there?
Should
we
have
a
separate
implementation
issue
around
that
transformation
or
mapping.
B
B
B
So
I
was
checking
the
poc
right
now,
the
the
the
front
end
code.
There
are
a
lot
of
front-end
changes
that
it
was
not
what
I
was
expecting.
At
least
it
was
not
what
I
had
in
mind
with
this
with
this
issue,
because
what
I
had
in
mind
was
that
we
have
the
the
the
amount
of
work
that
we
deliver.
It's
mostly
in
the
json,
so
the
json
knows
a
bit,
so
it
provides
also
information
on
the
ui
components.
B
But
what
I
see
here
is
that
we
have
a
lot
of
front-end
code
delivered
that
that
was
not
my
expectation.
So
I
was,
I
was
kind
of
confused,
but
the
thing
is
so
once
we
have
the
json
the
schema
ready,
the
next.
The
next
step
should
be
just
simply
write
those
wrappers
or
if
we
need
any
wrapper,
hopefully
not
which
maps
the
json
to
the
to
the
ui
components.
B
So
that's
that's
the
probably
the
the
second
step,
so
the
first
step
would
be
identifying
the
components
understand
what
we
have
today
and
build
the
json
schema.
According
to
that,
the
second
step
would
be
to
implement
those
those
components,
the
missing
ones
and
the
if
we
have
any
and
then
create
the
mapper,
that's
clear.
I
think
I
was
confused
while
I
spoke
of
it
so.
C
But
my
my
suggestion
for
the
unified
schema
is
that
it's
not
developed
with
the
ui
front-end
consumption
in
mind
that,
because
I
expect,
if
we
do,
that,
having
the
front
end
in
mind
the
unified
schema,
then
I
expect
that
at
some
point
it
would
turn
out
that
people
integrating
tools
with
our
unified
schema
have
a
different
different
requirements
than
the
front-end
has
to
consume
them.
So,
ideally,.
C
With
the
scanners
in
mind
and
structured
in
such
a
way
that
it's
easy
to
write
a
scanner
conforming
to
the
schema,
and
we
would
ingest
that
schema
in
the
back
end
and
we
would
transform
the
input
schema
from
the
scanner
on
the
back
end
transformed
into
a
way
that
can
be
parsed
by
the
front
end
in
an
easy
way.
So,
ideally,
all
the
hard
computation
would
take
place
on
the
back
end
and
we
would
have
a
schema.
That's
designed
with
the
scanners
in
mind,
not
in
not
with
the
front
in
mind.
B
Yeah
you're
right
you're
right.
I
think
the
the
the
ui
logic
shouldn't
sorry.
That
was
my
mistake.
So
what
I?
How
I
imagine
this
is
that
the
back
end
provides,
for
instance,
a
json
schema
could
look
like
this.
There
is
a
type
field,
it
says
diff
and
then
there's
the
data
which
gives
the
div
data,
for
instance,
and
then
we
have
a
mapper
around
it
and
we
once
we
parse
the
json.
We
we
see
that
the
type
whenever
the
type
is
the
diff.
B
We
use
a
diff
component
for
that
and
we
inject
the
data.
So
we
definitely
need
a
mapper
for
that,
but
I
was
imagining
this
to
be
dynamic,
not
like.
I
couldn't
check
the
code
in
detail,
but
I
saw
that
there
was
a
lot
of
front-end
changes.
That
was
not
my
expectation.
My
expectation
was
to
build
a
simple
wrapper,
mapper
function,
which
basically
parses
the
json
data
and
then
displays
the
the
components
in
a
for
loop,
for
instance.
E
E
I
think
me
how
your
point
about
making
something
that
scanners
can
output
is,
I
agree,
is
much
more
important
and
then
we're
just
sort
of
allowing
them
to
adjust
the
way
that
they
create
that
output
if
they
would
like
to
see
something
different
in
our
ui
just
sort
of
ordering
of
operations,
but
yes,
avash.
If
you're
seeing
a
lot
of
code
in
a
place
that
you
don't
expect
it
for
the
front
end
stuff,
we
we're
not
we're,
not
we're
not
married
to
that.
We
can
get
rid
of
that
code
and
and
start
from
scratch.
B
Yeah,
I
would,
I
would
need
to
check
in
detail,
because
I
was
I
remember.
I
checked
that
a
few
months
ago
and
then
next
time
I
checked
was
yesterday
and
today
so
I
would
need
to
check
it
in
detail
and
understand
again
what
it
does
exactly.
But
what
I
had
in
mind
was
simply
you
know,
a
function
which
iterates
it
which
parses
the
data
and
then
displays
dynamic
components.
B
C
C
The
second
one
would
be
for
front-end
engineers
to
come
up
with
a
desired
schema
of
what
what
what
backhand
should
give
them
to
display
the
report
in
the
vulnerability
details
section
and
the
third
high-level
task
is
to
create
back-end
code
that
would
transform
the
unified
security
scanner
schema
into
the
front-end
schema.
So
that
would
be
three
high-level
tasks
we
currently
have
to
deal
with.
B
E
A
list
of
yeah,
so
those
are
the
ones
that
that
james
had
called
out
and
after
I
was
actually
discussing
this
with
him
a
couple
of
months
ago,
like
the
markdown
one
was
one
that
I
thought
would
be
really
helpful
to
add.
So
that's
what's
in
there
now,
if
there
are
certain
things
that
maybe
don't
make
as
much
sense
or
you
think
some
of
the
components
might
be
better
combined
or
split
apart.
That's
open
for
discussion
as
well.
B
Okay,
perfect,
so
what
I
would
do,
for
instance
here
I
would
go
one
by
one
through
this
list,
understand
what
data
these
components
require
and
then
build
or
ask
the
backend
to
provide
the
the
the
specific
data
based
on
that.
So
so
it's
it's
in
line
with
what
meehau
said.
First,
the
back
end
creates
defines
the
the
json
the
the
fields
that
that
are
needed.
Then
we
collaborate
with
the
back
end.
We
tell
them
what
kind
of
data
and
we
need,
and
then
we
start
building
it.
B
A
A
B
A
C
C
A
And
that's
a
good
point
getting
input
from
others.
Insecure
will
definitely
be
a
step,
keep
in
mind
since
we're
gonna
continue
to
support
the
existing
schemas,
we're
not
asking
them
to
change
anything
right
away.
We
should
make
it
as
compatible
so
that
they
would
want
to
adopt
the
schema
as
possible
and
make
whatever
plans
for
that
early.
A
C
Yes
collaborative
if,
if
we
follow
this,
then
there
will
be
one
additional
backend
task,
which
is
basically
transforming
the
details:
json
b
column
from
the
unified
input,
unified
scanner,
unified
scanner
schema
to
the
schema
desired
by
the
front-end
team.
So
we
will
have
one
additional
issue
for
the
back-end.
A
B
C
C
C
A
I
think
this
might
be
a
separate
issue,
then
so
you're
talking
about
there's
the
generic
security
report
schema,
and
this
is
the
one
that
we
want
the
secure
team
to
agree
on.
Yes,
yes
is
the
schema
that
you're
talking
about
now
the
front-end
schema.
That's
expected.
Do
we
need
a
second
issue
around
that
front-end
schema.
C
B
I
I
think
linsey
it's
like
this,
so
there
is
the
defined
json
schema.
I
think
that's
that's
breakdown
yeah!
The
first
one
is
that
the
front-end
does
the
investigation
and
tell
the
back-end
what
fields
they
want.
Yeah
correct
me
if,
if
I'm
wrong
and
then,
which
is
a
blocker
for
the
back
end
issue,
to
create
the
json,
so
first
the
the
backend
needs
input
from
the
front
end
so
that
they
can
start
writing
the
json
schema.
I
think
that's,
okay,
that
makes
sense.
C
C
C
A
C
A
A
C
A
C
B
Do
I
understand
this
correctly,
so
you
will
have
one
schema
for
for
the
back
end
and
then
you
will
have
something
that
transforms
that
schema
into
what
the
front-end
desires
exactly
and
you
will
send,
and
you
will
send
that
back
to
us
yeah,
okay,
so
we,
the
front-end,
will
never
know
about
the
schema.
That
is
in
the
back
end
the
the
one
that.
C
B
C
Shouldn't
right
yeah,
ideally,
you
shouldn't
know
any
details
about
the
scanner
schema,
because
if
we
force
you
to
consume
the
scanner
schema,
then
we
will
create
a
like
dependency
between
what
frontend
expects
and
what
the
scanner
should
provide.
While
I
think
that
the
scanner
schema
should
be
geared
towards
integrating
new
scanners
and
the
frontend
schema
should
be
different
and
it
shouldn't
depend
on
what
scanners
provide
okay.
B
That's
the
data
structure
yeah
I
so
you
will
store
the
raw
data.
For
instance,
let's
put,
let's
call
it
the
raw
data
in
the
database,
the
ones
that
generated
from
the
from
the
scanners
and
then
once
the
front-end
asks
it.
You
will
take
that
data,
you
will
massage
it
and
then
you
will
serve
it
to
us
right.
So
that's
why
you.
B
A
B
C
B
A
A
C
A
A
B
I
I
like
the
terms
you
use
the
generic
report
and
then
the
display
report
or
the
display
the
generic
scheme
and
then
the
display
scheme.
So
maybe
the
first
one
is
the
generic
scheme
and
then
the
second
one
identify
get
live.
Ui
component,
the
one
the
second
bullet
point:
it's
it
it's
the
display
scheme,
which
mihaw
was
mentioning
like
the
ones
that
that's
gonna
be
served
to
the
frontend.
A
A
E
A
B
A
B
B
So
one
should
be
defined
in
the
schema.
The
other
issue
should
be
implement.
The
schema
yeah,
yes,
but
also
in
the
front
end
implement
parse
that
schema
into
ui
components.
So
one
is
give
the
backend
what
they
want
so
that
they
can
prepare
the
schema
and
then
the
second
one
is
parsing
it
in
the
front
end.
So
we
we
have
two
front-end
issues.
B
B
Chronologically
the
first
one
should
be
defined,
json
schema,
the
second
one
should
be
front-end
defined,
vulnerability
to
the
details,
display,
schema
and
then
the
third
one
should
be
back
and
generate
the
expected
vulnerability.
Details
display,
schema
and
then
the
fourth
one
should
be
front
end.
I
don't
know
okay.
A
A
C
A
A
A
That's
that's
a
thought
too.
So
that
can
be
part
of
the
refinements.
You
know,
I
don't
think
we
need
to
decide
that
here.
So
can
we
think
of
anything
else
that
we
and
I'm
happy
to
create
these
implementation
issues,
but
I'm
going
to
sign
them
off
to
you
guys
for
refinement
and
putting
more
details
on
them.
I've
already
asked
savash
to
create
a
lot
of
implementation
issues
in
a
different
area,
so
I
don't
want
to
pile
this
all
on
him.
Is
there
anything
else
that
you
guys
can
think
of,
though.
B
A
B
A
A
Or
I
always
like
confused,
that's
just
that's
just
me,
I'm
not
confused.
I
feel
I
was
expecting
there
to
be
a
lot
more
issues
coming
out
of
this,
but
I
think
that
this
is
really
where
they
live
and
I
think
that'll
come
out
of
some
of
this
refinement,
so
I'm
not
confused.
I
just
want
to
make
sure
that
you
guys
are
comfortable
with
this.
I
mean.
C
A
A
The
thing
that
we
want
to
make
really
clear
to
everyone:
we
don't
want
to
cause
confusion,
saying
that
they're
going
to
need
to
make
updates
right
away
to
use
this
schema.
You
know
we're
not
asking
anyone
to
change
their
their
current
schemas.
We
just
want
to
make
sure
that
we're
building
something
that
will
meet
their
needs.
If
they
do
decide,
I
mean
they.
Who
knows.
One
of
these
scanners
could
decide
that
they
want
to
embrace
one
of
these
new
elements,
and
then
we
say:
hey
you
got
to
switch
over
and
use
the
generic
report
schema.