[oslc-core] OSLC Unstable Paging Integrity

Fri Apr 1 13:51:18 EDT 2011

Nick asked a very good question below about the integrity of data in a
paged result:

   If a provider uses 'unstable paging' of large query results, as most
   probably will, what guarantees are there that a query will give you all
   resources at least once?  The description of unstable paging in the core
   spec just says that the resources might change as you read each page of
   the list, but does not mention the integrity or consistency or lack
   thereof for the result set itself.  If the 'next page' link might return
   a page with a resource skipped over (perhaps because some resources from
   a previous page have been deleted, and so a resource would now appear on
   an earlier page), then the result may be incomplete.

I think that this is a general issue with OSLC paging and therefore the
core spec is the place to address it. I think it should provide a general
guarantee that resources can't be skipped. An unstable paged result may
return a combination of older and newer states of the result, but it can't
skip resources that were in both.

Thoughts?

Thanks,
Frank

  From:       Nick Crossley/Irvine/IBM at IBMUS                                                                               

  To:         Frank Budinsky/Toronto/IBM at IBMCA                                                                             

  Cc:         Martin Nally/Raleigh/IBM at IBMUS, oslc-core at open-services.net                                                  

  Date:       03/22/2011 08:10 PM                                                                                          

  Subject:    Re: [oslc-core] Updated ChangeLog Proposal                                                                   

Other than comments already made by others on the names and name spaces,
etc., I have only one comment and one question.

Comment: in section 1.2.2, when mentioning that a change log might include
notification of a change even though the RDF representation appears
identical, another (and perhaps more likely) case of this is where the
resource changed to exactly the same state as it was originally - either
because it changed twice sufficiently quickly that the provider only put a
single entry in the change log, or because the updated property values are
the same as they were, and the provider does not compare original to
updated values o a PUT of a resource.

Question: if a provider uses 'unstable paging' of large query results, as
most probably will, what guarantees are there that a query will give you
all resources at least once?  The description of unstable paging in the
core spec just says that the resources might change as you read each page
of the list, but do not mention the integrity or consistency or lack
thereof for the result set itself.  If the 'next page' link might return a
page with a resource skipped over (perhaps because some resources from a
previous page have been deleted, and so a resource would now appear on an
earlier page), then the initial population of an index might be incomplete.
Should the core spec provide a general guarantee that paged results cannot
skip resources, or should this belong in the indexer profile (or whatever
we call it), or should an indexer use some other techniques to check for
missing resources?

Nick.

-----oslc-core-bounces at open-services.net wrote: -----
 To: oslc-core at open-services.net
 From: Frank Budinsky
 Sent by: oslc-core-bounces at open-services.net
 Date: 03/17/2011 08:57AM
 Cc: Martin Nally/Raleigh/IBM at IBMUS, RELM Development
 <RELM_Development%IBMCA at ca.ibm.com>
 Subject: [oslc-core] Updated ChangeLog Proposal

 Hi All,

 I've uploaded the latest version of the OSLC change log proposal here:

 http://open-services.net/pub/Main/IndexingProposals/OSLC_indexing_0316.doc

 It includes changes to reflect discussion and decisions made during the
 first round of review, including the following:
    1. A section to describe the motivating use case.
    2. Description of a formal "Indexing Profile" which defines the
       capabilities that a service provider MUST support in order to be
       indexable.
    3. Proposed formal scope of indexing/changeLog.
    4. ChangeLog entry timestamps changed to sequence numbers.
    5. ChangeLog entries can optionally be referenced URI-addressable
       resources.

 Please send comments and issues to the mailing list. We're also
 tentatively scheduled to discuss this during the OSLC Core Workgroup call,
 next week, so hopefully we can hash out most of the remaining issues by
 then.

 Thanks,
 Frank._______________________________________________
 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/20110401/a912319b/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/20110401/a912319b/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110401/a912319b/attachment-0001.gif>