Re: [oslc-core] Fw: helping out with TRS spec

["Nicholas Crossley" <nick_crossley@us.ibm.com>]

re TBD5 - the base paging is related to
change log processing in the following way.

Suppose we have a client reading the
TRS from a server. The server last calculated the base on Jan 1st at noon.
The client starts reading that base late on Jan 12th. Early on Jan 13th,
the client is still reading the 5th page out of 10 base pages. At that
time, the server decides to rebase - calculate a new base and prune the
change log so it goes back to Jan 6th, keeping 7 days behind the new Jan
13th base as recommended by the standard.

Now the client issues a request to read
the 6th base page. If the server returns the 6th page of the new base,
the client may miss some resources entirely as there is no guarantee the
resources are in the same order or the same pages. If the server preserves
the old base and returns the 6th page of that, there's still a problem
- the new change log does not go back as far as the old base, so change
events from Jan 1st to Jan 6th are missing.

At this point, the best thing the server
can do is fail the attempt to read the 6th base page, probably returning
a 409. In order to do this, the server needs to recognize that a base page
request is for an out of date set of pages. For example, the server could
encode some information about the base age in the paging query string of
the URL for second and subsequent pages.

For TBD 6, we agreed in this week's
Core meeting to separate the Access Control part to a separate spec or
part (TBD).

Nick.



From:      
 David Honey1 <DavidHoney@uk.ibm.com>
To:      
 "Jim Amsden"
<jamsden@us.ibm.com>
Cc:      
 "OASIS OSLC Core
TC Discussion List" <oslc-core@lists.oasis-open.org>
Date:      
 02/02/2018 09:25 AM
Subject:    
   Re: [oslc-core]
Fw: helping out with TRS spec
Sent by:    
   <oslc-core@lists.oasis-open.org>

---

Re TBD3: The support for Etag and HEAD
relates to the tracked resources rather than the TRS resources such a tracked
resource set, change log, base page. I think that might be better covered
in the core spec rather than TRS spec. I think all resources SHOULD support
ETag. MAY is too weak. The Etag is important to support caching.  But
I think that support for HEAD should be a MAY rather than SHOULD.

Re TBD4: We should stick the term "page" rather than "segment".
OSLC Core already uses that term. 

Best regards,
David 



From:        "Jim
Amsden" <jamsden@us.ibm.com> 
To:        "OASIS
OSLC Core TC Discussion List" <oslc-core@lists.oasis-open.org>
Date:        29/01/2018
18:03 
Subject:        [oslc-core]
Fw: helping out with TRS spec 
Sent by:        <oslc-core@lists.oasis-open.org>

---

Forwarding for broader discussion on the core mailing list as others may
be able to provide more informed opinions.


Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575

----- Forwarded by Jim Amsden/Raleigh/IBM on 01/29/2018 12:59 PM -----

From:        Axel
Reichwein <axel.reichwein@koneksys.com>
To:        Jim
Amsden <jamsden@us.ibm.com>
Cc:        "Sarabura,
Martin" <msarabura@ptc.com>
Date:        01/28/2018
10:25 PM
Subject:        RE:
helping out with TRS spec

---

Hello Jim,

I just reviewed the TBDs in 

https://tools.oasis-open.org/version-control/browse/wsvn/oslc-core/trunk/specs/trs/tracked-resource-set.html

1.       TBD1 is related to updating the CSS o make all
uses of RFC2119 words use the rfc2119 style
2.       TBD2 - TRS Client, or simply, client – my preference
would be to use the term “TRS client”, and no definition is needed according
to me
3.       TBD3: “The TRS Server should support ETags, caching,
and conditional GETs for Tracked Resources; TBD: TRS Servers may support
ETags, caching, and conditional GETs for Tracked Resource Sets and Base
resources.” -  replace “should” by “may”
4.       TBD4: Paged Base definition is missing.
5.       TBD5: “TBD: If paging of the base is supported
(see other TBD section), then the server should take care to avoid mismatching
pairing of a new change log with the old base and vice versa.” – I personally
think that this does not need to be explained as the Base and the Change
Log are of different type and would  be segmented each in their own
way. 
6.       TBD6: Access Context - https://issues.oasis-open.org/browse/OSLCCORE-82


