[oslc-core] Proposed change to JSON formatting rules for Query responses

Patrick Streule patrick_streule at ch.ibm.com
Tue Aug 3 12:38:36 EDT 2010


> 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 <sspeiche at us.ibm.com>
> >
> >   To:         oslc-core at open-services.net
> >
> >   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
> >
> >
> > _______________________________________________
>
>





More information about the Oslc-Core mailing list