-
Key: SYSMOAS_-106
-
Status: closed
-
Source: IncQuery Labs Ltd. ( Dr. Gábor Bergmann)
-
Summary:
The current requirements for Derived Property conformance (including the changes accepted in https://issues.omg.org/browse/SYSMOAS_-102 ) are too narrow.
- For the Query service, the text only focuses on the derived properties being computed and included in the results. However, it should also clarify whether the query can refer to (i.e. filter by) the computed values of derived features.
- For the Element Navigation Service, the text only mandates that the data structure returned at commit creation should have the derived properties filled in. However, ideally, derived features should also be filled in when requesting element contents for reading, without having updated them; this guarantee is omitted in the current text.
- See the discussion at https://issues.omg.org/browse/SYSMOAS_-102?focusedCommentId=27339&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-27339 on why this is NOT already implied by the current text
-
Reported: SystemsModelingAPI 1.0b2 — Mon, 4 Nov 2024 14:30 GMT
-
Disposition: Resolved — SystemsModelingAPI 1.0b3
-
Disposition Summary:
Derived Property Conformance further clarified
This change further improves on https://issues.omg.org/browse/SYSMOAS_-102
Overview of proposal:
- Clarify that QueryService in conformant providers is to consider derived features referenced in queries
- Clarify that conformant providers must consider the computed values of derived features in the response of not just ProjectDataVersioningService.createCommit but any other API methods that return element Data
- Clarify that responses are to have guarantees even if the original data source was not the createCommit API method
- Clarify the text to acknowledge that derived features may change at elements other than those that were directly changed by a commit.
- Relax the over-specified restriction of when the evaluation must happen; the only thing that shall be prescribed is that it shall happen by the time it is needed by one of the API methods
- Introduce three distinct level of conformance for providers, keeping three legitimate implementation strategies in mind (providers that do not compute anything and treat derived properties as just data; providers the compute derived feature values of an Element on the fly when the element is returned as a response, and providers that precompute/maintain the derived features of all Elements so that the values can be indexed for queries).
- Allow for Provider to be flexible and declare different conformance levels for different derived features and different commits. This may allow them to consider performance or implementation difficulty in choosing which feature to implement in which manner, and maybe even allow the user to specify which projects or commits are important enough to warrant the performance penalty of derived feature precomputation.
- Finally, since the individual derived feature conformance levels are crosscutting across Service Interfaces, the text is removed from subitems under the listing of the 6 Services, and moved into its own 3-item enumeration.
-
Updated: Sat, 19 Jul 2025 19:07 GMT
SYSMOAS_ — Extend Derived Property conformance
- Key: SYSMOAS_-106
- OMG Task Force: Systems Modeling API and Services (SystemsModelingAPI) 1.0 FTF 2