How about this text for TBD4: “”Often, the number of member Resources
in the Base will grow to the point where it is not reasonable to contain
all the Resources in a single HTTP response. In this case, the base member
Resources may be segmented into separate resources. There can be any number
of such base member Resource segments, each one containing a subset of
all  base member Resource segments.

Regarding TBD6: Access Context, it seems to me that Access Context is an
orthogonal topic to OSLC resources in general, and it is not specific to
TRS. I don’t think that Access Context should be standardized in an OSLC
spec. 

I’m not sure if the TBDs all correspond to an existing issue. I guess
the list of existing issues is more specifically what I should be looking
at
https://issues.oasis-open.org/browse/OSLCCORE/component/12922/?selectedTab=com.atlassian.jira.jira-projects-plugin:component-summary-panel

I guess that I should add my comments to the issues? Or should I just review
the existing spec at 
https://tools.oasis-open.org/version-control/browse/wsvn/oslc-core/trunk/specs/trs/tracked-resource-set.html
and potentially create new issues?

There are really many issues related to TRS…Are there any issues that
I should tackle first? Do we have a deadline? 

Best regards,
Axel




From: Jim Amsden [mailto:jamsden@us.ibm.com]
Sent: Tuesday, November 14, 2017 7:16 AM
To: Axel Reichwein
Subject: Re: helping out with TRS spec

Axel,
Thanks for volunteering, we welcome broader input in order to promote effective
integration technologies.

Instructions for editing documents are from the OSLC Domains TC Wiki: https://github.com/oasis-tcs/oslc-domains/wiki.
These apply to OSLC Core spec too.

OSLC Core issues are in Jira: https://issues.oasis-open.org/browse/OSLCCORE-93?jql=project%20%3D%20OSLCCORE.
TRS issues are in the TRS Component. Create whatever issues you want to
manage your work.

Subversion is used for SCM: https://tools.oasis-open.org/version-control/browse/wsvn/oslc-core/trunk/

TRS specs are here: https://tools.oasis-open.org/version-control/browse/wsvn/oslc-core/trunk/specs/trs/#_trunk_specs_trs_

Send Robin Cover <robin@oasis-open.org>
a note to get write access to SVN. I use Subclipse, but there are other
SVN clients you can use.


I have done and checked in the following based on the actions from last
week's meeting:

1. added the tracked-resource-set-vocab.html document. This needs some
editing, I just copied a template and added the ReSpec processing of the
TRS domain vocabulary and shapes. This is also part 2 of a multi-part specification.
So those two parts need to be added to the tracked-resource-set.html document
too. See the CM spec for an example on how to do this: https://github.com/oasis-tcs/oslc-domains/tree/master/cm.

2. I added the TRS Patch section back into the tracked-resource-set.html
document

3. I was suppose to add the Access Control section back, but I found it
was already there. Maybe I missed something.

4. I created an initial draft of the trs-guidance.html document and put
the old content in there. https://tools.oasis-open.org/version-control/browse/wsvn/oslc-core/trunk/supporting-docs/trs-guidance.html




Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575




From:        Axel
Reichwein <axel.reichwein@koneksys.com>
To:        "nick_crossley@us.ibm.com"
<nick_crossley@us.ibm.com>
Cc:        Jim Amsden
<jamsden@us.ibm.com>,
"msarabura@ptc.com"
<msarabura@ptc.com>
Date:        11/14/2017
09:46 AM
Subject:        helping
out with TRS spec

---

Hello Nick, Jim, Martin,

As I volunteered to help out with the TRS spec, could you share with me
some documents on how to do it? Will I be assigned Jira issues to keep
track of my tasks?

Best regards,
Axel




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU