Simplification of Profiles in data and API calls

[floydtree]

Objective: Define the usage of metadata.profiles in OCSF records. Update the server API that retrieves a schema, to be in congruence with the usage of metadata.profiles.

More Context

Potential path ahead.

1. metadata.profiles is made a required field.
2. If your data contains no profiles then metadata.profiles = [ ]
   1. Does absence of field mean there are no profiles set?
   2. In that case, does it allow for metadata.profiles to remain optional?
   3. Cast your vote here.
3. If your data contains a, b, ... z profiles then set metadata.profiles = [a, b, ... z]

Utilize the same strategy in the API calls.

1. ?profiles= OR NO profiles parameter should return vanilla schema definition.
   1. Although, not strictly related, this decision should be consistent with what we decide for metadata.profiles
2. ?profiles=x,y must return the schema with attributes from profile x & profile y

[paveljos]

Let's move this to a proposal, option 1.) make profiles required, and 2.) optional profiles, unset = no profiles.

[rroupski]

How are we going to get schema that includes all-profiles?

[floydtree]

Using metadata.profiles = [x, y, ..n]. Explicitly state the profiles that are needed.

I don't imagine an event class will have more than 2 or 3 profiles applied to it, if it does, then probably the event class definition is lacking and needs to be addressed. You as a user would always be in control and fully aware of which profiles are being used for you class.

I think being explicit is more preferable than a blanket "all" for profiles. Check the discussion here