[Community] OSLC RM - meetings during July

Thu Jul 9 14:34:49 EDT 2009

Andy and Simon make good points, and I think that discovery of related 
assets is certainly important.  as Scott points out, the CM team are 
looking at this too, and from a "i know nothing other than the URI of the 
CR".   the friendliness of the URIs Simon drew is beguiling, giving the 
impression that the path to the resource can be trusted to mean something. 
 Stability of URIs is also important and the two concerns are not always 
compatible.

As well as thinking about all the relationships a requirement might have 
with its contexts, we ought to think about other relationships - 
satisfaction, validatedBy and so on.

What happens in response to a GET on a requirement URI: should all of 
these relationships be represented?  That won't scale but perhaps it 
doesn't need to?

 An alternative is to separate the requirement representation from the 
resources to which it is related, as the CM specification does.  (See 
http://open-services.net/bin/view/Main/CmRestApiV1?sortcol=table;up=#Managing_multi_valued_properties
.)   So the requirement could indicate the presence of a group of links 
(collected by type?).

In the CM approach links are not first-class in the resource model - i 
can't GET a link, nor can I DELETE one: they are not resources.

best wishes,
    -ian

ian.green at uk.ibm.com (Ian Green1/UK/IBM at IBMGB)
Chief Software Architect, Requirements Definition and Management
IBM Rational

From:
Scott Bosworth <bosworth at us.ibm.com>
To:
community at open-services.net
Cc:
Andreas.Keis at eads.net, Dominic Tulley/UK/IBM at IBMGB, Simon Wills 
<simon.wills at integrate.biz>, George DeCandio <decandio at us.ibm.com>, 
david.ruiz at ravenflow.com, Pratik Shah <ppshah at us.ibm.com>, Sky Matthews 
<sky at us.ibm.com>, rainer.ersch at siemens.com, Brenda.Ellis at ngc.com, Steve 
Abrams <sabrams at us.ibm.com>, randy.e.vogel at accenture.com, Andrew J Berner 
<ajberner at us.ibm.com>, srinivasan.renganathan at citi.com, Chris 
Mcgraw/UK/IBM at IBMGB, Ken Jackson/UK/IBM at IBMGB
Date:
09/07/2009 15:09
Subject:
Re: [Community] OSLC RM - meetings during July
Sent by:
community-bounces at open-services.net

