OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

csaf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [EXT] Re: [csaf] [CSAF JSON Schema] Combining "document____" properties


Nested JSON is great, when actually needed.  A guiding principle should be “flatter is better than nested”.  Often times from a data model perspective we go way over board on the design, which does nothing but increase implementation complexity.  

Simple and clean is king when designing these sort of things.

Bret 

Sent from my Commodore 64 

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

On May 8, 2018, at 10:28 AM, Jamison Day <jday@lookingglasscyber.com> wrote:

A nested JSON property structure may be valuable here.

e.g.

“document”: {
    “tracking”: “Back to Eric"
    “notes”: “Another suggested approach"
    “references”: [“Eric”, “Allan”]
    “distribution”: “Don’t send to Allan"
}

____________________________
Jamison M. Day, Ph.D.
Distinguished Data Scientist
Lookingglass Cyber Solutions, Inc.
303.968.0139 mobile

This electronic message transmission contains information from LookingGlass Cyber Solutions, Inc. which may be attorney-client privileged, proprietary and/or confidential. The information in this message is intended only for use by the individual(s) to whom it is addressed.  If you believe that you have received this message in error, please contact the sender, delete this message, and be aware that any review, use, disclosure, copying or distribution of the contents contained within is strictly prohibited.

On May 7, 2018 at 9:25:09 PM, Allan Thomson (athomson@lookingglasscyber.com) wrote:

Introducing ‘/’ separation requires parsers to know what the separator character is and introduces complexity that does not exist if the properties are separately defined without structure as you suggest.

 

If a product or software instance wants to create structure from those attributes that is easy done after parsing the properties into an object model/object database.

 

I suggest keeping the original properties.

 

Allan

From: <csaf@lists.oasis-open.org> on behalf of Eric Johnson <eric@tibco.com>
Date: Monday, May 7, 2018 at 10:34 AM
To: "csaf@lists.oasis-open.org" <csaf@lists.oasis-open.org>
Subject: [csaf] [CSAF JSON Schema] Combining "document____" properties

 

 

It seems to me that these should simply be combined under one "document" property, as in:

 

/document/tracking

/document/notes

/document/references

/document/distribution

 

Any objections to this reorganization?

 

(Note, this stems from an observation about the CVRF documents - such a document consists of three large chunks of data - information about the document itself, information about products, and information about vulnerabilities. Perhaps the top level properties of the JSON document should reflect that?)

 

Eric.

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]