1) It seems that your scripts do not properly "interact with/query your
repo" to verify, for example, if a check already exists before (re)creating
it. Leading to duplicates (no reuse of states/objects/tests...)
2) It seems that you don't have a relationship between OVAL content
(Definitions) and Products, making it difficult to manage or clone the OVAL
Definitions for a new Product, etc.
While you could do the queries with the lxml.etree XPath-like and play
drift, you can clearly use a (very simple) relational database approach for
more efficient management, speed (for this use case of OVAL content
generation), and object relational mapping.
On Tue, Feb 21, 2017 at 10:39 PM, Trevor Vaughan <tvaughan(a)onyxpoint.com>
The term 'relational database' may be misleading.
What I want is a relational pairing between data segments so that later
changes can be done in a traditional manner. We don't actually need to
create full on tables in XML and do all that fun.
I do understand that it may break the git workflow and it will certainly
break the build scripts. However, I think that it will increase the user
experience and, therefore, help adoption of the suite.
I've asked before about being able to create micro data streams and
extract very small parts of the standards without having to lug around the
entire repo through my few hundred projects. Presently, this is not
possible but decoupling the data model should make it possible.
On Mon, Feb 20, 2017 at 5:54 PM, Martin Preisler <mpreisle(a)redhat.com>
> On Mon, Feb 20, 2017 at 9:08 AM, Zbynek Moravec <zmoravec(a)redhat.com>
> > Hi,
> > database sounds like interesting idea. I didn't think about it in that
> > In my opinion, XML DB could be way how to store many SSG "items", not
> only OVALs/remediations.
> > If I understood it correctly, only overhead of adding of new
> remediation would be
> > adding bindings to product, right?
> > I don't have own experience with XML databases. What does rest of SSG
> community think about it?
> Personally I don't like it. It doesn't work well with our git
> workflow. I don't think this is what the SQL
> XML databases are for.
> Martin Preisler
> scap-security-guide mailing list -- scap-security-guide(a)lists.fedo
> To unsubscribe send an email to scap-security-guide-leave@list
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
scap-security-guide mailing list -- scap-security-guide@lists.
To unsubscribe send an email to scap-security-guide-leave@