Great points Simon, I agree completely. Not to jump to spec too quickly, 
but it may be helpful to look at the OSLC-CM 1.0 spec (
http://open-services.net/bin/view/Main/CmSpecificationV1) and its 
approaches for establishing project context (service discovery), 
collections of change-requests, and simple query services. We may be able 
to learn something on how we might think about requirements collections 
from this vantage point. 

To Andy's point, rather than saying that a requirement should have a "back 
pointer" to the project, we might instead say that given the url of a 
requirement, we may have a need to discover the project context (or maybe 
other requirements collection contexts?). I think this is probably a 
common scenario - someone receives the requirement url in an e-mail and 
that's all they have. This is a topic that has come up in the CM 2.0 
directions as well (see 
http://open-services.net/bin/view/Main/CmArchitecturalDirectionV2 -- 
Reverse service discovery).

Thanks...Scott

p.s. Ian - I think the to-do Steve and I took was to think about how to 
better organize the scenarios overall in the site given the cross-domain 
nature many of them exhibit.

Scott Bosworth | IBM Rational CTO Team | bosworth at us.ibm.com | 
919.486.2197(w) | 919.244.3387(m) | 919.254.5271(f)

Scott Bosworth---07/09/2009 09:46:16 AM---Hi all - moving this discussion 
to the mailing list...Scott

From:

Scott Bosworth/Raleigh/IBM at IBMUS

To:

community at open-services.net

Cc:

Andreas.Keis at eads.net, Dominic Tulley <dominic.tulley at uk.ibm.com>, Simon 
Wills <simon.wills at integrate.biz>, George DeCandio/Raleigh/IBM at IBMUS, 
david.ruiz at ravenflow.com, Pratik Shah/Durham/IBM at IBMUS, Sky 
Matthews/Durham/IBM at IBMUS, rainer.ersch at siemens.com, Brenda.Ellis at ngc.com, 
Steve Abrams/Watson/IBM at IBMUS, randy.e.vogel at accenture.com, Andrew J 
Berner/Dallas/IBM at IBMUS, srinivasan.renganathan at citi.com, Chris Mcgraw 
<chris.mcgraw at uk.ibm.com>, Ken Jackson <KEN.JACKSON at uk.ibm.com>

Date:

07/09/2009 09:46 AM

Subject:

Re: [Community] OSLC RM - meetings during July

Hi all - moving this discussion to the mailing list...Scott

Scott Bosworth | IBM Rational CTO Team | bosworth at us.ibm.com | 
919.486.2197(w) | 919.244.3387(m) | 919.254.5271(f)

"Simon Wills" ---07/09/2009 09:23:21 AM---To elaborate on Andy’s comment 
(and noting that I missed the last call where this was discussed) ...

From:

"Simon Wills" <simon.wills at integrate.biz>

To:

Andrew J Berner/Dallas/IBM at IBMUS, "Ian Green1" <ian.green at uk.ibm.com>

Cc:

<Andreas.Keis at eads.net>, <Brenda.Ellis at ngc.com>, "Chris Mcgraw" 
<chris.mcgraw at uk.ibm.com>, <david.ruiz at ravenflow.com>, "Dominic Tulley" 
<dominic.tulley at uk.ibm.com>, George DeCandio/Raleigh/IBM at IBMUS, "Ken 
Jackson" <KEN.JACKSON at uk.ibm.com>, Pratik Shah/Durham/IBM at IBMUS, 
<rainer.ersch at siemens.com>, <randy.e.vogel at accenture.com>, Scott 
Bosworth/Raleigh/IBM at IBMUS, Sky Matthews/Durham/IBM at IBMUS, 
<srinivasan.renganathan at citi.com>, Steve Abrams/Watson/IBM at IBMUS

Date:

07/09/2009 09:23 AM

Subject:

RE: OSLC RM - meetings during July

To elaborate on Andy’s comment (and noting that I missed the last call 
where this was discussed) ...

Requirements collections can mean many things. They may be related to 
application/project structure (e.g. subsystem X); they may time related 
(e.g. phase B); they may represent any arbitrary grouping of related 
requirements based on some classification. 

This has implications on cardinality. One collection may contain many 
requirements. But one requirement may also be a member of many collections 
(e.g. it may be re-used across projects; it may belong to collection of 
key integrity requirements at the same time as being in the collection of 
requirements that are to be implemented in phase B). 

This isn’t an issue in terms of addressability, in that it’s perfectly 
valid for one resource to be designated by multiple URIs. Hence a single 
requirement resource might have a canonical URI (e.g. 
/world/requirements/R1027), while also being addressable within the 
context of one or more collections (e.g. 
/world/projects/Project12/requirements/R32 and 
/world/applications/App14/requirements/R527). In both cases, it’s 
desirable for a GET on a given URI to return related URIs (e.g. a GET on a 
collection-based requirement URI returning not only a representation of 
the requirement, but also listing the canonical URI of that requirement in 
its related resources).

If I understand Andy correctly, he is suggesting an ‘either/or’ situation 
(i.e. the collection points to the requirements, or the requirement points 
to the collection). I would suggest that real world needs means that the 
answer must be ‘both’. But then maybe I’ve missed Andy’s point ...

Simon

PS and don’t forget that collections may be simple buckets, or they may 
organise their requirements into some hierarchical structure ...

Simon Wills
Managing Director
integrate systems engineering ltd
m: +44 (0)7967 091824
t: +44 (0)1225 859991
f: +44 (0)1225 859993
e: simon.wills at integrate.biz
w: www.integrate.biz

From: Andrew J Berner [mailto:ajberner at us.ibm.com] 
Sent: 09 July 2009 13:08
To: Ian Green1
Cc: Andreas.Keis at eads.net; Brenda.Ellis at ngc.com; Chris Mcgraw; 
david.ruiz at ravenflow.com; Dominic Tulley; George DeCandio; Ken Jackson; 
Pratik Shah; rainer.ersch at siemens.com; randy.e.vogel at accenture.com; Scott 
Bosworth; Simon Wills; Sky Matthews; srinivasan.renganathan at citi.com; 
Steve Abrams
Subject: Re: OSLC RM - meetings during July

One comment about the "requirement set": 

In some cases, it may really be a list of requirements, but I think the 
bigger issue is that a requirement is related to either a project or 
application....this means that either that related resource should have a 
list of requirements (identified by URL so you can get a resource 
representing each requirement) or that the requirement should have a 
reference ("back pointer") to the project/application. In data modeling 
terms, is it an identifying relationship (thus the requirement has the 
back pointer) and if so, to what? 

Andy Berner
Lead Architect, ISV Technical Enablement and Strategy
IBM Rational Business Development
972 561-6599
ajberner at us.ibm.com

Ready for IBM Rational software partner program - 
http://www.ibm.com/isv/rational/readyfor.html 

OSLC RM - meetings during July

Ian Green1 
to: 
Andreas.Keis, Andrew J Berner, Brenda.Ellis, Chris Mcgraw, david.ruiz, 
Dominic Tulley, George DeCandio, Ken Jackson, Pratik Shah, rainer.ersch, 
randy.e.vogel, Scott Bosworth, simon.wills, Sky Matthews, 
srinivasan.renganathan, Steve Abrams 
07/09/2009 05:17 AM

Hello all, 

the minutes from last meeting are on the wiki 
http://open-services.net/bin/view/Main/RmMeetings20090706. Steve and Scott 
took an action which i have missed - do either of you recall that? 

I'm on holiday August so will not be able to attend the regular scheduled 
meetings 13th and 27th July. 

Can I ask for a volunteer to chair either one or both of those calls? 
We need to discuss the specification needs for the scenarios A and B. 
Torge touched on this on our last call. 
What are the resources we need to describe in the specification? 
What actions must the API support over these resources? 
Are the link types fixed by the specification, or are they open? 
What is a requirement collection/set? 

best wishes,
-ian

ian.green at uk.ibm.com (Ian Green1/UK/IBM at IBMGB)
Chief Software Architect, Requirements Definition and Management
IBM Rational 
_______________________________________________
Community mailing list
Community at open-services.net
http://open-services.net/mailman/listinfo/community_open-services.net

_______________________________________________
Community mailing list
Community at open-services.net
http://open-services.net/mailman/listinfo/community_open-services.net

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20090709/2972d20b/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20090709/2972d20b/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20090709/2972d20b/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20090709/2972d20b/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20090709/2972d20b/attachment-0003.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20090709/2972d20b/attachment-0004.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20090709/2972d20b/attachment-0005.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20090709/2972d20b/attachment-0006.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20090709/2972d20b/attachment-0007.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20090709/2972d20b/attachment-0008.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20090709/2972d20b/attachment-0009.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20090709/2972d20b/attachment-0010.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20090709/2972d20b/attachment-0011.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20090709/2972d20b/attachment-0012.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20090709/2972d20b/attachment-0013.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20090709/2972d20b/attachment-0014.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20090709/2972d20b/attachment-0015.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20090709/2972d20b/attachment-0016.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20090709/2972d20b/attachment-0017.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20090709/2972d20b/attachment-0018.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20090709/2972d20b/attachment-0019.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20090709/2972d20b/attachment-0020.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20090709/2972d20b/attachment-0021.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20090709/2972d20b/attachment-0022.gif>