[oslc-core] TRS spec cutoffEvent property

[Jim des Rivieres]

> Since the base set can be paged, and for very large collections, the 
paging can be unstable, it would be useful to include the cutoffEvent 
property in every page with a possibly changing value.

Joe,  As the spec intro puts it "the Base provides a point-in-time 
enumeration of the members of the Resource Set".  It's important that the 
base is captured at a particular point-in-time, because that means 
resources cannot be added or removed for this base, regardless of what is 
happening to the resources in the set. The paging would be stable. The 
cutoffEvent property applies to this particular base as a whole, and there 
is no need to have the the cutoffEvent property in every page.

This point-in-time semantics is also spelled out in the Base Resources 
section: 

"The Base of a Tracked Resource Set is a W3C Linked Data Platform (LDP) 
Container where each member references a Resource that was in the Resource 
Set at the time the Base was computed." 

Regards,
Jim



From:
Joe Ross <joeross at us.ibm.com>
To:
oslc-core at open-services.net, 
Date:
05/02/2013 01:31 PM
Subject:
[oslc-core] TRS spec cutoffEvent property
Sent by:
"Oslc-Core" <oslc-core-bounces at open-services.net>



This question is related to the Tracked Resource Set 2.0 specification: 
http://open-services.net/wiki/core/TrackedResourceSet-2.0/

Since the base set can be paged, and for very large collections, the 
paging can be unstable, it would be useful to include the cutoffEvent 
property in every page with a possibly changing value. The specification 
indicates that the first page MUST include a cutoffEvent property, but 
doesn't seem to prohibit also including the cutoffEvent property also in 
subsequent pages. This is particularly useful if pages in base are shown 
in order of increasing modification time, which is the case in our 
implementation. Of course in that case, a resource can appear more than 
once in the base set if it is modified while someone is paging. Are there 
any issues with this implementation from a spec perspective?

================================================
Joe Ross/Austin/IBM, joeross at us.ibm.com
Tivoli Autonomic Computing & Component Technologies
512-286-8311, T/L 363-8311_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20130503/830cf778/attachment-0003.html>