Data elements for JSON consolidation

[anweiss]

This issue is meant to track data elements that would allow for potential consolidation of JSON and JSON schema artifacts. The initial list is as follows:

• hoisting array values into objects whose keys are the unique identifiers in the original array (possible for props, params and parts)

  Original XML snippet:

  <prop class="name">AC-1</prop>
  <prop class="priority">P1</prop>
  <prop class="baseline-impact">LOW</prop>
  <prop class="baseline-impact">MODERATE</prop>
  <prop class="baseline-impact">HIGH</prop>

  Current JSON equivalent:

  "props": [
    {
      "class": "name",
      "value": "AC-1"
    },
    {
      "class": "priority",
      "value": "P1"
    },
    {
      "class": "baseline-impact",
      "value": "LOW"
    },
    {
      "class": "baseline-impact",
      "value": "MODERATE"
    },
    {
      "class": "baseline-impact",
      "value": "HIGH"
    }
  ]

  Proposed JSON restructuring:

  "props": {
     "name": "AC-1",
     "priority": "P1",
     "baselineImpacts": [ "LOW", "MODERATE", "HIGH" ]
  }

• support for both single-value arrays and singular property/values

  "baselineImpacts": [ "LOW" ]

  becomes:

  "baselineImpact": "LOW"

• arrays of single-property objects become arrays whose values are from the original array's object's values

  Example of current JSON profile:

  "imports": [
     {
       "include": {
         "calls": [
           {
             "controlId": "ac-1"
           },
           {
             "controlId": "ac-2"
           },
           {
             "subcontrolId": "ac-2.1"
           }
         ]
       }
     }
  ]

  becomes:

  "imports": [
    {
      "includeControls": ["ac-1", "ac-2"],
      "includeSubcontrols": ["ac-2.1"],
      "matchControls": "<regex>"
    }
  ]

  the example above assumes the user disregards or simply has no need for the with-control/subcontrols semantics (they become optional) and explicitly calls the controls out instead

[david-waltermire]

@anweiss has this been sufficiently addressed for you? If so, comment and transfer this back to me to close. if not, please indicate what still needs to be done.

[wendellpiez]

There are lots of good ideas here but they will require extension of metaschema functionality to provide validations for testing and ensuring the requisiste consistency in the data.

Just for example, to produce this enviable JSON from profile XML:

"imports": [
  {
    "includeControls": ["ac-1", "ac-2"],
    "includeSubcontrols": ["ac-2.1"],
    "matchControls": "<regex>"
  }
]

the processor must be configured to know that any import/call/@control-id (XPath into the profile XML) should be represented as a string value in an array labeled includeControls.

This is not impossible -- the call field and control-id flag in the Metaschema have declarations, where the information for such optimizations might be described (here, that the calls are removable while their control IDs, subcontrol IDs etc can be promoted into a labeled array object). However, it requires design, development and testing.

[wendellpiez]

Working on the first two items in my branch issue388-json-refactor. See #388.

Leaving the last issue for later since the modeling questions are more complex.