OASIS Common Security Advisory Framework (CSAF) TC

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

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

    Posted 05-08-2018 17:19
    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.