TRS specification incorrect references OSLC resource paging and not LDP paging

[DavidJohnHoney]

The OSLC TRS specification at https://docs.oasis-open-projects.org/oslc-op/trs/v3.0/ps01/tracked-resource-set.html#paged-base describes base page segmentation as follows:

Base segmentation MUST be accomplished using the mechanisms described in the "Resource Paging" section of [OSLCCore3]. [TRS-28]

This is an incompatible change with respect to TRS 2.0 described by https://archive.open-services.net/wiki/core/TrackedResourceSet-2.0/#Paged-Base . Existing ELM TRS implementations and LQE/LDX only support LDP paging and the use of Link headers as described https://www.w3.org/TR/ldp-paging/ and the TRS 2.0 specification.

My recommendation is to update the TRS 3.0 specification to reference LDP paging only to keep it compatible with TRS 2.0 and existing ELM TRS providers and consumers.

[jamsden]

OSLC Core says "OSLC Services MAY support [[!LDPPaging]] to enable clients to retrieve large LDP resources (LDPRs) a page at a time.". That would reasonably apply to TRS.

[DavidJohnHoney]

Except that, reading the specification as is, all the information and examples that were in TRS 2.0 were removed. A reader is thus left with the false impression that they must implement OSLC Resource Paging and need not implement LDP paging. If they do so, it would not be consumable by LQE/LDX. The TRS specification needs to be more explicit (only LDP paging was described), and ideally, include the examples that were originally in TRS 2.0. I don't think the current state of the specification is acceptable in this respect. We MUST change it to describe that LDP paging is required.

[berezovskyi]

Was LDP paging ever published? I thought it never went past a draft. What alternatives for paging do we have?

Also, LDP paging is quite expansive if you read the draft, I doubt that Jazz (or it is ELM now?) supports all conformant LDP Paging configurations.

Another thought, to republish LDP paging WD as an OSLC Paging PS (or maybe even LDP Paging PS directly) spec.

[jamsden]

Linked Data Platform Paging 1.0https://www.w3.org/TR/ldp-paging/ was withdrawn as a W3C Candidate Recommendation due to lack of sufficient implementations. It is currently published as a W3C Note for future reference. No new LDP working groups were formed to complete LDP Paging or LDP Query. So, implementations of this specification would have to consider the viability of the specification, and perhaps LDP itself for that matter.

OSLC Paging predated LDP Paging, and they don’t share much in common other than REST. At this point, there are likely more implementations of OSLC Paging then LDP Paging. An OSLC-OP investment in LDP Paging would therefore introduce interoperability challenges, just like LDP did for OSLC 2.0, something that in hindsight may not have added much value to OSLC integration. At this point, issues with OSLC Paging would perhaps be best addressed in OSLC Paging in backward compatible manner to avoid introducing interoperability issues.

Given the lack of working groups and progress on LDP Paging, this may not be a good investment for OSLC-OP.

From: Andrew Berezovskyi @.> Reply-To: oslc-op/oslc-specs @.> Date: Wednesday, August 10, 2022 at 1:29 PM To: oslc-op/oslc-specs @.> Cc: Jim Amsden @.>, Comment @.***> Subject: [EXTERNAL] Re: [oslc-op/oslc-specs] TRS specification incorrect references OSLC resource paging and not LDP paging (Issue #578)

Was LDP paging ever published? I thought it never went past a draft. What alternatives for paging do we have? Also, LDP paging is quite expansive if you read the draft, I doubt that Jazz (or it is ELM now?) supports all conformant LDP Paging ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd

Was LDP paging ever published? I thought it never went past a draft. What alternatives for paging do we have?

Also, LDP paging is quite expansive if you read the draft, I doubt that Jazz (or it is ELM now?) supports all conformant LDP Paging configurations.

Another thought, to republish LDP paging WD as an OSLC Paging PS spec.

— Reply to this email directly, view it on GitHubhttps://github.com/oslc-op/oslc-specs/issues/578#issuecomment-1211028459, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAIQFKRJWWZYY6VPIEEL5CDVYPRFZANCNFSM555ZQHUQ. You are receiving this because you commented.Message ID: @.***>

[berezovskyi]

I am trying to hint at the fact that we are discussing NORMATIVE clauses in our specs towards a Note. Hence, there may be interest to do re-homing of the Note to OASIS just to push it at least to a PS stage (not necessarily OS) if our OS-stage specs depend on it.

[DavidJohnHoney]

Folks, you are missing the point. Whether LDP paging was ever published is irrelevant. The fact that OSLC resource paging predated LDP paging is irrelevant, TRS 2.0 required and only supported LDP paging. It did not reference OSLC Resource Paging. From https://archive.open-services.net/wiki/core/TrackedResourceSet-2.0/#Paged-Base the section starts with:

Note (Feature Unstable): The paging support is based on the W3C Linked Data Platform (Paging) Specification that has not stabilized.

The existing TRS consumers (LQE and LDX) only support LDP paging. All the existing TRS providers in ELM use LDP paging because OSLC resource paging is not supported by LQE or LDX.

The TRS 3.0 specification as it stands is incompatible with the TRS 2.0 specification. These are breaking changes that mean that LQE and LDX are likely to be incompatible with TRS implementations written solely based on the TRS 3.0 specification.

I cannot stress how bad a situation this is. It's not enough to say that OSLC allows LDP paging for TRS and to leave the specification citing OSLC resource paging as the recommended approach. Like it or not, TRS 2.0 used and required LDP paging. We need to ensure that TRS 3.0 is upwards compatible with TRS 2.0. This has always been our guiding principle with 3.0 specifications - don't break existing implementations. If OSLC stakeholders do not agree and support the aim of upwards compatibility, then this has a huge impact on ELM - all the existing TRS providers and consumers would need code changes. This would not go down well with IBM product management. We would be failing our duty of care not to break existing usage. I regard this issue as a BLOCKER.

[DavidJohnHoney]

Proposal for review and subsequent vote:

Under 9. Base Segmentation in https://docs.oasis-open-projects.org/oslc-op/trs/v3.0/ps01/tracked-resource-set.html#paged-base,

Remove the following:

Base segmentation MUST be accomplished using the mechanisms described in the "Resource Paging" section of [OSLCCore3]. [TRS-28]

In its place add the following with appropriate conformance clause identifiers TBD:

If base paging is implemented, the server MAY respond with a 30x redirect message, directing the Client to the first “single-page resource”, or alternatively it MAY respond with the first "single-page resource" [TRSxxx].

The representation of a single-page resource MAY contain a subset of the Base’s membership triples [TRSxxx+1].

The response for a single-page resource SHOULD contain a Link: <http://www.w3.org/ns/ldp#Page>; rel="type" header [TRSxxx+2]. If there are further pages of base page members for the single-page response, the response MUST include a Link: <uriOfNextPage>; rel="next" header, where uriOfNextPage is the URI of the next page.[TRSxxxx+3].

The first single-page resource of a Base MUST include a trs:cutoffEvent property [TRSxxx+4].

Additional notes (not to be included in the spec):

The purpose of the following notes are to explain the rationale why the replacement in the above section was written the way it was. I am not proposing any of those notes are to be included in the specifiiation. I am trying to avoid protracted discussion about the proposed replacement text and head off questions that people might have otherwise asked, such as "why did you write it that way" and so on.

I have intentionally not included a link to the W3C LDP paging working note. In ELM, the code that consumes TRS used by LQE, LDX, and TRS validation, only cares about the Link header with rel='next'. So that's required for all single-page responses where there is a next page.

I included the SHOULD for Link: <http://www.w3.org/ns/ldp#Page>; rel="type" because its presence would not break those existing consumers, but more closely aligns it with LDP paging, and allows a client to distinguish a paged response from a non-paged response, especially where the server does not respond with a redirect on the GET of the TRS base. The TRS 2.0 specification used that in the example, and it was required by the W3C LDP Paging note. I made it a SHOULD rather than MUST so that existing implementations of TRS providers can remain compliant. The existing TRS parsing code used by LQE, LDX, and Jazz Foundation does not look for that header, so including it will be benign.

I intentionally omitted mention of first or last page Link headers. Although these headers were in the TSR 2.0 example, they were not in the text. The W3C LDP Paging note describes them as optional. The existing TRS parsing code used by LQE, LDX, and Jazz Foundation does not look for first or last page Link headers.

I added the conformance clause that the first page must contain the cutoff event. This is in the TRS 2.0 specification but was omitted from the TRS 3.0 specification. Existing TRS consumers are likely to rely on this being the case.

I have intentionally limited this proposal to address the issue of compatibility with TRS 2.0. We should not conflate this issue and the proposed changes with other issues such as stable paging. While such issues may be valid, they should be handled in their own separate issues and discussed separately. The immediate concern here is making TRS 3.0 compatible with TRS 2.0 which is currently not the case.

[jamsden]

I think the reference to the W3C LDP Paging note is necessary, otherwise a reader of the TRS spec might wonder about the relationship between OSLC Core and TRS paging.

Regarding the additional type link header, are we trying to replicate OSLC 2.0 TRS paging, or are we trying to design something new and improved?

The fact that the TRS 2.0 spec included a first page link header in the example response, but didn't include it in any normative text would indicate we may not know all the details of existing TRS 2.0 paging implementations and are chasing an open-ended issue.

[DavidJohnHoney]

I think the reference to the W3C LDP Paging note is necessary

I'm confused. My proposed replacement did not include any reference as explained in additional notes. The additional notes (which I am not proposing be included in the spec) are there to explain why my proposed replacement was written that way - that is, not include such a reference. Why do you think I am proposing a link to the W3C LDP Paging note?

Regarding the additional type link header, are we trying to replicate OSLC 2.0 TRS paging, or are we trying to design something new and improved?

Replicate TRS 2.0 paging - all as explained in my Additional notes section.

The fact that the TRS 2.0 spec included a first page link header in the example response, but didn't include it in any normative text would indicate we may not know all the details of existing TRS 2.0 paging implementations and are chasing an open-ended issue.

Not true. I looked at the LQE code that consumes base pages. LQE does not make any reference to first or last page link headers. So as far as TRS consumers are concerned, I have done the analysis. Whether TRS providers provide those headers doesn't matter because the TRS parsing code used by LQE, LDX, and Jazz Foundation will ignore them.

[berezovskyi]

Replicate TRS 2.0 paging

I am against specifying only by example. I am also against copying normative statements from the LDP paging spec.

We should list a short number of LDP paging spec clauses that MUST be supported by a TRS 3.0 server. If first or last page links are not required, simply don't list those clauses.

[DavidJohnHoney]

Replicate TRS 2.0 paging

I am against specifying only by example. I am also against copying normative statements from the LDP paging spec.

We should list a short number of LDP paging spec clauses that MUST be supported by a TRS 3.0 server. If first or last page links are not required, simply don't list those clauses.

I'm puzzled since the proposal of 2022-08-11 doesn't contain "Replicate TRS 2.0 paging". Are you commenting on that proposal? The proposal of 2022-08-11 does not reference the W3C LDP paging note. And there are specific conformance clauses for each aspect of paging in a TRS 3.0 server.