Adding JSON value keys to fields in Catalog and Profile models

[wendellpiez]

Describe the bug

With the current metaschema, we have the capability of fixing the names for JSON keys on the nominal value (data content) of fields (as distinct from the values of flags on those fields). Without such a value key we have (by default):

'constraint': {
  'id': 'rule_zzz',
  'STRVALUE': 'no more than two (2)'
}

but with a value key 'rule' we can have:

'constraint': {
  'id': 'rule_zzz',
  'rule': 'no more than two (2)'
}

We should consider where in the Catalog and Profile models to use this feature, and what are appropriate value keys for the fields concerned.

Who is the bug affecting?

Anyone who works with the JSON data.

When does this occur?

Anytime there is a field, without a json-value-key designated in the metaschema.

How do we replicate the issue?

The easiest way to see where settings are made by default is to look at the model maps.

[david-waltermire]

@wendellpiez Can you compile a list of where we need to define a json-value-key for these instances? If you do, I can suggest names.

[iMichaela]

9/5/2019

@wendellpiez will work on it per @david-waltermire-nist 's assignment above.

[wendellpiez]

The following fields are candidates, in that they have no json-value-key defined, but they have one or more flags, so they cannot be flattened into strings. In some cases a flag can serve as the JSON value key:

• Catalog - looks good
• Profile - looks good
• Control_common: usage, constraint
• Metadata: doc-id, person-id, org-id, phone, base64
• Component - looks good
• SSP - system-id, port-range, vendor, ip-address, asset-owner, asset-administrator
• Implementation_common: script

Over any metaschema instance, XPath to find field definitions, not empty and with flags but no json-value-key:

//define-field[exists(flag)][not(@as-type='empty')][empty(json-value-key)]

[david-waltermire]

@wendellpiez Thanks. I'll go through this and make the changes in the refactor branch that is being worked on for #478 as well.

[david-waltermire]

This was addressed in PR #492.