I have one particular curiosity about OSLC, aside from my daily job ;), that is the following. In SECollab, we have developped the ability to create custom links, tailored to the exact traceability semantics a user / company wishes to accomplish. What feels frustrating is that there is no way whatsoever to share those custom links definition with other OSLC tools.
Has it ever been considered to promote such a spec where link definitions can be created and shared across all tools in the lifecycle? Which would have community / tool providers create a tool tool where we would just “load” or “enable” definitions for CM and RM if we only need those, and “boom, you got it”: the connected tools now know about these domains, project associations and link types. And they can create links with remote tools, should the remote tools advertise Service Providers for the corresponding domains. With comparision to letting each OSLC CM compatible tool re-define “oslc_cm:relatedChangeRequest”… and that’s the easy part. Understanding all Project Associations, as defined by IBM within their tools… that was the hard part.
Well, that’s it. Does that sound like a reasonable curiosity? I’d love to hear your thoughts.
I do share your frustration very much. I am one of the OP members who is in favour of introducing profiles for OSLC specs. The reason is that OSLC specs have very little MUSTs today and changing that may be breaking. Many implementers do just the bare minimum and I would like to be able to say they are in full compliance with the OSLC Light Profile, for example. Only those who implement specs with decent completeness could say they comply with the OSLC Full Profile. I am in the minority at the time in the OP wrt to this position, sadly.
Now, regarding your question more directly.
I am trying to think how would it be possible under current OSLC specs and the only thing that comes to mind is to define those links as OSLC AM Link Type Resources and require any Server that receives such links to fetch unknown Link Type Resources instead of rejecting/removing the properties. @jamsden@ndjc please weigh in here if possible.
Ok, this sounds a little bit more than “link definitions can be created and shared across all tools”. You would need to explain how do you see that implemented. But if I take your proposal from above and stretch it, you are suggesting to define all existing resource traceability link predicates we have today in other speces as AM LTR so that they can be loaded dynamically without actually implementing a corresponding spec?
Not sure I follow but let’s see what I wrote above makes sense and then see further.
As for the Light Profile vs. Full Profile, I am unsure it would actually solve anything, but create complexity and potential confusion.
The links as they are defined are suggesting a way to work with the data, as a supposedly appropriate workflow. A recommended workflow even, for managing traceability.
How I understand the ultimate purpose of those specs is “this is how you should represent your data”:
for others to be able to understand them (because they share the same shapes),
so that we can produce actual reports on data from all connected tools
But the linking does not necessarily have to be expressed within the specs IMO. We might have a dedicated spec that expresses how to deal with Link Types across applications.
That’s about it. This is somehow what we achieved in SECollab, with a full implementation of a custom Tracebility Management feature (we define custom Resource Types and custom Link Types that use those custom Resource Types as start/end of our link). Background: this was for a customer to have more precise links than what the specifications currently offers, so they can support their A-SPICE processes using SECollab.
Now the linking between the data, I’m afraid, should not necessarily be so deep into each spec. Don’t get me wrong, I’ve implemented these a few times now, and it works great. But it offers too little flexibility IMO. Hence the custom development we had to do for our customer on the custom traceability management feature.
I believe the Linking should be a spec of its own. “Workflow Management”? “Linking Management”? Whatever the name, this spec should explicit:
how to create a link type: what is its source, target, property definition, backlink if any, who owns the link (should it be discovered?)…
for connected applications how to discover the Link Types they should use, so that each of those applications can accept the properties when they see them on their resources, as well as add the corresponding properties to the resource shapes (that is, if they use the resources shapes)
And this spec should refer to existing specs as for the default links to be advertised (I would also advocate for making the Jazz implementation of Project Associations a de facto standard as part of this, and adding them the default setup too… because who wants to setup IBM ELM just to discover this on his own because there’s no public documentation for this??)
Introducing this means that, as an implementer, I would:
Use the default properties existing on the shapes of each specifications as they are today, unless 2. is valid
Use custom properties based on the Link Types created in a “Workflow management” if such application is registered and the rootservices says “I’m open to work with a Workflow Manager” (same as GCM’s current implementation)
Enable creating project associations that are truly homogeneous between all OSLC-enabled application in my workflow.
Enable creating links based on the link types that are “enabled” by the actual project associations on my project
And the Link Types would depend on the Global Configuration, if it is enabled.
I truly believe that would make the solution more customizable for each customer’s internal context and expectations.
And it could even come with an open source implementation… Which would greatly simplify the whole logic.
Let’s imagine…
Services already declare what Selection / Creation Dialogs they offer. And the corresponding Resource Type. If you leverage this, you can determine from the “Active Workflow” which Link Types to display in your UI… and now can even dream of a Web Component implementation of this, that any implementer would just add to its application, and skin, to provide a perfect implementation of the Linking between whatever tool he wants, leaving her/him with the task of mapping the application’s data to OSLC shapes… the easy and fun part… ok, this is just for web applications and not desktop apps… and I probably dream too much, or am I too tired and my mind is just wandering off
Thank you for an extended reply and a spec proposal!
I fully agree, having LinkTypes sit in AM is awkward given they could be used in every domain.
That is a very insightful look at OSLC: after all, we have been promoting linking as a key activity. It makes sense that there is a simple way to do that without getting into the full details of the spec.
Wait, so you are proposing a spec so that any tool can create a link type definition aspice:ProcessImprovementIssue and to create such a link type (i.e. POST this definition) in every tool in the toolchain? Or simply how to declare a shape of that link so that it can be defined in one tool and have its definition be discoverable across the toolchain?
Right, we are now working on a IANA application for a .well-known/oslc/ address and planning to allow discovering a “root” service provider catalog together with the rootservices.xml document with zero configuration. I think that adding TRS feed information as well as your proposed Link Type discovery would fit nicely into this (most likely as a query cap to an SPC but it’s just an idea).
I must admit my knowledge in this area is pretty limited but I would be interested to learn more about the problem Associations solve and the approach.
I think this is were I start losing the thread but here comes a proposal: would you be interested to join of the calls and present your vision or at least the list of grievances with the way OSLC enables (or fails to enable) linking today? I think OSLC can definitely benefit from a spec that defines better links.
I know that @jamsden has strong opinions on the AM spec but @axel.reichwein what does the board think about this? @jad I know that LyoD supports defining all kinds of resources and properties but ones that are fixed at the design time as opposed to being discoverable at the toolchain setup phase. Would you be interested in this?
This would be fantastic! I mentioned a few times that we shall evolve Delegated UI to WebComponents but not many people listened really. I also think you have dreamed about thought this through much further than me. @axel.reichwein ping, I mentioned this in the calls before and even suggested OSLC WebComponents discussion for the OSLCfest agenda AFAIK.
I would like to better understand the scenario. Sorry for catching up and joining the discussion late! In general, I’m in favor of facilitating the discovery of link types. I suggest to have Fred, or someone who understands the scenario to present it at at OSLC meeting.
I would prefer discovery, but I’m guessing it generates a few challenges in how we make those link types available in each tool of the toolchain. Still… we can do TRS, so we should be able to manage this
That sounds very nice.
I might be a bit too much into the “all the folks out there doing OSLC have ELM somewhere”, which might not be true at all Still, having worked on both Polarion (1 single multi domain project association) and ELM (1 project association per domain couple, be CM-CM, CM-RM, etc.) makes not having these create a gap between actual configuration and perceived configuration.
Also, when a tool supports multiple domains, you might want to filter out some domains for the Linking For example, SECollab only supports linking to CM artefacts because we filter out the corresponding project associations. We do have these enable inside the project.
If I take another last somehow real life example: consider we had support for test management in OSLC Connect for Jira, then customers might want to create a project association to 1 project because it holds the issues, hence the CM-whatever project association. And create a second project association to another project holding the tests. Hence the QM-whatever project association.
Project associations avoid enabling useless link types between projects to ease the life of the user doing traceability.
I’ll be glad to. Honestly, I tried once, but failed to connect on time And those last few weeks, I feel like I’m already spending too much time in meeting… so I kinda skipped the last 2 voluntarily! Unexpected confinement consequences! Time to join though. @axel.reichwein I’ll make it to the next one so we can discuss the larger scenario
I’m unfortunately not enough of a specialist of A-SPICE and ISO26262 to answer this. I’ll see if someone at the office can take on this.
@andrew@axel.reichwein I’ll be glad to discuss this shared links definition topic next thursday during the OSLC OP meeting.
Here’s the feedback I got on the differences between the mentioned standards:
Blockquote Both are iso standards. 26262 is all about the probability of failure and mitigating that with regards to process implementation and technical content. ASPICE/iso330xx is a process capability assessment. They overlap alot but the 26262 is another bunch of attributes you have in your rm tool. And a few extra analysis documents.
And those last few weeks, I feel like I’m already spending too much time in meeting… so I kinda skipped the last 2 voluntarily! Unexpected confinement consequences! Time to join though.