SYSMOAS_ — Expand Conformance Levels for Read-only service providers without splitting PIM services

Summary of rationale for SYSMOAS_-83 (Read-only API providers)

The issue SYSMOAS_-83 (https://issues.omg.org/browse/SYSMOAS_-83) put forth a good suggestion on Conformance levels. A summary of that suggestion and its purpose is stated below.

API and Services Conformances, as specified in section 2 of the specification, are directly based on individual services and require that all operations (get/create/update/delete) for the given service be implemented for a service provider to claim conformance to that service. For example, ProjectService Conformance states the following.

ProjectService Conformance - A Service Provider must implement all the operations in the ProjectService, and demonstrate that the implementation successfully passes all the ProjectService Conformance Test Cases (see A.1) and Cross-Cutting Conformance Test Cases (see A.7).

A digital engineering tool, such as a Requirements management tool or a Product Lifecycle Management (PLM) platform, may expose some of its data using services defined in this standard (Systems Modeling API and Services 1.0) using only the get operations. For example, a Requirements management tool may implement the get operations in ProjectService and ElementNavigationService to fetch requirement projects and requirement structures. Similarly, a PLM platform may implement the same to fetch hardware projects and part BOMs. However, these implementations would be non-conformant to both the ProjectService and ElementNavigationService since they would only implement the get operations and not the create/update/delete (data mutation operations).

Summary of work items for SYSMOAS_-83 (Read-only API providers)
SYSMOAS_-83 also suggested work items (included in its description) that can be summarized as below.

1. Identify get operations from mutation operations (create/update/delete) by using the 'query' UML modifier on those operations.

2. Define Read-level and Read-Write Conformance levels for each service so that non-SysML digital engineering tools that make their data available using get operations can claim Read-level conformance.

Problem with proposal SYSMOAS_-86 for SYSMOAS_-83

The proposal SYSMOAS_-86 for issue SYSMOAS_-83 took an incorrect step with major change impacts that was NOT part of the core work items in SYSMOAS_-83 and also summarized above.

Instead of limiting the change to splitting the Conformance levels for each service in section 2 for Read-Only and Read-Write Conformance, the proposal also split the individial PIM services. A new supertype service was proposed for each PIM service with get operations, e.g. ProjectServiceReadOnly with get operations, inherited by ProjectService that will also include the mutation (create/update/delete) operations.

This proposal of splitting the PIM services was not necessary to achieve the goal of SYSMOAS_-83 and has a major change impact on this specification, as described below:

1. It was not necessary to split the PIM services. Splitting of the Conformance levels in Section 2 and stating that Read-Only Conformance can be achieved by implementing the get operations (also marked by 'query' UML modifier) in each service was sufficient to achieve the original aim. Only the conformance test suite in Appendix A would have to be refactored. No PIM level services, or PSM services/endpoints, or PIM -> PSM mappings would have been affected.

2. Splitting each PIM service also impacts the mapping from PIM -> PSM for both REST/HTTP PSM and OSLC PSM. The mapping tables have to be redone, and the PSM level service groups may have to be modified. For example, GET endpoints in the REST/HTTP PSM may require to be separated from POST/PUT/DELETE. The extent of this change is significant and requires a lot more time to investigate and plan even before affecting the change. Given that FTF2 was closing in August when the proposal was approved, it was infeasible from the start in addition to being unncessary. This is true even with the new Nov 2024 deadline for submission.

3. In the future, as this standard and the service providers evolve, we may need to define new conformance levels or refactor existing conformance levels. Changes in the conformance levels should not require us to rearchitect the design of the PIM services which then subsequently impacts the PSM services and the PIM -> PSM mappings.

4. It is also not recommended to name services with "read" or "write". This is done at the operation level. A service is a grouping of operations related to an entity, and should remain so.

Solution being proposed in this issue
This issue is being opened to correctly implement the core work items of SYSMOAS_-83 and to rollback the PIM service splitting step in proposal SYSMOAS_-86. A draft proposal will be forumated in the comment of this issue, and following a discussion in the FTF2 meeting, a formal proposal will be created an attached to this issue.