[oslc-core] Fw: Issue with the Use of dcterms:title and dcterms:description with oslc:ResponseInfo
Arthur Ryman
ryman at ca.ibm.com
Wed Dec 1 14:03:03 EST 2010
Dave,
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.
The proposal to use the content-location header to point to the first page
URL seems like a better alternative than using an error response. However,
we should check with implementers to see if this would break clients.
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.
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.
Regards,
___________________________________________________________________________
Arthur Ryman, PhD, DE
Chief Architect, Project and Portfolio Management
IBM Software, Rational
Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063
From:
Dave <snoopdave at gmail.com>
To:
oslc-core at open-services.net
Cc:
Martin Nally <nally at us.ibm.com>, Arthur Ryman/Toronto/IBM at IBMCA
Date:
12/01/2010 09:51 AM
Subject:
Re: [oslc-core] Fw: Issue with the Use of dcterms:title and
dcterms:description with oslc:ResponseInfo
Thanks for pointing out the error of our ways. I think that we all
forgot paging is optional and must be requested by the client. More
comments below.
On Fri, Nov 26, 2010 at 8:22 PM, Martin Nally <nally at us.ibm.com> wrote:
> Regardless of the answer to the question on 302/303 redirects, I like
your
> suggestion that the server should be allowed to return the first page in
> response to a GET on the whole list (contrary to what I originally
wrote).
> If we allow this, I would like us to mandate that the server provide a
> content-location header in the response that indicates that the resource
> that was returned is in fact
http://example.org/bugs?oslc:pagination=true,
> not http://example.org/bugs. This gives the client two ways to recognize
> what just happened - it can notice that the resource returned is
different
> from the one requested, or it can look for a nextPage property in the
> representation. More generally, it provides the client with a specific
> indicator of the "implicit redirect" that happened on the server without
> having to guess based on the representation. When we get our
verification
> test suite going, it should check for this.
We required clients to ask for paging via oslc.paging=true because we
had lots of feedback from implementation teams telling us that clients
could not handle paging. We removed it and other features (e.g. in
query syntax) because we were under pressure to simplify the spec.
Even if things have changed and client implementations (we know about)
can all now handle paging, it's pretty late in the spec process to be
making such a fundamental change.
Do we have a handle on the impact to existing implementations and can
we tolerate it?
> Several people have noted that the term "ResponseInfo" does not fit the
> conceptual model currently documented in the spec. I think this term is
may
> be a relic a different conceptual model that was previously proposed and
> discarded. Any chance we can change the name to match the model? Page
would
> be the obvious choice of term.
Page is a better term, I agree, but we are very late in the game now
so I have the same question as above.
> RDF representations lend themselves very nicely to pagination, because
an
> RDF graph has no structure - it's just a set of triples, so is easy to
> break into subsets. Some other representations, like HTML, are much
harder
> to paginate, and in fact I find it hard to imagine a satisfactory way to
> paginate HTML (maybe 2 pages - one with the head and one with the body).
> JSON might also be tricky to paginate. Is pagination only expected to
work
> with RDF? If so, the spec should say so - I didn't find anything when I
> looked. If pagination is expected to work with other formats like JSON,
I
> think the spec needs explain how to paginate them.
The spec does explain how to paginate JSON using oslc:ResponseInfo and
oslc:nextPage.
http://tinyurl.com/3yxuxvz - or -
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixRepresentations#Guidelines_for_JSON
> It's not clear what totalCount refers to. Is it simply the number of
> triples? The spec says "the number of results", which is a bit vague. I
> think we should clarify.
Yes, this should definitely be clarified. I'll get it on the work-group
agenda.
Thanks,
Dave
More information about the Oslc-Core
mailing list