SYSMOAS_ — Consistency and future-proofing of read-only API providers

Follow-up from https://issues.omg.org/browse/SYSMOAS_-83 and specifically the comment https://issues.omg.org/browse/SYSMOAS_-86?focusedCommentId=26800&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-26800 by Mr. Hans Peter de Koning

Two of the Service interfaces, namely ElementNavigationService and ExternalRelationshipService, are entirely read only, and thus are not affected by the resolution of https://issues.omg.org/browse/SYSMOAS_-83 - they work with read only API providers as is.

However, as Mr. Hans Peter de Koning argues, we should treat them the same way as all the other Service interfaces. Even though this is not useful at the moment, there are two good reasons to extend the change:

• Consistency among parts of the API: by having different parts of the API resemble each other in a systematic way and share common logic or naming conventions, Clients and Providers will both find it easier to (a) implement communication through the API and (b) communicate about required or supplied conformance to API services
• Future proofing: in case future editions of the standard introduce read-write operations to these two API services, there will already be a place ready for them in the standard, both in the normative machine-readable models and the language of the text.