[OASIS Issue Tracker] (OSLCCORE-171) TRS base member predicate may introduce incompatibilities with TRS 1.0

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

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

Nick Crossley commented on OSLCCORE-171:
----------------------------------------

TRS 1.0 was not an OSLC standard, but rather an internal IB document, using IBM namespaces. TRS 2.0 was the first OSLC version of the specification. TRS 1.0 and 2.0 are already incompatible in various ways, including a change in the way change events were specified as members of the TRS as well as the aforementioned namespace changes.

For those reasons, trying to improve TRS 3.0 compatibility with 1.0 seems to me to be not worth any effort.

Generalizing the container type for the base seems more reasonable, but still could cause incompatibilities - an existing client could legitimately today expect only a DirectContainer, and would work with a non-Lyo-based 2.0 conformant server, only to be broken in an update to that server that decided to take advantage of the new more relaxed standard.

More strongly, I feel it would be wrong to change 3.0 to say that the member predicate MUST be rdfs:member - that would be directly incompatible with any 2.0 compliant server that used ldp:member. You could say that the member predicate MUST be rdfs:member or any of its subtypes (not relying on inferencing that would imply that in the first place), but even that might break an existing client.

> TRS base member predicate may introduce incompatibilities with TRS 1.0
> ----------------------------------------------------------------------
>
>                 Key: OSLCCORE-171
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-171
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Bug
>          Components: TRS
>            Reporter: James Amsden
>            Priority: Major
>
> The TRS 1.0 specification did not define a trs:Base class, but rather referred to the object of a trs:base predicate as an "RDF container". The Base Resources does not specify and rdf:type for the base resource. The members of this RDF container are captured using rdfs:member predicates. 
> TRS 2.0 also does not define a trs;Base class, it also refers to the Base resource as the target of the trs:base predicate whose range is specified to be ldp:DirectContainer. The TRS 2.0 spec does define some properties of this unspecified resource type, so when I created the resource shapes for TRS 3.0, I added a trs:Base resource shape that oslc:describes ldp:DirectContainer in order to formerly reflect what was in the 2.0 specification.
> It is not clear what TRS 1.0 implementations exist, but any TRS implementations done using eclipse/Lyo oslc-trs as a reference implementation may not be entirely compatible with TRS 2.0 as specified. It appears oslc-trs does utilize LDP, but it sues ldp:Container, not ldp:DirectContainer (a subclass), and uses rdfs:member, not ldp:member (ldp:member is a subPropertyOf rdfs:member). A TRS provider I recently implemented ([https://github.com/OSLC/iotp-adaptor)] using oslc-trs does produce ldp:Container with rdfs:member, and this base is consumed without any problem by IBM LQE. 
> So it appears we have a mixture of container and member specifications that we may need to maintain for backward compatibility. 
>  
>  



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