OSLC Core extensions proposal

1. OSLC Core extensions proposal Update of the Core WG proposal V0.10 Gray Bachelor and the PLM Workgroup team OSLC PLM Workgroup

2. Topics • Request to the OSLC Core WG • Why do we need versioning support in Core ? • What is the proposal ? • What examples do we have ? • Q&A OSLC PLM Workgroup

3. Summary of the request • The OSLC Core Workgroup to adopt an initial versioning spec as a “Core extension” OSLC PLM Workgroup

4. Why do we need versioning support in Core ? OSLC PLM Workgroup

5. Definition of version • Indicating some thing as a version of another thing is a common way that some difference, or change of state, between two things is denoted1 • Changes of state arise from • Work done on the definition of the thing2 • Application of compositional options3 • Therefore creation of a version is used to • Signal that some change activity has occurred • Trigger evaluation of alternative process states 1 Alternative approaches are to use unique, but related name for things – say by concatenation or specific coding and classification terms 2 Such as evolving or correcting the definition of the thing OSLC PLM Workgroup

6. Versioning is a key aspect of configuration and change control • Alternate versions of a resource allow specific resource states to be linked • Configuration by association of versions of resources allows multiple configurations to be available • e.g. to provide alternative product and system descriptions from a common base and to phase the work needed to make change • Identification of resources as versions is a key means to support change control • e.g. to track changes to an artefact at a coarse grained level, to require approval to allocate a new version OSLC PLM Workgroup

7. Why is versioning needed in OSLC ? • OSLC resources represents things and their inter-relationships • Several OSLC resource can represent composition of related groups of things (e.g. other resources) • Resource use links to signify important relationship e.g. compositional dependencies • Most OSLC resources undergo change • Change to a resource may require re-evaluation of the composition of the resource • Changes to resources may require new links to be established • Changes to resources may invalidate the purpose of a link • Today version support needs to achieve indirectly say by resource properties. However there is a not a common way to define the behaviour of a resource when it is represents a version of another resource • This proposal formalises basic OSLC resource version behaviour • Consistent versioning support if necessary for the OSLC PLM scenario OSLC PLM Workgroup

8. The main PLM scenario is a typical industry case • Dear Systems Engineer please “implement a change to a system product” that is at some defined state, and make it available at a new state Is Implemented By Is Based upon CR CR System or product context System or product context Version Alpha Version Beta Controlled config Controlled config Transition Requirements Requirements Implementation Implementation Version A Version B Version 1 Version 2 State 1 State 2 State 1 is some combination of artefacts that describes what change is based upon, typically it is a previously released configuration . Additional things may be identified to allow e.g. Take account of this, combine these, refer to this too, make one like this from that. The elements that make up the combination are usually under change control to allow an exact as necessary states to be described State 2 is the result of some change and is a involves new, modified, replaced and removed artefacts compared with State 1. State 2 is typically achieved when the state of the artefacts and their relationships meet the requested change. For simplicity intermediate states are not shown and will depend on the sequence and actual means used to make the change. OSLC PLM Workgroup

9. Proposal outline OSLC PLM Workgroup

10. Proposed versioning model: Base resource and versions ResourceVersion: HSUV V1 Resource: HSUV replaces ResourceVersion: HSUV V2 isVersionOf replaces replaces ResourceVersion: HSUV V3 ResourceVersion: HSUV Vulcan replaces ResourceVersion: HSUV V5 replaces ResourceVersion: HSUV 061111 Versions are created by the base resource Version resource isVersionOf a base resource OSLC PLM Workgroup

11. Basic versioning model proposed (2) Resource: HSUV replaces replaces • A base resource • Only the base can make new version resources • Individual resources per version • MAY • isVersionOf the base resource • MAY • Replaces another version resource ResourceVersion: HSUV Vulcan ResourceVersion: HSUV V1 ResourceVersion: HSUV 061111 replaces replaces replaces ResourceVersion: HSUV V2 ResourceVersion: HSUV V3 ResourceVersion: HSUV V5 OSLC PLM Workgroup

12. Simplified proposal OSLC PLM Workgroup

