OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-promcode message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [oslc-promcode] provider/client design problem about collects from Plan or Report


I suggest that there should be no automatic inclusion of child or
related managed items in Plans (or other collections). The initial
content of a Plan should be set explicitly by POST and then explicitly
modified  by PUT. In practice, the client would GET the current Plan,
update its contents, then PUT it.

This approach keeps the server logic simple and avoids the need to
make a lot of decisions about the correct behaviour.

If more complex behaviour is desired, then it can be implemented by
the client using the basic API. If people later decide that the API
should directly support more complex behaviour, then we can add it.

Our general API design approach should be to start with the simplest
API that supports the use cases, and then add more complex behaviour
based on usage experience.

-- Arthur

On Fri, Jul 10, 2015 at 1:45 AM, Kazuhiro Funakoshi <k-f@bk.jp.nec.com> wrote:
> Arthur,
> Thank you for TRS pointer. I didn't know this. I will take a look.
> Sorry for my bad explanation. I did not intend to say about query mechanism but PROMCODE service provider behavior:
> Precondition:
> For a plan <p> collects WorkItem <w>,
> <p> a promcode:Plan;
>   promcode:collects <w>.
> <w> a promcode:WorkItem.
> Situations:
> (1) create sub-WorkItem <w'>, (<w'> promcode:isPartOf <w>);
> (2) create super-WorkItem <w'> (update <w>, <w> promcode:isPartOf <w'>);
> When we have an isolated WorkItem <w'>,
> (3) create sub-WorkItem of <w> and super-WorkItem of <w'> as <w''> (→:isPartOf, <w'> → <w''> → <w>);
> Question:
> Q1: Should <p> collects <w'> automatically at least when respond to a GET request on <p>?
> Q2: What about other resources ScopeItem, WorkItem and Artifact which are associated with <w> ?
> Q3: If yes, when should it be done: In POST time or GET time (lazy way) ?
> Q4: If yes, should it be done at service provider side or client side?
> Yesterday I had a chance to talk this with Mr. Wakao and Mr. Matsumoto. The conclusion there was, we should keep query capability as MAY and no complicated logic with ManagedItemCollection. It means that promcode:collects is always complete and maintained by stakeholders as their intention. Thus, the answers to Q1, Q2 above are "No".  I agree with this, because it keeps implementation simple.
> In our scenario Example 15, the plan <200> collects scope item <1010>, it means supplier needs neither work item <3010>(Example 11) nor artifact <2010>(Example 10).
> If supplier needs them, then acquire has to make a plan collects them.
> Note that Fig. 9 says excel adaptor issues GET at WorkItem, so Example 15 is going to be updated to collect <3010> at least.
> -----Original Message-----
> From: Arthur Ryman [mailto:arthur.ryman@gmail.com]
> Sent: Friday, July 10, 2015 12:19 PM
> To: Funakoshi Kazuhiro(船越 和大)
> Cc: oslc-promcode@lists.oasis-open.org
> Subject: Re: [oslc-promcode] provider/client design problem about collects from Plan or Report
> Kaz,
> We have a classic tradeoff here. On the one hand, people want complex queries. On the other hand, people want to simplify implementation. So if the PROMCODE server does not provide a SPARQL endpoint, then it could provide a Tracked Resource Set interface so that an external indexer, such as the Jazz Lifecycle Query Engine (available in the Jazz Reporting Services) can pull the data out of the PROMCODE server into an external SPARQL endpoint.
> My recommendation is that we don't invent another query mechanism.
> Either the PROMCODE server has a built-in SPARQL endpoint or it provides a Tracked Resource Set interface.
> -- Arthur
> On Mon, Jun 29, 2015 at 1:39 AM, Kazuhiro Funakoshi <k-f@bk.jp.nec.com> wrote:
>> Dear TC members,
>> As subclasses of ManagedItemCollection, we have four: Plan, Report,
>> IssueCollection and RiskCollection. To traverse in these collections, we have a design problem: what they should collect.
>> Especially in Plan and Report, they can collect any ManagedItems.
>> However, imagine when we want to obtain series of Artifacts from a plan, what we can do is:
>> 1. Directly find from Plan collects property.
>>   To do this, we have guarantee that the Plan collects all of Artifacts which relates to the Plan.
>> 2. Filter from ManagedItemContainer.
>>   2.1 By SPARQL
>>     We didn't make Query Capability as MUST, so we cannot expect this always work.
>>   2.2 Client side filter operation
>>     First we have to get all items, then filter with:
>>     (1)*{ (2) + (3) + (4) + (5) + ...}
>>     (1) is an Artifact
>>     (2) the Plan collects
>>     (3) a ScopeItem which has producedFor range of the Artifact and collects range of the Plan
>>     (4) a WorkItem which has producedFor range of the Artifact and collects range of the Plan
>>     (5) a WorkItem which has producedFor range of the Artifact and has requiredBy to a ScopeItem which the plan collects
>>     (...) we also have to consider isPartOf relation, it may have a deep hierarchy.
>> Query in 2.1 and 2.2 should have same logic, they don’t seem smart.
>> 1. helps but does not simplify the problem drastically. We still have
>> to think POST/PUT/PATCH operations for ManagedItems which can make disconnected items connected.
>> Remind we had inverse properties long time ago. During that time we
>> had a discussion that SPARQL query will solve problem so we deleted them. Actually, that design also have a problem shares the root: how to keep consistency (property・inverse ≡ id).
>> Before next meeting, I think we should at least make pros/cons clear.
>> If you find something wrong/oversight, feel free to reply to this mail as well as idea/comments.
>> Regards,
>> Kaz

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]