Ah, right good point. We should provide some guidance on how to deal with the fact that these exist today, and how to move forward. That makes sense.
Just off the top of my head, I'd say, the guidance would be to 1) stick with one in all future implementations, 2) clients should not expect to automatically see the other if the one exists. That means they'll have to write queries to look for both. I am sure some other thoughts will pop up. Thanks, jim conallen Rational Design Management (DM) Integration Architect, OSLC AM Lead [email protected] Rational Software, IBM Software Group From: Nils Kronqvist <[email protected]> To: James Conallen/Philadelphia/IBM@IBMUS, Cc: [email protected] Date: 02/14/2013 03:37 PM Subject: Re: [oslc-core] Minutes for 13 Feb OSLC Core workgroup meeting Hi, I agree that the bi-directional links are likely to cause issues - one being the example I mentioned below. So believe going for uni-directional is good. But bi-directional (e.g. oslc_cm:tracksRequirement and oslc_rm:trackedBy) are part of current CM/QM/RM specs, right .. so might make sense recommending including recommendation how to treat these or at least clarify and provide rationale why moving away from that pattern? Rgs, /N On 14 feb 2013, at 18:05, James Conallen <[email protected]> wrote: Hi Nils, Actually the lack of guidance on how to manage back links is not that because we don't believe back links are a good idea. It was an implementation specific solution to an implementation specific problem (displaying and querying for link information when in the context of the object of a link), that quite frankly causes more harm than good over time (imho). The guidance re-affirms the basic nature of a link; a single directional statement. We also go to great pains to not recommend the definition of 'pairs' of link types. This is an artificial concept that again causes more harm than good, over the long haul. While we don't define pairs of links, we do allow the definition of link labels for use in user interfaces, which may be different if in the context of the subject or the object. But this is not a separate link type predicate. Thanks, jim conallen Rational Design Management (DM) Integration Architect, OSLC AM Lead [email protected] Rational Software, IBM Software Group <graycol.gif>Nils Kronqvist ---02/14/2013 10:21:02 AM---Hi, A question around Links .. From: Nils Kronqvist <[email protected]> To: "[email protected]" <[email protected]>, Date: 02/14/2013 10:21 AM Subject: Re: [oslc-core] Minutes for 13 Feb OSLC Core workgroup meeting Sent by: "Oslc-Core" <[email protected]> Hi, A question around Links .. Links are uni-directional, but often come in pairs, e.g. oslc_cm:tracksRequirement and oslc_rm:trackedBy. And I assume a not too uncommon case is where you don't have write access in "the other" resource when setting up a link -- i.e. failing to create the "back link". If for example creating a link from RTC to another e.g. CM provider where RTC fails to create back link, RTC will provide warning dialog and allow to back out or proceed. As far as I can see there is no guidance in the specs around expected behavior here. Needed? Is the "OSLC connected system" inconsistent when not all back links are in place .. or .. as the http://open-services.net/wiki/core/Find-all-links/ suggest, to find all links you need to ask all service providers .. Rgs, /N Nils Kronqvist [email protected] phone: +46 76 1279272 www.find-out.se On 13 feb 2013, at 18:41, Michael F Fiedler <[email protected]> wrote: Minutes: http://open-services.net/wiki/core/Meeting20130213/ Regards, Mike Michael Fiedler IBM Rational Software [email protected] 919-254-4170 _______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net _______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net
