Why does CLM RM 6.0.2 not respond to OSLC Query application/json with well-formed JSON?
Using OSLC4J libraries 2.1.0 and making OSLC Core 2.0 queries to a CLM 6.0.2 DNG repository, I can properly query of application/rdf+xml Requirement.class instances. I get back proper-looking ResponseInfo collections.
However, when I attempt to set the Accept Header to application/json, I get back partial JSON objects. These contain the Requirement information but they leave out the crucial "prefixes: []" property. These means that the result can be getEntity( String.class ) received but any attempt to use a JSON Provider to marshall the JSON objects into proper OSLC Resource classes fails. It fails with a deep exception of:
org.eclipse.lyo.oslc4j.core.exception.OslcCoreMissingNamespaceDeclarationException: OSLC009: Namespace declaration not defined for namespace http://www.w3.org/1999/02/22-rdf-syntax-ns#
The debugger can trap for this and I can confirm that the JSON object has no "prefixes" property.
Postman GET for the query, after Form Authentication, also shows that the Query Result JSON string lacks the prefixes property. Therefore, apparently, something on the Jazz server is improperly serializing the Query Results to JSON.
Screenshot available at https://www.dropbox.com/s/1u3nsrrhl4dfblv/Screenshot%202016-10-27%2016.07.32.png?dl=0
Any clues as to what might be causing this and how to correct it?
{
"https://foo.atsodius.com:9443/rm/views?oslc.query=true&projectURL=https%3A%2F%2Ffoo.atsodius.com%3A9443%2Frm%2Fprocess%2Fproject-areas%2F_VL8C0HVwEeabvtjS7voR-g&vvc.configuration=https%3A%2F%2Ffoo.atsodius.com%3A9443%2Frm%2Fcm%2Fstream%2F_VcPvsHVwEeabvtjS7voR-g&oslc.paging=true&oslc.pageSize=100&oslc.where=dcterms%3Amodified%3E%222012-08-01T21%3A51%3A40.979Z%22%5E%5Exsd%3AdateTime&oslc.select=dcterms%3Aidentifier%2Cdcterms%3Acontributor%2Cdcterms%3Amodified&oslc.orderBy=%2Bdcterms%3Amodified&oslc.prefix=dcterms%3D%3Chttp%3A%2F%2Fpurl.org%2Fdc%2Fterms%2F%3E%2Crdfs%3D%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%3E%2Coslc_rm%3D%3Chttp%3A%2F%2Fopen-services.net%2Fns%2Frm%23%3E%2Cjazz_rm%3D%3Chttp%3A%2F%2Fjazz.net%2Fns%2Frm%23%3E" : {
"http://purl.org/dc/terms/title" : [ { "type" : "literal" , "value" : "Query Results: 2" } ],
"http://www.w3.org/1999/02/22-rdf-syntax-ns#type" : [ { "type" : "uri" , "value" : "http://open-services.net/ns/core#ResponseInfo" } ]
},
"https://foo.atsodius.com:9443/rm/resources/_3BSgYXyGEeaRoaBJ0pvnhg" : {
"http://purl.org/dc/terms/contributor" : [ { "type" : "uri" , "value" : "https://foo.atsodius.com:9443/jts/users/patricia" } ],
"http://purl.org/dc/terms/identifier" : [ { "type" : "literal" , "value" : "3", "datatype" : "http://www.w3.org/2001/XMLSchema#integer" } ],
"http://www.w3.org/1999/02/22-rdf-syntax-ns#type" : [ { "type" : "uri" , "value" : "http://open-services.net/ns/rm#Requirement" } ],
"http://purl.org/dc/terms/modified" : [ { "type" : "literal" , "value" : "2016-09-19T18:53:40.776Z", "datatype" : "http://www.w3.org/2001/XMLSchema#dateTime" } ]
},
"https://foo.atsodius.com:9443/rm/views?oslc.query=true&projectURL=https%3A%2F%2Ffoo.atsodius.com%3A9443%2Frm%2Fprocess%2Fproject-areas%2F_VL8C0HVwEeabvtjS7voR-g" : {
"http://www.w3.org/2000/01/rdf-schema#member" : [
{ "type" : "uri" , "value" : "https://foo.atsodius.com:9443/rm/resources/_3BSgYXyGEeaRoaBJ0pvnhg" },
{ "type" : "uri" , "value" : "https://foo.atsodius.com:9443/rm/resources/_6-7pQX4IEeaRoaBJ0pvnhg" }
]
},
"https://foo.atsodius.com:9443/rm/resources/_6-7pQX4IEeaRoaBJ0pvnhg" : {
"http://purl.org/dc/terms/contributor" : [ { "type" : "uri" , "value" : "https://foo.atsodius.com:9443/jts/users/patricia" } ],
"http://purl.org/dc/terms/identifier" : [ { "type" : "literal" , "value" : "4", "datatype" : "http://www.w3.org/2001/XMLSchema#integer" } ],
"http://www.w3.org/1999/02/22-rdf-syntax-ns#type" : [ { "type" : "uri" , "value" : "http://open-services.net/ns/rm#Requirement" } ],
"http://purl.org/dc/terms/modified" : [ { "type" : "literal" , "value" : "2016-09-19T18:50:41.393Z", "datatype" : "http://www.w3.org/2001/XMLSchema#dateTime" } ]
}
}
One answer
The JSON response is well constructed. I believe it's Lyo's fault for not properly handling the JSON format - it seems to request a "prefix" for whatever the reason, and complains about a namespace not being a "namespace".
As far as I know, there is no "namespace prefix" in JSON. If you Google "JSON namespace", you will find lots of discussions about this. For example this one:
http://www.goland.org/jsonnamespace/
As far as I know, there is no "namespace prefix" in JSON. If you Google "JSON namespace", you will find lots of discussions about this. For example this one:
http://www.goland.org/jsonnamespace/
Comments
Donald,
There is no "prefixes" property in JSON's schema but there is an expectation in OSLC4J that a provider of OSLC resources will return a JSON object that includes a "prefixes" array. This can be obtained for some OSLC requests and just not for the OSLC query responses. After a while of debugging through Jazz and OSLC requests and responses and comparing with the handling of application/rdf+xml, it clearly smells like an Oops oversight in the serialization of JSON responses by DNG.
Perhaps there is a missing OslcSchema OslcNamespaceDefinition annotation for the package that holds the OSLC Query response resource and so the related JSON serializer has no reflection advice on what prefixes it should normally generate?
I don't know what specification the RM implementation should use for its JSON response. What I try to clarify is that the JSON response is indeed well-formed. Take the "title" property as an example - in the JSON response, it's "http://purl.org/dc/terms/title", and it would be "dcterms:title" had there been a prefix 'dcterms="http://purl.org/dc/terms/"', and they are essentially the same thing.
I agree that out of the three CLM applications (CCM/QM/RM), RM quite often seems "odd" in its implementation, but it does not make it "wrong".
BTW, the RDF/XML response is more consistent and available for all requests, why not stick with RDF/XML?
I agree that the internal code base for RDF/XML seems to be more reliable. The point of the question was to inquire why the JSON implementation isn't as robust.
Why bother?
Sometimes it is easier to work with JSON data rather than XML/RDF, especially when interacting with some node-like, javascript-centric client that really wants JSON objects.