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

[Eric Johnson <eric@tibco.com>]

For the benefit of everyone, looks like I forgot to reply to the list. Sorry about that!

Eric.

On Tue, May 8, 2018 at 9:09 AM, Eric Johnson <eric@tibco.com> wrote:

Hi Allan,

On Mon, May 7, 2018 at 8:24 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.

I think you misunderstood my proposal. I used JSON pointer syntax to convey my meaning. Perhaps an explicit example would help:

What we currently have is something along the lines of this:

{

  "document_title": "title goes here",

  "document_references": [

    {

      "url": ...

    }

  ],

  "document_tracking": ...

...

My suggestion is to do this:

{

  "document": {

    "title": "title goes here",

    "references": [

      {

        "url": ...

      }

    ],

    "tracking": ...

  },

  ...

This approach actually lets the JSON parsing do the work of putting all the document related properties into a single object in whatever programming language of one's choosing. It adds no work for post-processing.

Eric.

 

 

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

 

I noticed, while putting together the schema, that we have "document_notes", "document_tracking", "document_references", "document_distribution".

 

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.