It's all about the answers!

Ask a question

resource values in oslc workitem query xml results


Clay Rowland (611) | asked Jan 12 '11, 9:42 a.m.
Is there a way to retrieve the actual value of work item attributes instead of their respective resource URIs? For example, if i want to retrieve the state of a defect, i have to retrieve the title of the state returned by

https://server/jazz/oslc/workflows/_B7pWkIqqEd-6naFoU-ISXw/states/com.ibm.team.workitem.defectWorkflow/4

this is very cumbersome when processing large numbers of work items and attributes. Is there a parameter that can be passed to a query that will allow for the title of the attribute to be returned rather than the rdf:resource attribute?

4 answers



permanent link
Brent Barkman (156) | answered Jan 13 '11, 10:31 a.m.
JAZZ DEVELOPER
AFAIK thats by design and it actually makes a lot of sense if you think about... REST -> everything is a resource. Anyway you can start caching things like state because they rarely change and that'll save you the extra call each time.

permanent link
Patrick Streule (4.9k21) | answered Jan 18 '11, 6:08 a.m.
JAZZ DEVELOPER
On 1/12/11 3:53 PM, crowland wrote:
Is there a way to retrieve the actual value of work item attributes
instead of their respective resource URIs? For example, if i want to
retrieve the state of a defect, i have to retrieve the title of the
state returned by

https://server/jazz/oslc/workflows/_B7pWkIqqEd-6naFoU-ISXw/states/com.ibm.team.workitem.defectWorkflow/4

this is very cumbersome when processing large numbers of work items
and attributes. Is there a parameter that can be passed to a query
that will allow for the title of the attribute to be returned rather
than the rdf:resource attribute?

There is a way (both in the 1.0 and the 2.0 spec). Please see:

http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;up=#Selective_Property_Values

--
Regards,
Patrick
RTC Work Item Component Lead

permanent link
Clay Rowland (611) | answered Jan 18 '11, 2:35 p.m.
Patrick, thanks for the tip. that is exactly what i was looking for.

permanent link
Paul Romanus (3355) | answered May 26 '12, 2:32 a.m.
Hi

When querying for a set of Workitems using the nested properties syntax in the oslc.select 'clause' as directed above - only the first discrete value of the value is returned e.g. submitting a query with 'oslc.select' defined as below:


... ?oslc.properties=dcterms:title,dcterms:creator{foaf:name}&oslc.where=...


Gives the resultset below:

e.g. each of the 3 Workitems below has the same creator - but only the first discrete instance is resolved to the selected nested property e.g. foaf:name - me - in this case.

If there are multiple different creators then again only the first instance of the nested property (foaf:name} is returned in the resultset.

grr .. ok .. so I can see that this could be justified ... just .. in the basis of some kind of performance grounds whereby only the first instance of a nested property is resolved and should be subsequently cached and resolved by the parsing program .. but I had expected that each result(work item) in the resultset would have all it's selected attributes fully resolved - e.g. like any other tool / db (at least that I've used) does.

So...
1/ Can I force all results ( workitems ) to fully resolve their selected nested properties?

2/ If not, and as all I want to do in this case is transform the oslc output to a simpler xml/json format to be consumed by a dojo Datagrid - could someone suggest a xslt I can apply (example) whereby I can prehaps cache the resolved properties and resolve subsequently non-resolved fields in one stylesheet ?

<xml>
<rdf>
<rdf>
<rdfs>
<oslc_cm>
<dcterms>Test Summary One</dcterms>
<dcterms>
<foaf>
<foaf>Paul Romanus</foaf>
</foaf>
</dcterms>
</oslc_cm>
</rdfs>
<rdfs>
<oslc_cm>
<dcterms>Test</dcterms>
<dcterms>
</oslc_cm>
</rdfs>
<rdfs>
<oslc_cm>
<dcterms>Some problems ...</dcterms>
<dcterms>
</oslc_cm>
</rdfs>
</rdf>
<oslc>
<dcterms>Work Items</dcterms>
<oslc>3</oslc>
</oslc>
</rdf>

Your answer


Register or to post your answer.