> I would expect with our approach to resource formats now, we could simply
> represent the query response as: > > ... > > Thus eliminating the intermediate query resource and property, just > include the resources in the response. That would be even simpler, but I think it interferes with the Resource Pagination part of the core spec. Having a 'QueryResult' resource with 'result' properties makes query results just a specific case of Resource Pagination (the properties -- all the same in this case -- are continued on additional pages). There would be a corner case (a bit constructed, admittedly): If the page size is 1, a client couldn't tell if the representation means that the properties of the single resource are continued on additional pages, or if there are additional resources on these pages: <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"; xmlns:dcterms="http://purl.org/dc/terms/"; xmlns:oslc="http://open-services.net/ns/core#"; xmlns:oslc_blog="http://open-services.net/ns/bogus/blogs#";> <oslc:ResponseInfo rdf:about="http://example.com/query?oslc.from [...] entry/1>"> <dcterms:title>Blog Service Query Results for term [remote]</dcterms:title> <oslc:nextPage rdf:resource="..."/> </oslc:ResponseInfo> <oslc_blog:Comment rdf:about="http://example.com/blogs/comment/5";> <!-- Comment propery values, etc. --> <dcterms:title>Comment #5</dcterms:title> </oslc_blog:Comment> </rdf:RDF> This representation could mean 1) There are more properties of oslc_blog:Comment on the next page 2) There are more oslc_blog:Comment resources on the next page Regards, Patrick > > > > Some concerns that I have: > > > > 1) Wouldn't these resources/properties also have to be spec'd by the > > domains? I.e. the CM spec would have to define e.g. a > > 'oslc_cm:ChangeRequestQueryResult' resource. Currently, I don't see > > anything about query results e.g. in the CM, QM and RM specs. > > I have an outstanding action to add definition of this for "oslc:results" > for JSON query results. > I made an assumption about the RDF/XML and XML form (as illustrated above) > that I need to get clarification on, where I thought we didn't need to > define query resources for the response. > > > 2) Does a domain specific query result resource provide added value over > a > > generic 'oslc:QueryResult' resource with 'oslc:results' properties? I > see > > that we get "Type Safety" by the domain specific resources/properties, > but > > the convenience of a common format for query results seems to outweigh > > that, IMO. > > > > Thanks, > > Patrick > > > > > > > > > > From: Steve K Speicher <[email protected]> > > > > To: [email protected] > > > > Date: 07/27/2010 10:57 PM > > > > Subject: [oslc-core] Proposed change to JSON formatting rules > > for Query responses > > > > > > > > > > > > > > Current JSON guidance [1] doesn't address what the result array name > > should be. > > > > I recommend that we use "oslc:results" array, like for delegated UIs [2] > > > > See also example at [3], how does a consumer know to look for array > named > > "oslc_blog:comment" in this example. I think it would be best to use a > > general OSLC property. > > So this example would become: > > "oslc:results" : [{ > > "oslc:qname" : "oslc_blog:BlogComment", > > "rdf:resource" : "http://example.com/blogs/comment/346";, > > }, > > > > [1] > > http://open-services.net/bin/view/Main/ > > OSLCCoreRepresentationsGuidance#Guidelines_for_JSON > > > > [2] > > http://open-services.net/bin/view/Main/ > > OslcCoreSpecification#Delegated_User_Interface_Dialogs > > > > [3] > > > http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixD#Query_Resource > > > > > Thanks, > > Steve Speicher | IBM Rational Software | (919) 254-0645 > > > > > > _______________________________________________ > >
