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: [csaf] CSAF JSON Schema - remove a level of nesting for lists of things.


I've made this change to the schema in progress.

Eric.

On Wed, May 2, 2018 at 12:27 PM, Omar Santos (osantos) <osantos@cisco.com> wrote:

+1 – I can also help clean some of the existing examples, if needed.

 

From: <csaf@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Wednesday, May 2, 2018 at 3:14 PM
To: Eric Johnson <eric@tibco.com>, "csaf@lists.oasis-open.org" <csaf@lists.oasis-open.org>
Subject: Re: [csaf] CSAF JSON Schema - remove a level of nesting for lists of things.

 

Agree with both the issue (unnecessary nesting) and suggested fix.

 

Allan

 

From: <csaf@lists.oasis-open.org> on behalf of Eric Johnson <eric@tibco.com>
Date: Wednesday, May 2, 2018 at 11:12 AM
To: "csaf@lists.oasis-open.org" <csaf@lists.oasis-open.org>
Subject: [csaf] CSAF JSON Schema - remove a level of nesting for lists of things.

 

Again, possibly, the conversion from the XML generated slightly odd JSON.

 

The CVRF specification defines a "RevisionHistory" element which has 1-N instances of "Revision".

 

In JSON:

 

      "revision_history": {

         "revision": [

            {

               "number": "1.0",

               "date": "2018-03-28T15:17:05",

               "description": "Initial public release."

            },

...

 

However, this is a completely unnecessary level of nesting (arguably so in XML as well, but there it is less clear).

 

Suggestion: Change all cases where we're doing this unnecessary nesting, remove it. The above JSON becomes:

 

      "revision_history": [

            {

               "number": "1.0",

               "date": "2018-03-28T15:17:05",

               "description": "Initial public release."

            },

...

 

This occurs in a number of places:

 

/document_tracking/revision_history/revision[] -->

  /document_tracking/revision_history

 

/vulnerabilities/notes/note[] -->

  /vulnerabilities/notes[]

 

/vulnerabilities/remediations/remediation[] -->

  / vulnerabilities/remediations[]

 

/vulnerabilities/references/reference[] -->

  /vulnerabilities/references[]

 

/document_notes/note[] -->

  /document_notes[]

 

/document_references/reference[] -->

  / document_references[]

 

Any objections to simply collapsing these paths as documented above?

 

Eric.

 




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