It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,883
×12,009

question asked: Sep 30 '15, 9:32 a.m.
question was seen: 2,792 times
last updated: Oct 01 '15, 2:21 p.m.

Related questions

Issues with constructing an oslc.where URL and valid XML results

1
James Waslo (23●1●5) | asked Sep 30 '15, 9:32 a.m.
Hello,
I'm currently working on a set of C# services and applications that require a certain degree of integration with our Rational Team Concert implementation.  Specifically, I've been asked to present a list of Change Requests to which the currently logged in user subscribes so that they may add the URLs for these Change Requests with certain items in another application.  I am attempting to obtain this list via a query in the style of https://<rtchost>:9443/ccm/oslc/contexts/_Tf1GwI4UEeGDLvoSNiZKIA/workitems?oslc.where=dc:identifier="5535" or something similar.  However, no matter how I build the URL, I get a list in XML of ALL Change Requests in the system.  In addition, the XML in the result set contains no information about the namespaces, which makes parsing the results more difficult.  The XML just starts with a <oslc_cm:Collection> tag and proceeds from there. 

I'm sure the list is long, but what am I doing wrong here?
Comments
Donald Nong commented Oct 01 '15, 2:31 a.m.

Which version of RTC are you using? In my test, if the OSLC property is incorrectly defined, RTC will complain about it. I have never seen that RTC will ignore the oslc.where filter (well except for the partial representation).

James Waslo commented Oct 01 '15, 9:16 a.m.

Donald,
The server under target is running RTC 5.0.2, from what I understand.  I'm not actually part of the RTC Development Team, just trying to consume some of its data.  I'm equally puzzled by this behavior myself, but remain convinced I'm doing something wrong rather than RTC.

Thanks!

Accepted answer

1
permanent link
Jim Ruehlin (791●1●4) | answered Sep 30 '15, 2:48 p.m.
JAZZ DEVELOPER
 Hi James,

It looks like you need to say dcterms:identifier="5535". RTC is probably returning all change requests because it doesn't recognize what a dc:identifier is. See http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA.

For the XML result set, I think the oslc:usage information is returned as part of the QueryCapability resource, not the query itself. If you check the XML returned when you ask for http://open-services.net/ns/core#QueryCapability you might see it there.

- Jim
James Waslo selected this answer as the correct answer
Comments
James Waslo commented Sep 30 '15, 3:15 p.m.

Hi Jim,
Sadly, the alteration of the where clause continues to produce the same results.  The issue isn't even related to dc:identifier or any specific prefix, but all prefixes or attempts at filtering.  I've attempted virtually filtering on virtually all prefixes I can identify in the XML by visual inspection, with nary a variation in result.

The returned XML still contains no namespace specifications in the results, but I've found my way around that with some post processing on my own.  My biggest issue is the attempt, via an oslc.where clause, to return, in XML, a list of all Change Requests to which a given user subscribes.  While that is clearly more complicated than what I provided in my example, it was meant to demonstrate the issues I'm experiencing while attempting to use that oslc.where clause for even simple filtering. 

Thanks!

2 other answers

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Jim Ruehlin (791●1●4) | answered Sep 30 '15, 5:56 p.m.
JAZZ DEVELOPER
 Hard to say without seeing the code, but I still suspect there's a problem with your parameters. The "dc:" or "dcterms:" is just a shortcut for "http://purl.org/dc/terms/". If you're not sure if you're actually getting the purl.org URI then you might want to check by typing the query manually.

If you've verified that, then you should check the OSLC CM Resource Definitions and the OSLC Core appendix A definitions. They have the official OSLC definitions (attributes) used in queries. Note that dcterms:identifier is defined in Core and CM as an internal ID not intended for display. So this might not be the simple numeric ID you're used to seeing in RTC (I'm not sure what they use for this). You might want to try oslc:shortId or oslc:shortTitle.
Comments
James Waslo commented Oct 01 '15, 8:49 a.m.

Jim,
The issue isn't just restricted to the dc prefix, which is defined in the oslc_cm:Collection root node for the result set.  Literally any attempted use of the oslc.where clause in the URL returns the same set of results, regardless of parameter or identifier. 

Thanks!

0
permanent link
Fernando Silva (81●2●4) | answered Oct 01 '15, 11:41 a.m.
edited Oct 01 '15, 11:41 a.m.
 Seeing the response body (oslc_cm:Collection), I suspect that you are using
Accept  Header equals to application/xml. With this value of the Accept Header and without OSLC-Core-Version: 2.0, the oslc.where did not worked for me. You must change Accept Header to  application/rdf+xml or include OSLC-Core-Version: 2.0. And you have to use the identifier as dcterms:identifier or use the oslc.prefix parameter (only dc is not recognized). Ex.: ?oslc.where=dcterms:identifier=2
Comments
Fernando Silva commented Oct 01 '15, 11:48 a.m.

I think that oslc_cm:Collection is from OSLC 1.0 and in that version you need to use oslc_cm.query=dc:identifier=... to filter results. See http://open-services.net/bin/view/Main/CmQuerySyntaxV1#Query_Syntax

James Waslo commented Oct 01 '15, 2:13 p.m.

Fernando,
Changing the Accept header did produce something different.  Unfortunately, it's an Error 406 from the server.  However, I still consider this a step in the right direction, as it tells me something is coming back that I just can't seem to process correctly.  I'm still investigation the URL change you suggested. 

Thanks!

Fernando Silva commented Oct 01 '15, 2:21 p.m.

 Normally, I only got the 406 error when I forget to include the accept header. Could you share the code that create the url and execute the GET request?

Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.