[oslc-core] Pagination

[Martin Nally]

I don't see the arguments around the <changelog>#<changeEntry> design the
same way as you do, but I don't want to argue the point because I think
your other design is better, precisely because it's more straightforward
and so avoids this debate.

> I was assuming that we could still optionally support addressable
> "change entries" (as opposed to addressable "list entries"), as
> described in the current version of the proposal document:
>
> <https://.../ChangeLog>
>   oslc:changes (<https://.../changeEvent/103>
<https://.../changeEvent/102> <
> https://.../changeEvent/101>) .

I don't think this really works, because this form is pretty useless for an
indexer, who would then be forced to GET each individual entry. If this was
even potentially the form of the changeLog, we would have to invent a new
resource - flattenedChangeLog - that inlined the triples for the events. I
think we should just reject the requirement for individually-addressable
entries.

> <https://.../ChangeLog>
>    oslc-log:changes (
>      ...
>      ]) ;
>    oslc-log:continuation <https://.../ChangeLog_1> .
>
> This way, the http://.../ChangeLog can claim to be the ChangeLog

This is really mostly a small terminology point, but I feel strongly about
it. People already have a strong mental model for what a changeLog is, and
this resource is clearly not a changeLog, its only a segment of one. Let's
just call it what it is. In this design we are not defining a single
resource and URI for the changeLog itself, which is perfectly fine. We can
add one later if we have a use-case for it. I understand that the RDF
people chose not to distinguish between a list (as everyone understands it)
and a single node in a list. This was a bad decision that we don't have to
emulate. The RDF decision is not only bad for its conceptual dissonance,
it's bad in practice - for example you can't query in a straightforward way
for all the resources that are the first entry in a (conceptual) list,
since in the RDF design every resource that is at any position in a
conceptual list has to be the first entry in some RDF List.

Best regards, Martin

Martin Nally, IBM Fellow
CTO and VP, IBM Rational
tel: +1 (714)472-2690

Frank Budinsky/Toronto/IBM wrote on 03/23/2011 11:57:59 PM:

> [image removed]
>
> Re: [oslc-core] Pagination
>
> Frank Budinsky
>
> to:
>
> Martin Nally
>
> 03/23/2011 11:58 PM
>
> Cc:
>
> oslc-core, oslc-core-bounces
>
> > You now
> > reject this design because it doesn't support fetching an individual
> > entry
>
> I was actually rejecting it because it DOES support fetching an
> individual entry (i.e., a server will return 200 OK for GET
> <ChangeLog>#fragment). but it's possible/likely that the requested
> resource isn't in the result. So the client is lead to believe the
> request was successful, but the result is missing. For this reason,
> I think using OSLC paging (in general) to paginate resources that
> contain fragment IDs is a bug. Do you agree, or do you think it
> would be acceptable to just document that GET <ChangeLog>#fragment
> is not supported and should not be called (because the result is
unreliable)?
>
> > but then you propose instead a different design that doesn't
> > support that feature either.
>
> I was assuming that we could still optionally support addressable
> "change entries" (as opposed to addressable "list entries"), as
> described in the current version of the proposal document:
>
> <https://.../ChangeLog>
>   oslc:changes (<https://.../changeEvent/103>
<https://.../changeEvent/102> <
> https://.../changeEvent/101>) .
>
> I don't think there's any harm in allowing this, but to be perfectly
> honest, I haven't yet seen a use case for it. The only justification
> I've seen is that it's best to say that client's need to be able to
> support this, even if it's not used by any servers right away, so
> that they have the option to do it in the future without breaking
clients.
>
> > Your new
> > design disappoints is a different way - the resource that said it
> > was the changelog actually isn't - it's only the first "segment" of
> > the changeLog. That can be easily fixed by avoiding claiming it's a
> > full changelog in the first place, perhaps like this:
> >
> > <https://.../ChangeLog?oslc:firstSegement>
> >   oslc-log:changes (
> >     ...
> >     ]) ;
> >   oslc-log:continuation <https://.../ChangeLog?pageno=2> .
>
> I wonder if it would be even better to not use query strings at all,
> but instead just give each segment a unique URI.
>
> <https://.../ChangeLog>
>    oslc-log:changes (
>      ...
>      ]) ;
>    oslc-log:continuation <https://.../ChangeLog_1> .
>
> This way, the http://.../ChangeLog can claim to be the ChangeLog,
> just like the first entry of a list can claim to be the list. The
> ChangeLog is essentially the first entry of a linked list of
> ChangeLog segments, each containing a page worth of entries.
>
> Frank.