[OASIS Issue Tracker] (OSLCCORE-169) Allow for more use of etags in TRS feeds

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/OSLCCORE-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=69784#comment-69784 ] 

David Honey commented on OSLCCORE-169:
--------------------------------------

I don't think the TRS 2.0 spec said anything about the ETag of the tracked resource set resource or the TRS base resource.

Many implementations will construct the initial set of TRS events for including into the Tracked Resource Set resource, and subsequent pages of it dynmically from querying TRS events rather than being first-class persisted resources. It's likely that if they include an ETag header in the response for a GET on the TRS resource or subsequent change log pages this will be a random value. In such implementations a HEAD might also return a random ETag, and a GET will require a query regardless of any preconditions such as If-Modified-Since. Consumers of a TRS are therefore more likely to just perform a GET without preconditions to determine if there are any new events to be processed since last time.

A meaningful ETag for the TRS base and base pages might be implementable. Some implementations have a TRS base and base pages as first-class persisted objects, and hence have an ETag associated with the state of those persisted objects. However, I don't think the TRS spec should mandate an implementation design. A query-based approach that delivers stable paging might be appropriate and it might be difficult to provide a meaningful ETag.

The standard needs to avoid being too prescriptive about ETags on the TRS, change log pages, TRS base, and base pages. I think the only requirement is that if an ETag is present, that a subsequent GET of the same resource MUST return a different ETag value if the response to the GET contains different RDF content. It would be acceptable for a different ETag value to be returned even if the response RDF content was not changed.

There are similar issues with ETag values associated with TRS events and base page members. It should be a requirement that the ETag of a tracked resource be different if its RDF content changes. However, there are a number of implementations in which the ETag represents an internal state, and that state may change without any impact to its public RDF content, and hence not be associated with any TRS event. Hence one cannot guarantee that the ETag when getting a tracked resource will match the ETag of any TRS event for that resource.

> Allow for more use of etags in TRS feeds
> ----------------------------------------
>
>                 Key: OSLCCORE-169
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-169
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Improvement
>          Components: TRS
>            Reporter: Nick Crossley
>            Priority: Major
>
> Allow TRS servers to provide more information about tracked resources, to allow both servers and clients to verify that a tracked resource set is consistent with the set and state of the tracked resources, and/or that a client has correctly processed a TRS feed.



--
This message was sent by Atlassian JIRA
(v7.7.2#77003)