[oslc-core] TRS spec cutoffEvent property

[Joe Ross]

Our base set can contain many millions of records. We absolutely do not
want to implement stable paging for it. This was discussed when this draft
was being prepared, and I think there was general agreement that a client
could implement unstable paging. In any case, from an implementation
perspective it can certainly be made work. During that discussion, the
following paragraphs in the specification were referred to:

   Because of the highly dynamic nature of the Resource Set, a Server may
   have difficulty enumerating the exact set of resources at a point in
   time. Because of that, the Base can be only an approximation of the
   Resource Set. A Base might omit mention of a Resource that ought to have
   been included or include a Resource that ought to have been omitted. For
   each erroneously reported Resource in the Base, the Server MUST at some
   point include a corrective Change Event in the Change Log more recent
   that the base cutoff event. The corrective Change Event corrects the
   picture for that Resource, allowing the Client to compute the correct
   set of member Resources. A corrective Change Event might not appear in
   the Change Log that was retrieved when the Client dereferenced the
   Tracked Resource Set URI. The Client might only see a corrective Change
   Event when it processes the Change Log resource obtained by
   dereferencing the Tracked Resource Set URI on later occasions.

   The Server SHOULD NOT report unnecessary Change Events although it might
   happen, for example, if changes occur while the base is being computed.
   A Client SHOULD ignore a creation event for a Resource that is already a
   member of the Resource Set, and SHOULD ignore a deletion or modification
   event for a Resource that is not a member of the Resource Set.

If it is unclear that unstable paging can be supported, I think that it
needs to be made clearer.

Joe

================================================
Joe Ross/Austin/IBM, joeross at us.ibm.com
Tivoli Autonomic Computing & Component Technologies
512-286-8311, T/L 363-8311



From:	Jim des Rivieres <Jim_des_Rivieres at ca.ibm.com>
To:	Joe Ross/Austin/IBM at IBMUS,
Cc:	oslc-core at open-services.net
Date:	05/03/2013 07:14 AM
Subject:	Re: [oslc-core] TRS spec cutoffEvent property



> 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/8fbbad30/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20130503/8fbbad30/attachment.gif>