[oslc-core] Fw: Issue with the Use of dcterms:title and dcterms:description with oslc:ResponseInfo

[Dave]

On Wed, Dec 1, 2010 at 2:03 PM, Arthur Ryman <ryman at ca.ibm.com> wrote:
> If we require the client to explicitly request paging, and the response is
> too big for the server to return, then the server MUST return an error
> code, which would require the client to react somehow. I don't believe the
> Core spec says what error code to use to indicate the result is too big
> and that the client should request paging. So I think we'll have to
> tighten up the spec anyway. It seems that returning the first page is more
> useful than returning an error, and would allow for a more graceful
> degradation of function for existing clients who do not understand paging,
> although the risk there is that they think they are getting the full
> response.

Yes, we need to add something to the spec to explain how an OSLC
Service should react when a client requests something too large, but
does not indicate that it wants paging. We discussed this in the
work-group today and consensus was that a 302 redirect is the way to
handle this case. Here's my first attempt to capture this in spec
text:

8< begin spec text

When a client requests a resource that an OSLC Service considers to be
too large to return in one response and the client has not indicated
that it desires paging (via oslc.paging or oslc.pageSize), the OSLC
Service MAY return a representation that contains partial information
about the resource. If such a representation is returned, it MUST be
returned as follows:
1) the OSLC Service receives an HTTP GET request for a resource that
exceeds size limits and URL does not include 'oslc.paging=true' or an
'oslc.pageSize' key/value pair,
2) the OSLC Service returns an HTTP Status 302 redirect to the same
URL but with key/value pair to indicate paging.
   2.1) If the client did not indicate paging, the new redirect URL
*MUST* include the oslc.paging=true pair.
   2.2) If the client indicated a page size, then the redirect URL
*MUST* include the oslc.paging pair with a size value that is
acceptable to the service.
3) the client receives a representation that contains partial
information about the resource.

On receiving a resource representation, OSLC Clients *SHOULD* check
for the presence of an =oslc:ResponseInfo= value to determine if the
representation contains partial information about the resource. If the
value is present, then paging is in effect and the representation
contains partial information about the resource.

8< end spec text


> For oslc:totalCount, as you point out, there was text in the original
> query spec to define that since it was used in conjunction with the the
> size and offset parameters.

No comment ;-)


> For a non-query response, although counting triples is precise, I don't
> like that since it is a very different measure than in the query case, and
> it would be expensive to compute. In the query case, it is usually much
> cheaper to run a preliminary query to just count the results, as opposed
> to running the entire query and constructing the complete result set -
> which is what we'd need to do in order to count the triples.
>
> We could punt this to the server and allow it to mean some relative
> measure of size. This is like having a progress indicator. If we let this
> be relative, then we should also include an oslc:thisCount property to
> indicate how much of the total count is included in the current page.

A relative indicator seems imprecise and not all that useful and I
really don't like the idea of adding a new property this late in the
spec cycle or the idea of a relative measure of size.

Wouldn't it be better to specify what oslc:totalCount really means in
the two cases? Regarding the "expensive to compute" argument,
oslc:totalCount is not required, so a implementers that consider it
(as I have defined it) to be too expensive, can choose not to
implement it.

Thanks,
Dave