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
with Concept
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 <[email protected]>
wrote:

> 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.
>
> Thanks,
>
> Trevor
>
> On Mon, Feb 20, 2017 at 5:54 PM, Martin Preisler <[email protected]>
> wrote:
>
>> On Mon, Feb 20, 2017 at 9:08 AM, Zbynek Moravec <[email protected]>
>> wrote:
>> > Hi,
>> >
>> > database sounds like interesting idea. I didn't think about it in that
>> way.
>> > 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 -- [email protected]
>> rahosted.org
>> To unsubscribe send an email to scap-security-guide-leave@list
>> s.fedorahosted.org
>>
>
>
>
> --
> Trevor Vaughan
> 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.
> fedorahosted.org
> To unsubscribe send an email to scap-security-guide-leave@
> lists.fedorahosted.org
>
>
_______________________________________________
scap-security-guide mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to