[oslc-core] New OSLC ChangeLog Proposal

[Martin Nally]

See <mn></mn>

Best regards, Martin

Martin Nally, IBM Fellow
CTO and VP, IBM Rational
tel: +1 (714)472-2690



|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Steve K Speicher/Raleigh/IBM                                                                                                                      |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Frank Budinsky <frankb at ca.ibm.com>                                                                                                                |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Martin Nally/Raleigh/IBM at IBMUS, oslc-core at open-services.net                                                                                       |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |01/04/2011 09:50 AM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Re: [oslc-core] New OSLC ChangeLog Proposal                                                                                                       |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|




> From: Frank Budinsky <frankb at ca.ibm.com>
> To: oslc-core at open-services.net
> Cc: Martin Nally/Raleigh/IBM at IBMUS
> Date: 12/20/2010 10:47 AM
> Subject: [oslc-core] New OSLC ChangeLog Proposal
> Sent by: oslc-core-bounces at open-services.net
>
> Hello,
>
> Nick Crossley and I would like to submit a proposal for adding a
ChangeLog
> service to the OSLC core specification. This new service will be key to
the
> success of an indexer, and therefore we would like to queue it up for
> discussion as soon as possible in January.
>
> The OSLC proposal, itself, is described in section 1.5 of the attached
> document, while the rest of the document describes an indexer prototype,
> including how it intends to use the change log.
>
> (See attached file: RDF_indexer_overview_1220.doc)
>
> Any comments/feedback on the new proposal or the indexer prototype itself

> would be very welcome.
>

Hi Frank,

Proposal seems quite simple and workable.  Some initial comments on the
proposal:

Though I would have expected that a client could request a date range for
the change log, or simply "changes since some date time".  Whether some of
the query syntax could be used or simply using name-value pair on changelog
service URI such as ?oslc.since=mmddyy or something.

<mn>Several people have requested this. The current thinking is that so
long as the pages are inverse-time-ordered, clients have enough mechanism
already to satisfy this need. So far this has indeed been adequate for the
prototype implementation. I would prefer to avoid adding more options until
we have a client that can explain in detail why the current solution is
inadequate.</mn>

Why is an ordered collection important if you have oslc:at (timestamp) with
each entry?  Is it expected that clients need to validate oslc:at match the
order?  I suspect the answer is that in order for the indexer to properly
process paged responses, it would like to start with first page received
and not have to fetch all pages to validate order.

<mn>Interesting point. I think there are two possible conceptual models.
One is that a change-log is inherently time-ordered. In that model, you
would expect the representation to reflect that characteristic, and you
would not need features like "?oslc.since=mmddyy" since retrieving the
pages in reverse time order gives you the same result. This is the
conceptual model that underpins the current proposal. The other conceptual
model is that the change log is just a set of entries with time-stamps,
which is the mental model you seem to be working with. Features like "
?oslc.since=mmddyy" are necessary in that model to select a subset that has
the characteristic that all other entries are guaranteed to be older or
younger than all the entries in the subset. I think your model is probably
a workable alternative. I can't think of a compelling reason for adopting
one over the other, although my bias is still towards the current
proposal.</mn>

Would you expect that each occurrence (change event) be possibly a
URI-addressable resource itself?  Proposal seems to imply it is not in your
proof of concept but could imagine implementations where it is.  Not sure
there is any issue with this, just an observation that may be worth noting.

<mn>The current design does not preclude URI-addressable change entries,
but does not require them. If a client had to GET the change events
individually to access their properties, it would have a significant
performance impact.</mn>

It would be interesting when we have this discussion to look at the
scenarios where we are interested in change log for a given resource, for
example "history of a defect", to see how these models should compliment
each other.  As Olivier alluded to in his response, there could be cases
where it might be helpful to extend this to include more detail about the
change.

<mn>Changelogs have been around for a long time, and the scenarios they are
used for are fairly well understood. It's not conventional to try to
implement resource-specific change logs, and I'd be nervous about going
down that path. Also, if you start to put "detail" in a change log, you
will have to invent a security model for the change-log, which I think will
lead to complexity. I don't think we should go there.</mn>

Would be good to stick to Dublin Core, for example dc:date instead of
oslc:at. <mn>Yes, I like that idea.</mn>  Not sure there are good matches
for any of the other properties.

Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645