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 <[email protected]> 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. >
