[oslc-core] OSLC Unstable Paging Integrity

Fri Apr 1 16:47:24 EDT 2011

Paging stability is something that is absolutely essential for both the 
enumeration of the resource base and for the change log proper.  It's one 
of the reasons that I believe we will end up with a simpler and most 
generally useful spec by lessening the reliance on other elements of OSLC 
Core spec and specifying something more standalone.  That way, we would 
not need to adjust the OSLC query result and OSLC paging specs.

I have some ideas on how a spec could be written to achieved the desired 
outcome without overconstraining the parties involved. But I'll save that 
for another time.

---jim

From:
Frank Budinsky/Toronto/IBM at IBMCA
To:
Nick Crossley <ncrossley at us.ibm.com>
Cc:
Martin Nally <nally at us.ibm.com>, oslc-core at open-services.net
Date:
04/01/2011 01:52 PM
Subject:
[oslc-core] OSLC Unstable Paging Integrity
Sent by:
oslc-core-bounces at open-services.net

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

Nick Crossley---03/22/2011 08:10:52 PM---Other than comments already made 
by others on the names and name spaces, etc., I have only one comme

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
_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net