Placeholder topic for the discussion of the David’s webinar presentation.
@DavidJHoney, are there use cases when OSLC Servers would store a link to :requirementA with the query part, e.g. :requirementA?oslc_config.context=':globalStream1' (from Config Primer, §6).
One thing that left me bothering is that when a global configuration contains multiple streams of the same component, but the lookup is always in the same order, then on any timepoint the second stream of that component is never reached and would be redundant.
Where am I getting this wrong? Would the ordering of the streams be a feature of managing global configurations?
@Rots You are considering the resources in both configuration are similar. You will reach the second configuration when the requested resource does not exist in the first configuration.
My understanding is that the ordering of streams is indeed a feature of the managing Global Configurations. At least for IBM’s implementation, since I don’t think this is anywhere in the specification. @DavidJHoney do you confirm?
Aha, yes with partially-overlapping streams it makes more sense.
Then again, the next thought is that the selection always lists the versions, but there is no direct connection between the version URL and the concept (i.e. purely based on the global configuration and selections I can’t fully know which concepts are versioned), which means “resolving” the version selections to a concept either needs à priori knowledge about (all the) possible versions (yes, this should already be “available” in the local configuration) or worst case needs to resolve the version selections to see which concepts they actually refer to.
Edit: changed “non-overlapping” to “partially overlapping”
There could be an overlap between the configuration. From a common ancestor, a resource can be deleted in the first configuration and kept in the second. or be just new in the second.
With regard to your next thought: I think what you do is that you don’t ask the GC manager to resolve the version resource, but get the global configuration and parse through the contributions to determine which contributions is compatible, then look into your repository to get the proper version. In the case of a component skew, you might want to ensure that you test for the existence of the resource in all compatible configurations when you get a 404, and not just the first one. But the first you find is THE one.
That’s my understanding at least.
Yes, that’s certainly possible. One might want to create a link to the version of some concept resource in a particular configuration context rather than a specific version. The danger in doing so is that if a user views that resource in a different configuration context, the link would be resolved in the link’s specific configuration context rather than the selected configuration context. But that same issue would exist if the link was to a specific version resource URI.
1 Like
The example I used in the webinar was an airplane that used a configuration of a wing component and a configuration of a jet engine component. Both the wing and the engine might use a metric bolt, but use different configurations of that bolt. In that example, the top-level GC represents the airplane, and might have a child GC for the wing, and a child GC for the engine. In the context of the airplane GC, asking what version of bolt is used involves component skew and possible version skew. However, if you ask the same question in the more specific wing GC or jet engine GC, there won’t be component skew.
A global configuration management application might report on such version skew. For example, in the Rational Global Configuration Management application, if you selected the airplane GC, the user would see a warning about component skew. An application could also provide such indication if a user selected a global configuration that had component skew.
The OSLC Configuration Management spec doesn’t specify how component skew is resolved. That is, does not define which local configuration is chosen if there are two or more for a given component. However, a common approach used in Rational Jazz applications is to use a depth-first order, followed by the contribution order of siblings. Some industries might want to avoid component skew to minimize confusion. Others, such as those that have tight regulation regarding changes and safety compliance, might require use of component skew.
The specification does describe the idea that you resolve a concept resource in a configuration context - see section 11. Version Resolution in OSLC Configuration Management Version 1.0. Part 3: Configuration Specification. However, if there is component skew or version skew, the behavior is implementation dependent:
A server MAY perform an ordered search using the
oslc_config:contributionOrderproperty, and MAY have a way to indicate multiple possible version resolutions [CONFIG-RES-135].
Currently, Jazz applications will select the first local configuration matching the component and return the version of the specified concept resource selected by that local configuration.