OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

openc2 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Use of the word "profile"


Toby,

Could you share your thoughts on the use of the word âprofileâ. We currently use the terms âactuator profileâ (which we sometimes shorten to just âprofileâ but that now sounds dangerous) to describe the specification of how the function of an actuator behaves. We also use the term âprofileâ as part of conformance requirements (a âconformance profileâ??)  to describe a type of subset of conformance requirements (not sure thatâs a good definition but I stole it from OASIS doc which stole it from ISO). I think you are using it slightly differently (In the PIM/PSM context) and Iâd like to understand better.

 

Duncan Sparrell

sFractal Consulting LLC

iPhone, iTypo, iApologize

I welcome VSRE emails. Learn more at http://vsre.info/

 

 

From: TC OpenC2 <openc2@lists.oasis-open.org> on behalf of Toby Considine <Toby.Considine@unc.edu>
Date: Tuesday, October 23, 2018 at 11:34 AM
To: Joseph Brule <jmbrule@radium.ncsc.mil>, TC OpenC2 <openc2@lists.oasis-open.org>
Subject: RE: Re: [openc2] One item I've noticed on the current CSDs that will need to be fixed

 

Two points, one small and one large:

 

Small:

 

The rule is âwhere the two are in conflictâ.  Any additional elements in the text are *not* in conflict. But that is a shoddy answer to work where the fit and finish are not complete.

 

Large:

 

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.

 

I had intended this as an observation for the Public Review, but bring this out now only because it seems a sticking point to release.

 

tc

 

From: openc2@lists.oasis-open.org <openc2@lists.oasis-open.org> On Behalf Of Brule, Joseph M
Sent: Tuesday, October 23, 2018 10:35 AM
To: openc2@lists.oasis-open.org
Subject: Re: [openc2] One item I've noticed on the current CSDs that will need to be fixed

 

All,

 

Sent on behalf of Dave Kemp:

 

===== tear line =====

 

         I do have a question. One of the reasons for the discussion and the "text beats schema" wording is that the schema is not as complete as the text (at least in the Language Spec). In particular there are statements in the text not represented in the schema. If the schema is the "more normative" text, would that mean the additional text constraints do not need to be met?

 

The schema contains the content of the tables in Section 3 of the Language Spec, and those tables are generated mechanically from the schema by a script.  The schema does not have anything to do with text outside of the tables, so it does not supersede or invalidate or conflict with that text.

 

In addition, the table Description column generated from descriptive text in the schema is non-normative, which is one of the reasons comments are stripped from Annexes A and B of the document.  Normative requirements not represented by the syntax appear in the text of the document, not in the syntax table comments.

 

In cases where the text DOES duplicate the schema, e.g. from Section 3.3.1:

         Usage Requirements:

         Each command MUST contain exactly one action.

 

â the table and the schema say that the cardinality of action is 1.   So in the event of a conflict, both the table and the schema are authoritative over any redundant requirements contained in the text.

 

 

         Itâs the automated testing of valid messages that I was worried about. I was worried you could claim passed just on the schema even if it violated a statement in the text. But my reading of your email is in text, not in schema doesnât count as not in schema wins.

Yes.

         If the text conflicts with a table (by attempting to permit something syntactically invalid), the table (and the schema) win.

         If there is no conflict because the text restricts something permitted by the table (and schema), then any normative requirements contained in text apply.

         Text that does not state a normative requirement doesnât affect conformance.

 

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]