Closed dlemire60 closed 1 year ago
Either would work. There are three general approaches: 1) keep type definitions in alphabetical order 2) keep type definitions "close" to others that use them (depth-first tree walk) 3) add new definitions at the end
From a reader's perspective 1 and 2 are easier to use but both require renumbering. 3 is easier for the editor.
I prefer 2.
The current list is mostly alphabetical, with the exceptions of the malformed targets
, which would be second if we just split 3.4.2.1, and Command-ID
which is oddly placed near the end. The "pain" of renumbering isn't that great. Given on the order of 20-30 members of this set, the depth-first tree walk wouldn't be that hard to maintain, but we'd need to create the initial version. Can we leverage the JADN source to create a list ordered that way?
3.4.2 Data Types
Do it alphabetically.
A type that is created only to define another type can be kept with its parent. But our data types are intended to be re-used. I don't see anywhere except L4_protocol and port that "keep with parent" might apply, and even they could be referenced by future types. A type that is tightly associated with its parent and never referenced separately should appear in its parent's section, not with its own section number.
In the schema I moved Status Code from OpenC2-Response (its parent) to Data Types to be consistent with OpenC2-Command. Command and Response are the top-level types in one section, and all the referenced types are in another. Status Code should also be moved to 3.4.2.x in the LS document.
The table in 3.4.2.1 combines two data types:
action-targets
andtargets
, which should be its own type definition in its own section (e.g., 3.4.2.2). It may make more sense to movetargets
to a new 3.4.2.17, so that the intervening sections .2 through .16 don't need renumbering, but from a logical content perspective, inserting it as 3.4.2.2 probably would be better.