Hi Frank, Fair enough. I just thought I'd raise the issue, in case it hadn't been considered.
Thanks, Dave -- Dave Steinberg IBM Rational Software [email protected] From: Frank Budinsky/Toronto/IBM@IBMCA To: [email protected] Date: 03/30/2011 02:44 PM Subject: Re: [oslc-core] ChangeLog Proposal Finalization Sent by: [email protected] Hi Dave, I think what you say makes sense if you want to retrieve a whole list and then work with it, but for ChangeLog, we want to be lazy, i.e., read the first page, and only if necessary, load the second and read it, etc. At each page, we also don't care about the last page's entries (which we've already processed), so we can discard them. We will likely never load the whole list, because we will either get to an entry that we have previously processed and stop or we'll get to a next page (or next entry, on a new page) that is missing because the change log has been truncated. Given this use case, I still think the explicit two-list model is best. Thanks, Frank. Inactive hide details for Dave Steinberg---03/30/2011 02:25:17 PM---Hi Frank, I didn't mean to suggest that it's simpler with tDave Steinberg---03/30/2011 02:25:17 PM---Hi Frank, I didn't mean to suggest that it's simpler with the single-list approach to From: Dave Steinberg/Toronto/IBM@IBMCA To: [email protected] Date: 03/30/2011 02:25 PM Subject: Re: [oslc-core] ChangeLog Proposal Finalization Sent by: [email protected] Hi Frank, I didn't mean to suggest that it's simpler with the single-list approach to determine how/when to get the subsequent pages. But rather, once you have the data, it's easier to work with, particularly if you're interested in data that crosses page boundaries. You can just merge the models (Model.add () in Jena) and you're left with a nice, simple list to traverse, rather than a nested structure defined by custom vocabulary. We've been doing client work where we actually use Jena as the underlying model, so the simpler option seems more attractive from that perspective. Cheers, Dave -- Dave Steinberg IBM Rational Software [email protected] Inactive hide details for Frank Budinsky---03/30/2011 01:49:14 PM---Hi Dave, That's an interesting suggestion - just use addresFrank Budinsky---03/30/2011 01:49:14 PM---Hi Dave, That's an interesting suggestion - just use addressable entries at the page boundaries to l From: Frank Budinsky/Toronto/IBM To: Dave Steinberg/Toronto/IBM@IBMCA Cc: [email protected], [email protected] Date: 03/30/2011 01:49 PM Subject: Re: [oslc-core] ChangeLog Proposal Finalization Hi Dave, That's an interesting suggestion - just use addressable entries at the page boundaries to link to the continuation of the list on the next page. Personally, I think I still prefer the design where pages (or segments) of the change log are explicitly modeled. I think it is very simple to understand, and the ChangeLog segments could themselves be interesting stand alone URLs (e.g. the changeLog/segment for a specific date). I'm not sure the single list design is simpler anyway. The client will need to check each node to see if it's a blank node of if it requires an HTTP get. The list-of-list model requires only one check for next segment, when it gets to the end of a page's list. Thanks, Frank. Inactive hide details for Dave Steinberg---03/30/2011 11:29:20 AM---Hi Frank et al., Apologies for not being able to make it toDave Steinberg---03/30/2011 11:29:20 AM---Hi Frank et al., Apologies for not being able to make it to the meeting today, and if this From: Dave Steinberg/Toronto/IBM@IBMCA To: [email protected] Date: 03/30/2011 11:29 AM Subject: Re: [oslc-core] ChangeLog Proposal Finalization Sent by: [email protected] Hi Frank et al., Apologies for not being able to make it to the meeting today, and if this input is too late to be useful, I certainly understand that. I think there's still an existing issue with the latest pagination proposal. It looks to me like a list of lists or, rather, something-like-a-list (using custom vocabulary) of lists (using standard vocabulary). And I think that's more effort for a client to understand and deal with than a single, basic list would have been. If the key concern is the use of resources with URIs (as opposed to blank nodes) within each "page" resource, you could still use a single list with mostly blank nodes, but retrievable resources for the first entry on each page. Cheers, Dave -- Dave Steinberg IBM Rational Software [email protected] Inactive hide details for Frank Budinsky---03/29/2011 03:14:35 PM---I also added a short summary of the three remaining issues Frank Budinsky---03/29/2011 03:14:35 PM---I also added a short summary of the three remaining issues on the IndexingProposals WIKI page: From: Frank Budinsky/Toronto/IBM@IBMCA To: [email protected] Date: 03/29/2011 03:14 PM Subject: Re: [oslc-core] ChangeLog Proposal Finalization Sent by: [email protected] I also added a short summary of the three remaining issues on the IndexingProposals WIKI page: http://open-services.net/bin/view/Main/IndexingProposals Frank. [email protected] wrote on 03/29/2011 12:26:13 PM: > [image removed] > > [oslc-core] ChangeLog Proposal Finalization > > Frank Budinsky > > to: > > oslc-core > > 03/29/2011 12:29 PM > > Sent by: > > [email protected] > > Hi all, > > We're very close to finalizing the OSLC ChangeLog proposal. The last > three issues, which are still being discussed are: > > 1. Indexing/ChangeLog resources/scope > Latest email: http://open-services.net/pipermail/oslc-core_open- > services.net/2011-March/000898.html > > 2. ChangeLog Pagination (also URI-addressable ChangeLog entries) > Latest email: http://open-services.net/pipermail/oslc-core_open- > services.net/2011-March/000893.html > > 3. Better name for OSLC indexing profile > Latest email: http://open-services.net/pipermail/oslc-core_open- > services.net/2011-March/000896.html > > We're planning/hoping to finish the discussion of the ChangeLog > proposal at tomorrow's OSLC WG meeting, so please send any > additional comments or ideas that you have by replying to this or > one of the discussion thread emails. > > Thanks to everyone that has provided input so far. > > 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 _______________________________________________ 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 _______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net
