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@IBMCA To: Nick Crossley <[email protected]> Cc: Martin Nally <[email protected]>, [email protected] Date: 04/01/2011 01:52 PM Subject: [oslc-core] OSLC Unstable Paging Integrity Sent by: [email protected] 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@IBMUS To: Frank Budinsky/Toronto/IBM@IBMCA Cc: Martin Nally/Raleigh/IBM@IBMUS, [email protected] 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. [email protected] wrote: ----- To: [email protected] From: Frank Budinsky Sent by: [email protected] Date: 03/17/2011 08:57AM Cc: Martin Nally/Raleigh/IBM@IBMUS, RELM Development <relm_development%[email protected]> 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 [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net _______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net
