Include grammar in language specification

The Language and the (unwritten) Architecture should be treated *together* as an abstract Platform Independent Model (PIM) and all things downstream as specific Profiles for specific technology and interaction choices (Platform Specific Models)(PSMs).

As generally used, a PSM is a specific set of extensions to or constraints on a PIM, and therefore conformant to the PIM. Each PSM then is interoperable with any other PSM by a sort of transitory rule, as each can be transformed into the PIM, and form the PIM into the other PSM. A PIM is never meant to be a specification in and of itself, although I have developed in the past a specific PSM that was as close to the PIM as possible, for use in integrating into other specifications.

As OpenC2 moves beyond a set of Products with mere faceplate conformance to an interoperable suite of communication specification, each with quite different assumptions and serialization requirements and communication challenges, the PIM-PSM model is how one enables long-term wide interoperability.

Although it predates the PIM-PSM language, consider the standard 802.11 as a PIM. It is unlikely that if you and I sat down with the Standard and began coding and selecting radios that our two systems would be able to interoperate. The industry has instead created a number of profiles that *are* interoperable (802.11 A, B, G, C, AC) and any device that opts to implement more than one of these profiles can easily route between the two because of their mutual conformance with the 802.11 PIM.

The rule that a Command must implement only one action (or one target) MAY be part of a Restriction Profile created as a PSM of the PIM, or other Profiles that permit them must explain how to translate to the PIM, but either model would fit. In either case, that translation to the Abstract PIM defines how interoperable routing or aggregation is achieved.

Under this approach, we HAPPEN to describe the abstract information model in JSON, and we require profiles for JSON-based serialization profiles to conform, to that in the PIM, but we do not restrict other serialization schemes. Any other serialization MUST define how it treats each PIM data element, i.e., define its conformance to the PIM.

In a similar vein, we use HTTPS to describe the interaction patterns of OpenC2, and MAY declare that HTTPS bindings must conform. Other Bindings MUST define how they conform to the interaction patterns of the PIM.

A Profile then defines the Serialization and/or Bindings to create a specific PSM

I think this is the path to achieving long-term interoperability and evolvability within this Specification and its derivative Specifcations

openc2-comment message