Configuration Context
Overview / Introduction
What is this resource?
Configuration Context in the SBE Platform is a mechanism to control what other branches are visible and accessible to a given branch. Each branch has a default (empty) configuration context, which can be extended by adding additional branches.
Why is it important in the system?
It allows users to logically group related branches for modeling and linking purposes without globally merging datasets. This supports modular development, reuse, and access control.
Where it sits in the system:
Configuration Contexts operate at the branch level, mediating lifecycle, ontology, and model access for operations within a specific workspace.
Conceptual Role
Problem it solves:
Without a configuration context, the system would have no way of validating references across branches. Users would need to manually manage links between ontologies, models, or classes. Configuration Context solves this by allowing scoped visibility across related sets.
Real-world abstraction:
Think of it like a "view" into multiple linked workspaces. By adding other branches into your context, your set can see and interact with their contents, much like importing packages in programming.
System limitations without it:
Configuration context is an important component to both transformation and link management. transformation, it sets the ontologies available to be used during publish and refreshes for a channel. For link management, model branches in a channel’s context defines which models a channel is allowed to link to. For subscriptions, the clone branch is automatically added to a channel’s context, making it possible to links between subscriptions and a channel’s authoritative models. In the case of thread linking, a channel is allowed to establish thread links to another channel only if the destination channel is in context. The same is true for seeing inbound thread links from another channel.
Design Rationale
Design decisions and trade-offs:
Configuration Contexts are recursively composable. When you add a set that has its own context, its context is also pulled in, forming a transitive closure over accessible sets.
Each branch has exactly one Configuration Context, simplifying resolution logic.
Current implementation does not use BOM-style semantics in favor of a simpler and more predictable model.
Constraints:
Only supports contextual visibility at the branch level.
BOM-type Configuration Contexts are not currently supported but may be explored in the future.
Relationship to Other Resources
Dependencies and integrations:
Models: Allows models to be based off of classes that are in the model branch’s context.
Classes: Allows classes to reference classes in different branches that are in context. These references are usually represented as ancestors or as valid class references in relation specs.
Branches: The basic units that make up and extend a configuration context.
Role in architecture:
It acts as a visibility filter and access layer. A configuration context defines what is "in scope" for a given branch’s operations.
Conceptual Usage Patterns
General usage:
Start with an empty context.
Add required branches (e.g., ontologies or model sets).
Operations like creating models or links will now reflect added visibility.
Recursive inheritance pattern:
Adding a context that itself includes other sets will bring in the entire chain.
Common Pitfalls, Misunderstandings, and Troubleshooting
Misunderstandings:
Assuming Configuration Contexts support full BOM resolution.
Thinking Configuration Context replaces branches — it augments visibility, not structure.
Common pitfalls:
Forgetting to include the ontology branch when setting up a channel/model branch — results in missing classes.
Linking errors when target models are not in context.
Troubleshooting tip:
Always verify your context includes all required branches by checking its full sub-context resolution.