As a Metaschema developer, in order to support extendable constraint systems that integrate as natively as possible with Metaschema concepts, I would like the ability to plug replace Metaschema with alternative policy/configuration languages adjustable to my use case.
Goals:
It was recently discussed in supply chain use cases that there are a number of popular policy and configuration languages for different policy engines and orchestration systems. Some are a blend of the two, and are particularly popular in the cloud-native and container workload communities of the software and service delivery world, Rego and Common Expression Language.
Initially, I am interested in long-term evaluation of CEL (over Rego and alternatives) given the community I am involved with and also because as a policy language it intentionally aligns its language specification and minimally required data types with that of binary format specification, Protobuf, as the specification discusses regarding dynamic values and many other refs in their spec. This seems very analogous and congruent with Metaschema, its datatypes, and Metapath.
I lay out the above areas of interests and background to identify two high-level goals that I believe are important, pending feedback from this project's maintainers.
[ ] A binding mechanism for target and any right-hand for an expression currently only supports Metapath (at this time, I believe that is only @target).
[ ] A binding/mapping mechanism for data type conversions between Metaschema data types and their equivalents in the pluggable alternative in the event another is chosen. (This seems separate, but equally different and important from what I inferred from conversation supporting a creation of this issue in the Metaschema chat in Gitter/Matrix.)
[ ] More to follow
Dependencies:
Nothing specific yet, but per discussion in the Matrix chat room this is an ambitious long-term goal that will have to come after many of the Metaschema 1.0.0 milestones are complete and we begin work on what we can describe here as a Metaschema 2.x roadmap goal.
Acceptance Criteria
[ ] All website and readme documentation affected by the changes in this issue have been updated. Changes to the website can be made in the docs/content directory of your branch.
[ ] A Pull Request (PR) is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR.
[ ] The CI-CD build process runs without any reported errors on the PR. This can be confirmed by reviewing that all checks have passed in the PR.
{The items above are general acceptance criteria for all User Stories. Please describe anything else that must be completed for this issue to be considered resolved.}
User Story:
As a Metaschema developer, in order to support extendable constraint systems that integrate as natively as possible with Metaschema concepts, I would like the ability to plug replace Metaschema with alternative policy/configuration languages adjustable to my use case.
Goals:
It was recently discussed in supply chain use cases that there are a number of popular policy and configuration languages for different policy engines and orchestration systems. Some are a blend of the two, and are particularly popular in the cloud-native and container workload communities of the software and service delivery world, Rego and Common Expression Language.
Similar but related, @wendellpiez referenced previous conversations about allow a SQL dialect to be used with Schematron, which is a little different but very similar and relevant as a yet another alternative.
Initially, I am interested in long-term evaluation of CEL (over Rego and alternatives) given the community I am involved with and also because as a policy language it intentionally aligns its language specification and minimally required data types with that of binary format specification, Protobuf, as the specification discusses regarding dynamic values and many other refs in their spec. This seems very analogous and congruent with Metaschema, its datatypes, and Metapath.
I lay out the above areas of interests and background to identify two high-level goals that I believe are important, pending feedback from this project's maintainers.
@target
).Dependencies:
Nothing specific yet, but per discussion in the Matrix chat room this is an ambitious long-term goal that will have to come after many of the Metaschema 1.0.0 milestones are complete and we begin work on what we can describe here as a Metaschema 2.x roadmap goal.
Acceptance Criteria
{The items above are general acceptance criteria for all User Stories. Please describe anything else that must be completed for this issue to be considered resolved.}