[oslc-core] Pagination

[Frank Budinsky]

Hi Martin,

> so I think the options are to use #2 or stick with Frank's original
> design, which was simple and understandable although it was new.

I think we need to rule out option #2 because OSLC paging won't work with
fragments. The problem is when the server initiates paging (with a 301
redirect), because the ChangeLog is too big, GET <changeLog>#fragment may
only return the first 100, say, and that may not even include the resource
being requested. The GET result will actually return something, but not
what was requested. That seems totally broken to me. If, and until, there
is a way for fragments to be passed to the server, so that it can decide
(base on the fragment) which page to return, I think OSLC paging can't be
used (not just for ChangeLog, but for fragment resources in general).

So I think that leaves the original design, but now that we understand OSLC
paging better, that's not totally satisfying either. The original design
used OSLC paging not to return the original resource in parts, but rather
to return pages, containing "page resource" with partial collections of
their own. I'm thinking that this is also a misuse of OSLC paging, and that
the bottom line is that OSLC paging is not really the right mechanism for
the ChangeLog.

Perhaps we should instead simply define our own simple paging mechanism for
ChangeLog. How about something like this:

<https://.../ChangeLog>
  oslc-log:changes (
    [ a oslc-log:Creation ;
      oslc-log:changed <https://.../com.ibm.team.workitem.WorkItem/23> ;
      oslc-log:at "103"^^xsd:int
    ]
    [ a oslc-log:Update ;
      oslc-log:changed <https://.../com.ibm.team.workitem.WorkItem/22> ;
      oslc-log:at "102"^^xsd:int
    ]
    [ a oslc-log:Deletion ;
      oslc-log:changed <https://.../com.ibm.team.workitem.WorkItem/21> ;
      oslc-log:at "101"^^xsd:int
    ]) ;
  oslc-log:continuation <https://.../ChangeLog?pageno=2> .

Notice that this does not require a redirect - the ChangeLog itself has an
optional continuation property. When we truncate the log, we would remove
the oslc-log:continuation property from the new last page (This is a good
example of a non-closed list. That is, there are more ChangeLog pages, we
just don't have it).

Thoughts?

Thanks,
Frank.

Martin Nally/Raleigh/IBM wrote on 03/22/2011 03:44:11 PM:

> [image removed]
>
> Re: [oslc-core] Pagination
>
> Martin Nally
>
> to:
>
> Frank Budinsky
>
> 03/22/2011 03:45 PM
>
> Cc:
>
> oslc-core, oslc-core-bounces
>
> Good point, Frank. I think there are 3 cases:
>
> Obviously, if the list nodes are blank nodes, then they are not
> independent resources - they are just part of the state of the
> changelog. This is simple, but the chagelog is now large and it
> can't be paginated.
> If the list nodes are resources, but they have URLs of the form
> <changeLogURL>#<list node fragment id>, then the list nodes are now
> real resources with URLs, but there is a standard relationship
> between the changelog and the list nodes based on the W3C definition
> of fragment identifiers. Fragment identifiers have always been a bit
> problematic, but the meaning of the relationship is something like
> "the representation of the list nodes will be inside the
> representation of the change log", which is a rather odd sort of
> relationship, but an important one. Now the changeLog is still large
> (since its representation includes the representation of all the
> list nodes, by definition), but it can be paginated using the
> standard OSLC pagination mechanism.
> If the list nodes are resources, but they have URLs of the form
> <changeLogURL>/<list node id>, then the list nodes are now real
> resources with URLs, and there is absolutely zero relationship
> implied by standard web theory between the changelog and the list
> nodes, or between the list nodes themselves. The relationship
> between them is the same as the relationship between martin,
> martingale and martini - they share the same first 6 letters of the
> name that is all. In this design you would expect the changelog
> resource to be small - the representation of the changeLog should
> reflect the state of changeLog (by theory of the WWW), and by
> adopting this pattern, we have specifically chosen to exclude the
> listNodes from the state of the changeLog itself. In this design, we
> can still invent new resources that include information on [the
> state of] multiple list nodes but these resources are not the
> changelog, and are not the list nodes, and are not the standard
> "pages" defined by the OSLC pagination specification either - they
> are something entirely  new and different.
>
> When I brought this up, I was advocating design 2 because it
> exploits what we already have, but given how complex the ensuing
> discussion has become, I'm getting discouraged. Maybe the discussion
> has had value in clarifying some of the ideas in OSLC paging. Design
> #1 can't be paginated, and #3 is something brand new (and subtle),
> so I think the options are to use #2 or stick with Frank's original
> design, which was simple and understandable although it was new.
>
> Best regards, Martin
>
> Martin Nally, IBM Fellow
> CTO and VP, IBM Rational
> tel: +1 (714)472-2690

>
> Frank Budinsky <frankb at ca.ibm.com> wrote on 03/22/2011 02:27:15 PM:
>
> > [image removed]
> >
> > Re: [oslc-core] Pagination
> >
> > Frank Budinsky
> >
> > to:
> >
> > Martin Nally
> >
> > 03/22/2011 02:27 PM
> >
> > Cc:
> >
> > oslc-core, oslc-core-bounces
> >
> >
> > > Pagination solves the problem that a resource
> > > is large and I don't want to get it all in one response.
> >
> > What makes pagination of the (latest proposed) ChangeLog different,
> > is that the "resource is NOT large", it's actually quite small,
> > although it includes a reference to another resource, which happens
> > to be the start of linked list of resources, which collectively
> > represent the ChangeLog. The ChangeLog data graph, not the resource,
> > is what's large.
> >
> > Normally, and consistent with Martin's definition, paging has been
> > used to break up the contents of a single resource, and in fact,
> > it's most useful when that content is a large number of values of a
> > single multi-valued property, like rdfs:members in the queryBase case.
> >
> > Once the thing being paged spans multiple resources, it almost
> > doesn't seem to fit the same model. Now, instead of "resource
> > paging", we're talking about "data graph paging", and in our case,
> > more specifically, "linked-list data graph paging". Maybe, as Dave
> > suggested, the OSLC core spec needs to describe the places where
> > paging can/should be expected?
> >
> > Frank.
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110323/88fd6723/attachment-0003.html>