SYSMOAS_ — Read-only API providers

Right now, the standard assumes repositories that provide any of the listed API services to implement all operations of these services, both the read only ones and the mutating ones. I believe we should have at least vocabulary in the standard to describe and recognize the kind of partial compliance with a given API Service where only the read-only operations of the Service are actually provided.

*Reasoning.* In order for a service to claim SysML compliance, it must implement some combination of the 6 existing API services defined in the standard. Most of which prescribe mutation operations such as createProject(), etc. but especially and primarily createCommit(), that make little sense to implement if the single source of truth is a data format other than SysML (or the textual format of SysML), and the SysML format is merely a derived view of the data.

*Example.* An off-the-shelf requirement managements system might not be willing to try and implement arbitrary SysML model mutation commands (especially pertaining to non-requirement stuff), and on the other hand creating requirements entries might require data fields that are not mandatorily written via the SysML API - at any rate this is a bad match.

*Core proposal.* It would make a lot of sense in these use cases if the standard talked about an officially recognized way for these services to claim that they implement some Services of the SysML API - but only the read-only operations. This does not mean that the projects would be immutable, just that they are to be modified through a means other than the SysML API.

*Clarification.* This request is not about user-specific access permissions. Even in the current version of the standard, any SysML v2 repository may in principle be configured so that certain users are forbidden from executing operations that manipulate state, there will still be other users that are authorized to execute them. In contrast, the proposed change would introduce repositories where (certain types of) mutation of state is simply not accomplished through SysML v2 API, but through other means.

*Impact on testability.* Repositories that provide the read-only form of one of the Services should still comply with the semantics and constraints of the read-only operations exposed by the Service. However, since the state of such repositories is not (fully) controllable via the SysML v2 API, this conformance relationship may not be possible to test via the Conformance Test Suite as is. Providers of such repository technologies are expected to demonstrate conformance via modified test cases, adapted to set up and influence repository state by means appropriate for the specific technology, with effects matching the original conformance test as closely as possible.

*Work items.* I propose to elaborate in detail the following changes to the standard:

• Section 2 "Conformance" should be expanded to (a) discuss Service Providers that only expose the read-only fragment of a Service, (b) provide vocabulary to discuss the degree of conformance by Service Providers, and (c) discuss how the conformance of such Service Providers is to be demonstrated
• Section 7.2 "API Services" should identify the subset of operations that are read only, featured both on Tables and on Diagrams (perhaps using the 'query' UML modifier)
• Normative Machine Readable Documents should be updated to reflect in operation metadata which of the API operations are read only; in particular, the PIM XMI should include the UML modifier 'query' for each such operation.