13. Overview of the need for versioning across the OSLC Specs • Change Management - integrations with work item and change management repositories. • e.g. early redefinition of the business intent of a change request may need to be signalled • Quality Management - integrations in quality management and testing. • e.g. a test plan is approved in a certain state, indicated by the state of test harness, test cases and test data. Alternative system configurations may required alterations of any of these to be visibly controlled • Requirements Management and Definition - integrations in requirements management and requirements definition tools. • e.g. a requirement may be allowed to evolve after some agreement amongst stakeholders and so the change will need to be indicated so that the correct stakeholders can be brought to bear on a new agreement on the updated requirement • Asset Management - integrations between asset management and other lifecycle tools. • e.g. an asset will evolve through a series of definition stages with changes during in its lifecycle, the changes may invalidate deployment and management services applied • Architecture Management - integrations related to models and other artifacts used during analysis, design and construction that help maintain architectural integrity. • e.g. an architectural model will undergo significant changes during its evolution and some certain important changes will trigger governance or design review activities • Software Configuration Management - integrations targeted at version control, change sets, baselines and other resources • E.g. revision control is very important to control which artefacts are applied in a given setting and to denote change, either to an individual thing, group via a container or explicit structure • Automation - integrations involving automation tools like build, deploy, and analysis tools. • E.g. an automation plan will evolve, be tested and sanctioned by SMEs based upon evaluation of its outcome. Changes to the plan will result in re-running and re-evaluation or application of alternatives tests and evaluations OSLC PLM Workgroup

14. Example: Requirement ResourceRequirement resource base + 2 revisions shortTitle REQ-20188 Requirement URI1 isVersionOf shortTitle RequirementVersion URI2 REQ-20188-A isVersionOf replaces shortTitle REQ-20188-B RequirementVersion:UR3 OSLC PLM Workgroup

15. Example: ChangeRequest resource shortTitle ECR-000031 ChangeRequest URI1 isVersionOf shortTitle ChangeRequestVersion URI2 ECR-000031/A-US and EU 2016 ULEV standards OSLC PLM Workgroup

16. Example: AM Resource shortTitle AM Resource URI1 isVersionOf shortTitle AM ResourceVersion URI2 AMG60104/004-POWERSUBSYSTEM hasView shortTitle AM ResourceView URI3 AMG60104/004-View hasPart shortTitle AM ResourceVersionURI4 00010998/003-CALIBRATIONS OSLC PLM Workgroup

17. Summary of the version handling proposal • Any OSLC resource can gain version support behaviour through extensions to Core • Applicable to any OSLC resource, including the new proposed Product resource • A base resource can have multiple version resources • hasVersion is an optional property of a base resource • A version resource identifies its base resource • isVersionOf • A version resource can indicate its succession • replaces http://open-services.net/bin/view/Main/Plm20SpecExtensions OSLC PLM Workgroup

18. Questions & Answers • What if my tool provides a versioned container • ANSWER: The resource version identifies the versioned container • What if my tool doesn’t indicate predecessors ? • ANSWER: Indication of succession is a May. • How to identify the versioning behaviour of a resource ? • ANSWER: base will have a minimal resource shape, infer from a resource types with no “isVersionOf”, or “replaces”. Multiple approaches today – Service provider doc, Query Header. Request guidance from Core. • ISSUE: Some SCM tools don’t have a base resource explicitly available e.g. SCCS/RCS/CVS/PVCS • What is the preferred use of backlinks for “hasVersion” ? • ANSWER: May. Preferred approach is not to use backlinks. • Is the a better dcterms property for succession ? ANSWER dcterms :replaces is ambiguous, however its definition includes succession so it is proposed as the most applicable term • What if the resource supports versioning but has no concept of a base resource ? Consequence isVersionOf would be used between ResourceVersions ANSWER: Implemented in the draft at 11/11 but not in the PM Spec Base Resource could be optional MAY Resource Factory for creating a new resource version on a base is optional MAY A creation factory service for a ResourceVersion would be an optional MAY • How associate ResourcesVersions with multiple base resources ? ANSWER: Allow multiple associations isVersionOf one or many • What if a resource doesn’t support versioning, a resource factory for a ResourceVersion as a SHALL is over stating the need ANSWER: Implemented in the draft at 11/11 but not in the PM Spec Resource Factory for creating a new resource version on a base is optional MAY OSLC PLM Workgroup