I don't think we have a strong scenario to differentiate a 'Plan item' from a 'Task'. A Task could be a plan item and the inverse could be true. I was considering this with my proposal as well.
How about we keep it to these 3: 1. "defect" - Used by QM tools in reporting defects. Find and fix a defect scenario. 2. "task" - Used by QM and PPM tools for tracking and planning. Agile planning of a change request scenario. 3. "requirementsChangeRequest" - Used by RM tools for tracking requirerments chagnes. Change management of requirements scenario. Thanks, Steve Speicher | IBM Rational Software | (919) 254-0645 > From: Samit Mehta/San Francisco/IBM@IBMUS > To: [email protected] > Date: 06/24/2010 02:37 PM > Subject: Re: [oslc-cm] Proposed values for "usages" identifies for > factories and dialogs > Sent by: [email protected] > > > I would suggest at least one additional use cases for Creation > Factory. Of course we should only add them if someone steps up to > use them, otherwise defer putting it in specification till someone > requests them. > > 4) "task" - Used by PPM tools for tasks that are at the next level > to Plan Items. This may be something that Tasktop could also > consider using - but I don't believe that they are creating tasks - > just querying / updating existing ones. > > Also, is there any way to make the <oslc:usage> more generic, so > that it can be used as a property value when querying for change > requests, and maybe even for the delegated UIs? > ____________________________________________ > Samit Mehta > mailto:[email protected] > IBM Rational Software - Business Development > > [email protected] wrote on 06/24/2010 09:44:10 AM: > > > To follow up from an action yesterday, I was to propose how we could > > leverage "usages" [1] to better allow for programmatic access by clients > > for certain scenarios. Please provide some feedback on this approach and > > the list of usage identifiers > > > > I see 3 primary cases (with usage identifiers): > > 1. "defect" - Used by QM tools in reporting defects. Find and fix a > > defect scenario. > > 2. "planItems" - Used by QM and PPM tools for tracking and plannings. > > Agile planning of a change request scenario. > > 3. "requirementsChangeRequest" - Used by RM tools for tracking > > requirerments chagnes. Change management of requirements scenario. > > > > The <oslc:usage> is optional and intended to be a *hint* to clients as to > > the purpose of creation factories, query capabilities, creation dialogs > > and selection dialogs > > > > To support these cases, an entry for a 2.0 oslc:ServiceProvider could be > > represented in this way: > > > > <oslc:service> > > <oslc:Service> > > <oslc:domain>http://open-services.net/ns/cm#</oslc:domain> > > <oslc:creationFactory> > > <oslc:CreationFactory> > > <dc:title>Location for creation of ChangeRequests that are > > Defects</dc:title> > > <oslc:label>Defect</oslc:label> > > <oslc:creation rdf:resource="http://example.com/defectFactory"; /> > > <oslc:shape rdf:resource="http://example.com/crShape"; /> > > <oslc:resourceType> > > http://open-services.net/ns/cm#ChangeRequest</oslc:resourceType> > > <oslc:usage>http://open-services.net/ns/cm#defect</oslc:usage> > > </oslc:CreationFactory> > > </oslc:creationFactory> > > </oslc:Service> > > </oslc:service> > > > > > > [1] - > > http://open-services.net/pipermail/oslc-core_open-services.net/2010- > > June/000313.html > > > > Thanks, > > Steve Speicher | IBM Rational Software | (919) 254-0645 > > > > > > _______________________________________________ > > Oslc-Cm mailing list > > [email protected] > > http://open-services.net/mailman/listinfo/oslc-cm_open-services.net > _______________________________________________ > Oslc-Cm mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-cm_open-services.net
