Inconsistent definition of "versions" and "profiles" in Response

[dlemire60]

While both versions and profiles in a response should be an array of strings, they aren't defined that way in the specification. Extracting the relevant sections / content:

3.3.2.2 Response Results

*_Type: Results (Map{1..})_**

ID	Name	Type	#	Description
1	versions	Version unique	0..*	List of OpenC2 language versions supported by this Actuator
2	profiles	ArrayOf(Nsid)	0..1	List of profiles supported by this Actuator

3.4.2.4 Feature

Specifies the results to be returned from a query features Command.

Type: Feature (Enumerated)

ID	Name	Description
1	versions	List of OpenC2 Language versions supported by this Actuator
2	profiles	List of profiles supported by this Actuator

3.4.2.12 Namespace Identifier

Type Name	Type Definition	Description
Nsid	String{1..16}	A short identifier that refers to a namespace.

3.4.2.17 Version

Type Name	Type Definition	Description
Version	String	Major.Minor version number

For consistency, it seems that versions should be defined as ArrayOf(Version). If the intent is that an Actuator should respond with a single OpenC2 version that it supports, then the definition in 3.3.2.2 and 3.4.2.4 citing "List of ..." appears incorrect.

[davaya]

Multiplicity as in 0..* is a JADN extension that is equivalent to ArrayOf. Extensions are removed (unfolded into core types) whenever the schema is used, so versions is converted into ArrayOf(Version).

These two happen to be next to each other, making the two ways of doing the same thing (core and extended) obvious. Back at one of the Forum meetings we decided to use the Multiplicity column, but didn't specify a preferred way to use it. We could:

• leave things as they are, with an explanation
• remove the multiplicity column everywhere and always use ArrayOf()
• remove ArrayOf() everywhere and always use a * multiplicity

I don't have a preference. Multiplicity is used in UML diagrams because ArrayOf is a JADN invention (inherited from ASN.1) that doesn't exist in databases or RDF models, so keeping multiplicity is closer to what most data people expect.

[dlemire60]

I think my preference would be to use the * multiplicity. It seems like a more expressive way to convey the essential concept. Also, looking at the definitions in 3.3.2.2, it seems that the "unique" attribute / caveat should apply to both, but it's not evident that the ArrayOf() construct conveys unique (although maybe that's a rule of arrays that just isn't explicit / visible here).

[davaya]

Unique must apply to ArrayOf, since ArrayOf is a core construct, and extensions like multiplicity must be convertible to core constructs. We may not have any examples of ArrayOf unique in our tables.

[dlemire60]

I did a search of the LS for ArrayOf( and came up with 9 instances, of which 5 were (at least at first look) specification of data types and the remaining 4 were in explanatory or example text. The five are:

• 3.2 Message, table 3-1: "to" is ArrayOf(String) -- table has no multiplicity column
• 3.3.2.2, Response Results: "profiles" is ArrayOf(Nsid)
• 3.4.1.5 Features: "Features" is ArrayOf(Feature){0.10} unique
• 3.4.1.16 Properties: "Properties" is ArrayOf(String){1..*} unique
• 3.4.2.1: Action-Targets: "Targets" is ArrayOf(Enum(Target)){1..*} unique

Table 3-1 is not a property table and shouldn't be changed. profiles, features, and responses can all be changed to the multiplicity style (I'll create a PR for that).

Per @davaya: The table in 3.4.2.1 combines two data types: action-targets and targets, which should be its own type definition in its own section (i.e., 3.4.2.2). I'll create a separate issue for that.

[dlemire60]

Addressed in PR #397

Closing issue.