Systems Modeling API and Services Avatar
  1. OMG Specification

Systems Modeling API and Services — Closed Issues

  • Acronym: SystemsModelingAPI
  • Issues Count: 87
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
SYSMOAS_-119 ExternalData and ExternalRelationship missing in sub-clause 8.2.3 PIM API Model - OSLC PSM Resource Mapping SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Resolved closed
SYSMOAS_-96 Time monotonicity in history SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Resolved closed
SYSMOAS_-104 ExternalRelationship creation and deletion operations missing from ExternalRelationshipService SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Resolved closed
SYSMOAS_-105 Inconsistency between PIM Query Model and REST/HTTP PSM JSON schema SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Resolved closed
SYSMOAS_-106 Extend Derived Property conformance SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Resolved closed
SYSMOAS_-61 SysML and KerML OSLC API vocabulary and shapes files need updates for FTF2 SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Resolved closed
SYSMOAS_-69 Does Project own queries SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Resolved closed
SYSMOAS_-89 Consistency and future-proofing of read-only API providers SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Closed; No Change closed
SYSMOAS_-7 derived relation without a specification of how it is derived SystemsModelingAPI 1.0a1 SystemsModelingAPI 1.0b3 Resolved closed
SYSMOAS_-30 created needs to be consistent SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Resolved closed
SYSMOAS_-68 Definition ExternalData is unclear SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Resolved closed
SYSMOAS_-94 Expand Conformance Levels for Read-only service providers without splitting PIM services SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Resolved closed
SYSMOAS_-8 humanIdentifier attribute is missing in API JSON schema for Commit entity SystemsModelingAPI 1.0b1 SystemsModelingAPI 1.0b3 Resolved closed
SYSMOAS_-20 Description of deletion in createCommit row seems wrong SystemsModelingAPI 1.0b1 SystemsModelingAPI 1.0b3 Resolved closed
SYSMOAS_-55 wrong multiplicity on DataVersion SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Resolved closed
SYSMOAS_-49 how is /versionData calculated SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Duplicate or Merged closed
SYSMOAS_-74 changeTypes argument not in the table SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Resolved closed
SYSMOAS_-9 Include typing hierarchy into SysML2 OSLC vocabulary SystemsModelingAPI 1.0a1 SystemsModelingAPI 1.0b3 Closed; No Change closed
SYSMOAS_-10 Cleanup OSLC API Resource Shapes and Vocabulary artifacts from OCL code SystemsModelingAPI 1.0a1 SystemsModelingAPI 1.0b3 Closed; No Change closed
SYSMOAS_-11 Query conformance and derived properties SystemsModelingAPI 1.0a1 SystemsModelingAPI 1.0b3 Resolved closed
SYSMOAS_-56 Branches are mutable SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Resolved closed
SYSMOAS_-83 Read-only API providers SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Resolved closed
SYSMOAS_-78 DataVersion.identity multiplicity SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Resolved closed
SYSMOAS_-3 The SysML OSLC 3.0 API should reference OASIS vocabulary and constraint specifications instead of copying them in a zip file SystemsModelingAPI 1.0b1 SystemsModelingAPI 1.0b3 Closed; No Change closed
SYSMOAS_-2 The OASIS OSLC SysML vocabulary uses namespace: http://open-services.net/ns/sysmlv2#. SystemsModelingAPI 1.0b1 SystemsModelingAPI 1.0b3 Resolved closed
SYSMOAS_-1 The OSLC SysML v2 vocabulary, like the JSON schema, is standalone, merges KerML into SysML v2 XMI and does not import or specialize KerML SystemsModelingAPI 1.0b1 SystemsModelingAPI 1.0b3 Closed; No Change closed
SYSMOAS_-5 Provide details on deleting a project that has commits with data SystemsModelingAPI 1.0a1 SystemsModelingAPI 1.0b3 Resolved closed
SYSMOAS_-4 Develop Conformance Test Suite for OSLC PSM SystemsModelingAPI 1.0a1 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-12 Develop REST/HTTP PSM Conformance Test Suite for Project endpoints SystemsModelingAPI 1.0a1 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-6 Add examples for creating, updating, and deleting elements in the OpenAPI spec for REST/HTTP PSM SystemsModelingAPI 1.0a1 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-13 Develop REST/HTTP PSM Conformance Test Suite for Commit endpoints SystemsModelingAPI 1.0a1 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-14 Develop REST/HTTP PSM Conformance Test Suite for Element and Relationship endpoints SystemsModelingAPI 1.0a1 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-15 Develop REST/HTTP PSM Conformance Test Suite for Branch endpoints SystemsModelingAPI 1.0a1 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-16 Develop REST/HTTP PSM Conformance Test Suite for Tag endpoints SystemsModelingAPI 1.0a1 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-17 Develop REST/HTTP PSM Conformance Test Suite for Query endpoints SystemsModelingAPI 1.0a1 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-18 Develop REST/HTTP PSM Conformance Test Suite for Meta endpoints SystemsModelingAPI 1.0a1 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-19 Develop REST/HTTP PSM Conformance Test Suite for Diff and Merge endpoints SystemsModelingAPI 1.0a1 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-21 Greater Scope SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-22 Not everything needs to be a UUID SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-23 What Language is are these models in SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-24 other attributes in Record not needed SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-25 IRI needs defintion SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-26 All Attributes and AssociationEnds are singular SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-27 many of the association ends are wrapped SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-28 all multiplicities explicity SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-29 ownership dots SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-31 visibility needs to be consistent SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-32 JoinOperator and Operator are enumerations SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-33 inconsistency with queries SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-34 Fig. 7 orderBy should be {ordered} SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-35 value being 1..* SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-36 specification example SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-37 specification and language need to be {ordered} SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-38 over specification of the API SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-39 should have defaults consistent in the parameters SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-40 there needs to be a stament in the standard concerning how things are serialized SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-41 some attributes need to be {readOnly} SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-42 need attribute /usedProject SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-43 OCL Constraints SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-44 multiplictiy change on Tag Commit SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-45 two branches can have the same head SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-46 navigation between DataVersion to DataIdentity SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-47 multiplicity change between Project and DataVersion SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-50 Need both an internal and external ProjectUsage SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-48 Head on Branch should be multiplicity 0..1 SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-51 Semantics of ProjectUsage needs to be defined SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-52 need the commit for a project SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-53 Data needs to be reworked SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-54 previousCommits must be in the same project as the Commit SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-57 locking SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-58 scope on Query SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-59 create and delete should not be on DataIdentity SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-62 getId() isn't implemented for realizations of Data SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-63 Data Identity attributes don't exist SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-64 Why does the spec say that Data Version.id is randomly generated SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-65 identifiedData does not exist SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-66 usage doesn't exist SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-67 why redefine owningProject for Branch SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-70 why is "select" typed by string? SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-71 Constraint property and value typed by strings SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-72 How to provide other properties of Project SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-73 Why do we need both project and commit as arguments in ElementNavigationService SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-76 updateQuery needs more explanation SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-75 Does mergeIntoBranch.resolution need to be typed by DataVersion? SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-77 How do ProjectUsages and DataVersions interact SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-82 createCommit Element deletion rules are model-breaking SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed
SYSMOAS_-121 The description of Commit.change-Deleting is not clear SystemsModelingAPI 1.0b2 SystemsModelingAPI 1.0b3 Deferred closed

Issues Descriptions

ExternalData and ExternalRelationship missing in sub-clause 8.2.3 PIM API Model - OSLC PSM Resource Mapping

  • Status: closed  
  • Source: InterCAX ( Dr. Manas Bajaj)
  • Summary:

    The mapping table from the PIM API model in sub-clause 8.2.3 to the OSLC PSM Resource mapping is missing rows for ExternalData and ExternalRelationship.

  • Reported: SystemsModelingAPI 1.0b2 — Mon, 3 Feb 2025 18:43 GMT
  • Disposition: Resolved — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Add mapping for ExternalData and ExternalRelationship for API PIM - OSLC PSM Mapping

    This proposal adds two missing rows in the table in sub-clause 8.2.3 for PIM API model to OSLC resource mapping, as described in the Revised Text.

  • Updated: Sat, 19 Jul 2025 19:08 GMT

Time monotonicity in history

  • Status: closed  
  • Source: IncQuery Labs Ltd. ( Dr. Gábor Bergmann)
  • Summary:

    We shall codify an additional invariant that ensures Commit timestamps increase monotonically, i.e. past commits have a strictly older timestamp.

    Reasoning:

    • this would make comparing and ordering Commits easier; given two commits from the history of a branch, it would take a single step (just comparing timestamps) to determine which one came earlier, without having to crawl through a potentially long chain of commits.
    • there is little extra burden brought by the introduction of this constraint, as it is already how most use cases would work, with Commits being created one by one and timestamps being naturally assigned at the time of Commit creation; this additional invariant would only really constraint edge cases, such as when a large volume of history is imported from an external format, and timestamps are synthetically assigned en masse
  • Reported: SystemsModelingAPI 1.0b2 — Mon, 5 Aug 2024 07:33 GMT
  • Disposition: Resolved — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Require strictly monotonic Commit timestamps

    In Sec. 7.1.2, two new pieces of text are to be inserted, in order to clarify the monotonicity invariant, and the universal representation of timestamps.

  • Updated: Sat, 19 Jul 2025 19:08 GMT

ExternalRelationship creation and deletion operations missing from ExternalRelationshipService

  • Status: closed  
  • Source: Dassault Systemes ( Mr. Tomas Vileiniskis)
  • Summary:

    Similarly to ProjectUsage, ExternalRelationship inherits from Data, hence PIM level operation definitions should be consistent for both. At the moment PIM level ExternalRelationshipService group is lacking operations for ExternalRelationship creation and deletion when compared to ProjectUsageServices, hence:

    1. PIM level ExternalRelationshipService group should have createExternalRelationship and deleteExternalRelationship operations added
    2. REST/HTTP PSM level operation to service mappings should provide steps on how createExternalRelationship and deleteExternalRelationship are realized through the createCommit operation
  • Reported: SystemsModelingAPI 1.0b2 — Wed, 11 Sep 2024 19:23 GMT
  • Disposition: Resolved — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Added PIM operations and related PIM -> PSM mappings for creating and deleting external relationships

    This proposal introduces createExternalRelationship and deleteExternalRelationship operations under ExternalRelationshipService as helper operations and to maintain consistency with similar operations in ProjectUsageService. It also adds PIM -> PSM mappings for these 2 new operations.

  • Updated: Sat, 19 Jul 2025 19:08 GMT

Inconsistency between PIM Query Model and REST/HTTP PSM JSON schema

  • Status: closed  
  • Source: Dassault Systemes ( Mr. Tomas Vileiniskis)
  • Summary:

    The Query model in PIM, specifically PrimitiveConstraint entity has value attribute data type as String [ 1..* ].

    However, the PrimitiveConstraint's value attribute in REST/HTTP PSM JSON schema is not typed as Array, causing inconsistency between PIM and PSM models.

    The value data type in both Query PIM and PSM should be an array.

  • Reported: SystemsModelingAPI 1.0b2 — Thu, 12 Sep 2024 16:19 GMT
  • Disposition: Resolved — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Resolve inconsistencies in PrimitiveContraint operator and values between PIM and REST/HTTP PSM (JSON schema)

    This proposal includes changes in the API PIM and the OpenAPI specification (JSON schema) for the REST/HTTP PSM to resolve inconsistencies in PrimitiveConstraint operator and values.

  • Updated: Sat, 19 Jul 2025 19:08 GMT
  • Attachments:

Extend Derived Property conformance

  • 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.
  • 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

SysML and KerML OSLC API vocabulary and shapes files need updates for FTF2

  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    https://www.omg.org/spec/SystemsModelingAPI/20240801/OSLC-Domain-Model.zip, needs updated vocabulary and constraints files for KerML and SysML:

    • KerML Shapes-shapes.xml
    • KerML Vocabulary-vocab.xml
    • SysML Shapes-shapes.xml
    • SysML Vocabulary-vocab.xml

    The vocabulary terms updates include:

    • Use updated SysML.ecore and KerML.ecore source files for generating the vocab files.
    • Add the ontology element to the vocab .ttl file.
    • Generate Turtle instead of RDF/XML
    • KerML and SysML v2 Element subclass oslc_am:Resource to link SysML elements to other lifecycle resources (e.g., requirements, change requests, test cases, etc.)
    • Add rdfs:isDefinedBy oalc_sysmlv2 and rdfs:label to each vocabulary terms
    • Translate the EEnum enumerations to RDF, e.g., FeatureDirectionKind
      See [Defining Enumerations](https://docs.oasis-open-projects.org/oslc-op/core/v3.0/os/core-vocab.html#enumerations). An EEnum would be an rdfs:Class (with label, comment and definedBy). Its enumeration literals have rdf:type of the enumeration class, and just a label.
    • Add SysML subclasses in the SysML vocabulary terms
    • Use the KerML and SysML v2 non-versioned namespace for the vocabulary terms to follow OASIS OSLC namespace guidelines:
      @prefix oslc_sysml: <https://www.omg.org/spec/SysML/vocabulary/>
      @prefix oslc_kerml: <https://www.omg.org/spec/KerML/vocabulary/>
    • Add assertion <https://www.omg.org/spec/SysML/20250201/vocabulary/> owl:sameAs <https://www.omg.org/spec/SysML/vocabulary/> to conform to OMG namespace guidelines. Add a similar assertion for KerML
    • Set rdfs:comment in the vocab file to be the first paragraph in the eCore description with the markup stripped out. rdfs:comment is a string and should not contain markup. Including the complete description in the OASIS vocabulary documents results in unwieldy machine readable documents, poor formatting, and unnecessary duplication of information.
    • Fixed all OSLC ShapeChecker errors
    • Rename the files to replace space in the names with "-"

    The resource shape constraint updates include:

    • Used updated SysML.ecore and KerML.ecore source files for generating shapes files.
    • Add the missing ResourceShapeConstraints element to the shapes.ttl file
    • Generate Turtle instead of RDF/XML (for readability)
    • Add inherited oalc_am:Resource properties to the shapes for KerML and SysML v2 Element to include recommended OSLC core common properties, and link types for integration with other OSLC domains (e.g., Change Management, Requirements Management and Quality Management).
    • Update the versioned namespace for the resource shape constraints:
      @prefix : <https://www.omg.org/spec/SysML/20250201/shapes/> . Similar change for KerML
    • Set dcterms:description in the shapes files to the first paragraph in the eCore description, retaining the markup. dcterms:description is an XMLLiteral so the markup can be retained.
    • Removed the classname_ prefix from all properties constraint names to conform with the JSON Schema naming conventions. One 58 properties have multiple domains (containing classes) and these are scoped in the ResourceShape by using RDF blank nodes for these properties.
    • Add cardinality, range and valueType to shape properties that correspond to the Ecore representation.
    • Fixed all ShapeChecker errors

    The OSLC artifacts for the current abstract syntax, as well as the script to update the artifacts, are available as open source here: https://github.com/oslc-op/oslc-specs/tree/master/specs/sysml.

  • Reported: SystemsModelingAPI 1.0b2 — Wed, 1 May 2024 14:30 GMT
  • Disposition: Resolved — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Proposed resolution for: SysML and KerML OSLC API vocabulary and shapes files need updates for FTF2

    https://www.omg.org/spec/SystemsModelingAPI/20240801/OSLC-Domain-Model.zip, needs updated vocabulary and constraints files for KerML and SysML:

    • KerML-Shapes-shapes.xml
    • KerML-Vocabulary-vocab.xml
    • SysML-Shapes-shapes.xml
    • SysML-Vocabulary-vocab.xml

    The vocabulary terms updates include:

    • Use updated SysML.ecore and KerML.ecore source files for generating the vocab files (will require one more update when SysML.ecore is updated in FTF2).
    • Add the ontology element to the vocab .ttl file.
    • Generate Turtle instead of RDF/XML
    • KerML and SysML v2 Element subclass oslc_am:Resource to link SysML elements to other lifecycle resources (e.g., requirements, change requests, test cases, etc.)
    • Add rdfs:isDefinedBy oalc_sysml and rdfs:label to each vocabulary terms
    • Translate the EEnum enumerations to RDF, e.g., FeatureDirectionKind
      See [Defining Enumerations](https://docs.oasis-open-projects.org/oslc-op/core/v3.0/os/core-vocab.html#enumerations). An EEnum would be an rdfs:Class (with label, comment and definedBy). Its enumeration literals have rdf:type of the enumeration class, and just a label.
    • Add SysML subclasses in the SysML vocabulary terms
    • Use the KerML and SysML v2 non-versioned namespace for the vocabulary terms to follow OASIS OSLC namespace guidelines with changes to follow OSLC PSM namespace guidelines:
      1. The vocabulary namespace is not versioned
      2. The namespace ends in # to support fragment URIs
      2. The namespace is all lower case

    @prefix oslc_sysml: <https://www.omg.org/spec/sysml/vocabulary#>
    @prefix oslc_kerml: <https://www.omg.org/spec/kerml/vocabulary#>

    • Add assertion <https://www.omg.org/spec/sysml/20250201/vocabulary#> owl:sameAs <https://www.omg.org/spec/sysml/vocabulary#> to conform to OMG namespace guidelines. Add a similar assertion for KerML
    • Set rdfs:comment in the vocab file to be the first paragraph in the eCore description with the markup stripped out. rdfs:comment is a string and should not contain markup. Including the complete description in the OASIS vocabulary documents results in unwieldy machine readable documents, poor formatting, and unnecessary duplication of information.
    • Fixed all OSLC ShapeChecker errors
    • Rename the files to replace space in the names with "-"

    The resource shape constraint updates include:

    • Used updated SysML.ecore and KerML.ecore source files for generating shapes files.
    • Add the missing ResourceShapeConstraints element to the shapes.ttl file
    • Generate Turtle instead of RDF/XML (for readability)
    • Add inherited oalc_am:Resource properties to the shapes for KerML and SysML v2 Element to include recommended OSLC core common properties, and link types for integration with other OSLC domains (e.g., Change Management, Requirements Management and Quality Management).
    • Update the versioned namespace for the resource shape constraints:
      @prefix : <https://www.omg.org/spec/sysml/20250201/shapes#> . Similar change for KerML
    • Set dcterms:description in the shapes files to the first paragraph in the eCore description, retaining the markup. dcterms:description is an XMLLiteral so the markup can be retained.
    • Removed the classname_ prefix from all properties constraint names to conform with the JSON Schema naming conventions. 58 properties have multiple domains (containing classes) and these are scoped in the ResourceShape by using RDF blank nodes for these properties.
    • Add cardinality, range and valueType to shape properties that correspond to the Ecore representation.
    • Fixed all ShapeChecker errors

    The OSLC artifacts for the current abstract syntax, as well as the script to update the artifacts, are available here: https://github.com/oslc-op/oslc-specs/tree/master/specs/sysml. These will be moved to an OMG site for FTF2.

  • Updated: Sat, 19 Jul 2025 19:07 GMT
  • Attachments:

Does Project own queries

  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The property doesn't seem to be composite in the API

  • Reported: SystemsModelingAPI 1.0b2 — Thu, 9 May 2024 10:15 GMT
  • Disposition: Resolved — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Project - Query should be a Composite Association in Figure 7 (Section 7.1.4)

    The definition of Project in section 7.1.2 of the specification states the following about the Project.queries property.

    queries is the set of Query records owned by the project. Each Query record represents a saved query for the given project. See Query for details.

    Since a project owns the queries, the association between Project - Query in the Figure 7 of section 7.1.4 should be a composite association and not just an association. This is a proposal to update the PIM model and the diagram shown in Figure 7.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

Consistency and future-proofing of read-only API providers


derived relation without a specification of how it is derived

  • Key: SYSMOAS_-7
  • Status: closed  
  • Source: International Business Machines ( Mr. Eran Gery)
  • Summary:

    In section 7.1.2 - the Data Versioning API Model, versionedData is a derived relationship. The spec does not specify what/how it is derived from.

  • Reported: SystemsModelingAPI 1.0a1 — Thu, 13 Jul 2023 18:08 GMT
  • Disposition: Resolved — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Include OCL with description for computing Commit.versionedData in sub-clause 7.1.2

    This proposal will add OCL and related description for computing Commit.versionedData in the Commit section of sub-clause 7.1.2. The specific addition is described in the Revised Text of this proposal.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

created needs to be consistent

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    Fig 5 Project, Commit, CommitReference all have created as a attribute, But many of the examples (and some of the text have timestamp).. needs to be consistent… I like “created” as it tells one what the timestamp is for

    and deleted as the other timestamp name

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 19 Apr 2024 15:00 GMT
  • Disposition: Resolved — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Ensure consistent naming of created and deleted timestamps

    As described in the issue, the timestamp properties are inconsistently named in the text of subclause 7.1.2 compared to Figure 5 in the PIM model. The proposal is to consistently rename them to created and deleted properties wherever such a discrepancy occurs, and to show the properties consistently in Figure 5 and the text.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

Definition ExternalData is unclear

  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The spec says "and represents the relationship between a
    KerML Element [KerML] in a provider tool or repository to ExternalData in another tool or repository." This sounds very vague given that the neither the notions repository or tool have official definitions.

    The spec also says "ExternalData may be a KerML Element or a non-KerML Element." I don't see how this is significant given that access is via IRI anyway.

  • Reported: SystemsModelingAPI 1.0b2 — Thu, 9 May 2024 10:13 GMT
  • Disposition: Resolved — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Replace "tool" and "repository" to "service provider" in ExternalRelationship and ExternalData definitions

    The definitions of ExternalData and ExternalRelationship in section 7.1.3 use the terms "tool" and "repository" that are not formally defined in the specification. We can use terms "service provider" and "service consumer" that are defined in the specification.

    (1) For ExternalRelationship, the first two lines state the following:

    ExternalRelationship - ExternalRelationship is a realization of Data, and represents the relationship between a KerML Element [KerML] in a provider tool or repository to ExternalData in another tool or repository. The ExternalData may be a KerML Element or a non-KerML Element.

    (2) For ExternalData, the first line states the following:

    ExternalData - ExternalData is a realization of Data, and represents a resource external to a given tool or repository.

    The Revised Text shows the updated text for the first two lines of ExternalRelationship definition and first line of ExternalData definition for
    section 7.1.3.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

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

  • Status: closed  
  • Source: InterCAX ( Dr. Manas Bajaj)
  • Summary:

    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.

  • Reported: SystemsModelingAPI 1.0b2 — Sun, 28 Jul 2024 23:37 GMT
  • Disposition: Resolved — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Add new Read Conformance levels

    This proposal defines four (4) new "Read" conformance levels based on operations that only get/fetch data but not create/modify data.

    Service Providers that will implement the Systems Modeling API and Services to only get data from their respective tools/platform will be able to demonstrate the "Read" conformance levels, and not be required to implement operations related to creation/modification of data.

    The specific changes needed in the specification are listed in the Revised Text section.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

humanIdentifier attribute is missing in API JSON schema for Commit entity

  • Key: SYSMOAS_-8
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Tomas Vileiniskis)
  • Summary:

    The API PIM specification has a Record entity with humanIdentifier attribute. Commit entity inherits from Record, therefore it is expected for humanIdentifier attribute to exist in Commit entity as well. This is not the case at the moment when looking at the API JSON schema.

    humanIdentifier is crucial for tool vendors to be able to relate commit UUIDs to version identifiers that are specific to the different versioning schemas used by different tool vendors.

  • Reported: SystemsModelingAPI 1.0b1 — Fri, 14 Jul 2023 09:32 GMT
  • Disposition: Resolved — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Harmonize name, alias, humanIdentifier from Record and subtypes in the API model and JSON schema

    This proposal aims to harmonize name, alias, and humanIdentifier attributes in Record (and its subtypes) in the PIM API model and the resulting JSON schema using in the REST/HTTP PSM.

    (1) Record.alias will be updated, described in the Revised Text. The attribute alias will also be added to all types of Records in the JSON schema, as described in item (4) in the Revised Text.

    (2) Record.humanIdentifier will be changed to Record.name, described in item (2) in the Revised text. For Project, Commit Reference, and Query name will be redefined to be mandatory, as described in item (3) in the Revised text.

  • Updated: Sat, 19 Jul 2025 19:07 GMT
  • Attachments:

Description of deletion in createCommit row seems wrong

  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The spec says: "DataVersion.identity should be populated with the DataIdentity that will be deleted in the new commit. When a DataIdentity is deleted in a commit, all its versions (DataVersion) are also deleted,"

    This sounds wrong - presumably DataVersions referenced by earlier Commits need to be maintained. This does seem to be the way that the reference implementation behaves.

  • Reported: SystemsModelingAPI 1.0b1 — Wed, 20 Dec 2023 09:45 GMT
  • Disposition: Resolved — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Deleted element accessible in previous commits

    Add a clarification for data deletion in the description of ProjectDataVersioningService.createCommit operation.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

wrong multiplicity on DataVersion

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    Data Version record is associated with up to one (0..1) Data Identity record, this is wrong it is multiplicity of 1

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 19 Apr 2024 16:58 GMT
  • Disposition: Resolved — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Data Version record is associated with exactly one Data Identity record

    The second line in the definition of Data Version in clause 7.1.2 states the following:

    A Data Version record is associated with up to one (0..1) Data Identity record.

    It should be updated to the line provided in the Revised Text.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

how is /versionData calculated


changeTypes argument not in the table

  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    in the description of getCommitChange and diffCommits they reference an optional argument changeTypes, which doesn't appear in figure 10

  • Reported: SystemsModelingAPI 1.0b2 — Thu, 9 May 2024 10:26 GMT
  • Disposition: Resolved — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Add argument changeTypes to ProjectDataVersioningService operations

    The argument changeTypes is missing from the operations getCommitChange and diffCommits in ProjectDataVersionService, as shown on Figure 10.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

Include typing hierarchy into SysML2 OSLC vocabulary

  • Key: SYSMOAS_-9
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Tomas Vileiniskis)
  • Summary:

    Since OSLC vocabulary gets generated automatically from SysML2 metamodel, it would make sense for it to include typing hierarchy (eSuperTypes of eClassifiers --> rdfs:subClassOf statements) which would make the vocabulary more semantically “rich” and enable some RDFS reasoning on top of it.

  • Reported: SystemsModelingAPI 1.0a1 — Fri, 14 Jul 2023 09:45 GMT
  • Disposition: Closed; No Change — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Generate SysML2 OSLC vocabulary by taking typing hierarchy into account

    As per discussion and resulting attachments in SYSMOAS_-3, the generation process of SysML2 OSLC Vocabulary now takes typing hierarchy into account, hence this issue is no more relevant and should be closed with No Change.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

Cleanup OSLC API Resource Shapes and Vocabulary artifacts from OCL code

  • Status: closed  
  • Source: Dassault Systemes ( Mr. Tomas Vileiniskis)
  • Summary:

    OSLC API Resource Shapes and Vocabulary (both for KerML and SysML2) get automatically generated from respective Ecore metamodels, which leads to OCL expressions ending up as part of documentation in <rdfs:comment> properties. This makes the generated vocabularies and shapes super ugly and hard to read, e.g.:

    <rdf:Description rdf:about="https://www.omg.org/spec/SysML/20230201/vocab#Expression">
        <rdfs:comment>&lt;p&gt;An Expression is a Step that is typed by a Function. An Expression that also has a Function as its &lt;code&gt;featuringType&lt;/code&gt; is a computational step within that Function. An Expression always has a single &lt;code&gt;result&lt;/code&gt; parameter, which redefines the &lt;code&gt;result&lt;/code&gt; parameter of its defining &lt;code&gt;function&lt;/code&gt;. This allows Expressions to be interconnected in tree structures, in which inputs to each Expression in the tree are determined as the results of other Expressions in the tree.&lt;/p&gt;
    
    isModelLevelEvaluable = modelLevelEvaluable(Set(Element){})
    specializesFromLibrary("Performances::evaluations")
    owningMembership &lt;&gt; null and 
    owningMembership.oclIsKindOf(FeatureValue) implies
        let featureWithValue : Feature = 
            owningMembership.oclAsType(FeatureValue).featureWithValue in
        featuringType = featureWithValue.featuringType
    ownedMembership.selectByKind(ResultExpressionMembership)-&gt;
        forAll(mem | ownedFeature.selectByKind(BindingConnector)-&gt;
            exists(binding |
                binding.relatedFeature-&gt;includes(result) and
                binding.relatedFeature-&gt;includes(mem.ownedResultExpression.result)))</rdfs:comment>
    

    Prior OSLC artifact generation we need to figure out how to distinguish between normative documentation of metamodel objects (eClassifiers and eOperations) vs their OCL expressions in the original Ecore files.

  • Reported: SystemsModelingAPI 1.0a1 — Fri, 14 Jul 2023 10:11 GMT
  • Disposition: Closed; No Change — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Generate SysML and KerML Resource Shapes and Vocabularies from clean Ecore files

    As per discussion and resulting attachments in SYSMOAS_-3, SysML and KerML Resource Shapes and Vocabularies are now being generated from OCL-clean Ecore files, hence this issue is no more relevant and should be closed with No Change

  • Updated: Sat, 19 Jul 2025 19:07 GMT

Query conformance and derived properties

  • Status: closed  
  • Source: International Business Machines ( Mr. Eran Gery)
  • Summary:

    it is unclear if queryConformace implies derivedProperties conformance. In other words, does the query service provider need to support derived properties or not.

  • Reported: SystemsModelingAPI 1.0a1 — Mon, 28 Aug 2023 13:57 GMT
  • Disposition: Resolved — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Add clarification on QueryConformance and DerivedPropertyConformance

    Section 2 (Conformance) already states the following for DerivedPropertyConformance.

    In order to demonstrate Derived Property Conformance, a service provider must do the following when ProjectDataVersioningService.createCommit operation is invoked.
    1. Compute or verify all derived properties for Element data that is created or updated in the commit
    2. Include the derived properties in the response, i.e. DataVersion.payload should include derived properties for Element data.

    Section 2 (Conformance) already states the following for QueryConformance.

    A Service Provider must implement all the operations in the Query Service, and demonstrate that the implementation successfully passes all the QueryService Conformance Test Cases (see Section A.4) and Cross-Cutting Conformance Test Cases

    This proposal adds a supporting text under QueryConformance in section 2. This supporting text is available in the Revised Text field of this proposal.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

Branches are mutable

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    says in the standard "Branches are immutable", no they are mutable... can change the head subsequently

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 19 Apr 2024 17:00 GMT
  • Disposition: Resolved — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    *Update text in section 7.1.2 to state that Branches are mutable *

    The description for the Branch concept in Section 7.1.2 states the following:

    Branches are immutable.

    This is incorrect and a typo. Branches are mutable. The table on the same page shows that Branches are mutable.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

Read-only API providers

  • Status: closed  
  • Source: IncQuery Labs Ltd. ( Dr. Gábor Bergmann)
  • Summary:

    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.
  • Reported: SystemsModelingAPI 1.0b2 — Fri, 7 Jun 2024 12:01 GMT
  • Disposition: Resolved — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Adding read-only API interfaces

    • Normative Machine Readable Documents are updated to reflect which of the API operations are read only, by applying the UML metaproperty "isQuery" to them, and by pulling them up to newly created and exclusively read-only superinterfaces of the original PIM service interfaces.
    • Section 7.2 "API Services" reflect these model changes in Tables and Diagrams, so that a human reading the standard text is also informed of the subset of operations that are read only.
    • Section 2 "Conformance" is expanded to discuss Service Providers that only expose the read-only fragment of a Service.
  • Updated: Sat, 19 Jul 2025 19:07 GMT

DataVersion.identity multiplicity

  • Status: closed  
  • Source: IncQuery Labs Ltd. ( Dr. Gábor Bergmann)
  • Summary:

    From Tim Weilkiens <tim.weilkiens@oose.de>

    I got the following question from someone who does some experiments with the API:

    Here is an excerpt from the SysML v2 API specification:

    > For creating new Data, CommitRequest.change should include a DataVersion where DataVersion.payload includes the Data being created and DataVersion.identity is not specified.

    It says that DataVersion.identity must not be specified when creating new data.

    However, how can one commit new data with multiple elements that reference each other, if we cannot provide IDs to the elements that will allow each of them to be referenced from other elements via its ID?

    As a side note, it has been noticed that the Juypter notebook support for SysMLv2 in the SysML release does specify the “identity” during the creation of new data, when it publishes a model via “%publish …”. This has been verified by using an HTTP sniffer to sniff the POST command that was send

    Note: the PIM spec also says something similar

    > (1) Creating Data - Commit.change should include a DataVersion record with DataVersion.payload populated with the Data being created. DataVersion.identity is not provided, thereby indicating that a new DataIdentity needs to be created in the new commit.

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 10 May 2024 14:02 GMT
  • Disposition: Resolved — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Clarify DataVersion.identity multiplicity when creating element

    Makes data element identity optional rather than forbidden in case of new element creation, in order to accommodate the use case where the client has pre-generated identifiers for new elements. This is expected when multiple elements are affected by a change, and some elements may establish references to the newly created element, necessitating a way for the Commit to internally reference the newly created element.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

The SysML OSLC 3.0 API should reference OASIS vocabulary and constraint specifications instead of copying them in a zip file


The OASIS OSLC SysML vocabulary uses namespace: http://open-services.net/ns/sysmlv2#.

  • Key: SYSMOAS_-2
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    This namespace will be published at http://open-services.net/ns and will provide content negotiation for tools to be able to access the vocabulary and constraints in various RDF resource representations.

    All OSLC domain specifications use an open-services.net namespace, e.g., http://open-services.net/ns/am#. The same namespace is used for vocabulary terms and shapes for consistency, and to support navigation to specific sections in the vocabulary and constraints documents for elements of the namespace. The namespaces URLs also provide machine readable access to the RDF resources for use by tools.

    RDF namespaces can include version identifiers, but for OSLC integration standards, the OSLC-OP recommends against inclusion of version identifiers as that introduces integration incompatibilities as the standards evolve.

    The section OSLC 3.0 API section in Systems Modeling Application Programming Interface (API) and Services will need to be updated to refer to the correct namespace.

  • Reported: SystemsModelingAPI 1.0b1 — Fri, 5 Apr 2024 17:37 GMT
  • Disposition: Resolved — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    OSLC Vocabulary and Constraint namespace URIs should be updated per OMG requirements

    The OSLC Vocabulary and Constraint specifications are generated for KerML 1.0 and SysML 2.0 meta-models, and used in OSLC PSM of the Systems Modeling API and Services 1.0 specification. The OSLC Vocabulary and Constraint specifications for SysML 2.0 will include KerML 1.0 entities.

    This proposal provides the updated namespace URI patterns for OSLC Vocabulary and Constraints, as below.

    OSLC Vocabulary and Constraint namespace URIs for KerML 1.0

    OSLC Vocabulary namespace URI for KerML should conform to the following pattern : http://www.omg.org/spec/KerML/<version>/vocabulary#

    OSLC Constraint namespace URI for KerML should confirm to the following pattern: http://www.omg.org/spec/KerML/<version>/shapes#

    OSLC Vocabulary and Constraint namespace URIs for SysML 2.0

    OSLC Vocabulary namespace URI for SysML should conform to the following pattern : http://www.omg.org/spec/SysML/<version>/vocabulary#

    OSLC Constraint namespace URI for SysML should conform to the following pattern: http://www.omg.org/spec/SysML/<version>/shapes#

    In all the patterns above, <version> is the date timestamp when the OSLC vocabulary and namespace documents are generated from the KerML 1.0 and SysML 2.0 meta-models.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

The OSLC SysML v2 vocabulary, like the JSON schema, is standalone, merges KerML into SysML v2 XMI and does not import or specialize KerML

  • Key: SYSMOAS_-1
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    This is perhaps not an issue and may require no action other than acknowledging that it is being done, and isn’t formally following KerML semantics.

    If this is not acceptable, then we can generate the OSLC SysML v2 vocabulary to import and specialize KerML. That would add some additional work and redundancy, but could be done.

    If this is adopted, then there is no reason for the OSLC 3.0 API to define the KerML vocabulary and constraints, hence the reason it is not include in #1 above.

  • Reported: SystemsModelingAPI 1.0b1 — Fri, 5 Apr 2024 17:38 GMT
  • Disposition: Closed; No Change — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    OSLC Vocabulary and Constraints should be generated using the same approach followed in FTF1

    OSLC Vocabulary and Constraints should be generated from KerML 1.0 and SysML 2.0 meta-models using the same approach followed in FTF1, except for the updated namespace URIs to be used (SYSMOAS_-2).

    This issue should be closed with no changes.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

Provide details on deleting a project that has commits with data

  • Key: SYSMOAS_-5
  • Status: closed  
  • Source: InterCAX ( Dr. Manas Bajaj)
  • Summary:

    The beta spec should provide details on deleting a project that has commits with data.

    ProjectService in the PIM includes an operation "deleteProject" to delete a project. An equivalent endpoint is available in the REST/HTTP PSM (DELETE /projects/

    {projectId}

    ).

    However the specification should provide details, including recommended practices on what happens to the contents of a project and project usages when a project is deleted.

    Note that authorization (permissions) are outside the scope of the specification but related to this action.

  • Reported: SystemsModelingAPI 1.0a1 — Tue, 20 Jun 2023 15:09 GMT
  • Disposition: Resolved — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Updating documentation for ProjectService.deleteProject(..)

    This proposal provides a new description for ProjectService.deleteProject(...) operation in the PIM (Section 7.2.1, Table 6).

    The last proposal on for this issue was: https://issues.omg.org/browse/SYSMOAS_-81. It had a Precondition 2 that a project cannot be deleted if any of its owned elements are being used in another project.

    This new proposal removes that precondition and adds a general recommendation, based on the joint discussion on the proposal. See the Revised Text for details.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

Develop Conformance Test Suite for OSLC PSM

  • Key: SYSMOAS_-4
  • Status: closed  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    The goal of this task is to develop conformance test cases for the OSLC PSM of the Systems Modeling API and Services. Annex A of the specification includes Conformance Test Suite for the PIM of the API & Services. API & Services Providers and Consumers will generally conform to the individual PSMs, even though PIM-level conformance is allowed. See Section 2 (Conformance) for details. Hence, the specification should provide a Conformance Test Suite for the OSLC PSM.

  • Reported: SystemsModelingAPI 1.0a1 — Fri, 12 May 2023 23:17 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

Develop REST/HTTP PSM Conformance Test Suite for Project endpoints

  • Status: closed  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    Description - The goal of this issue is to develop conformance test suite for Project endpoints in the REST/HTTP PSM. This includes the following endpoints:
    1. GET /projects
    2. POST /projects
    3. GET /projects/

    {projectId}
    4. PUT /projects/{projectId}

    5. DELETE /projects/

    {projectId}

    Other details:
    1. Tests should be defined for each endpoint individually.
    2. Both positive and negative scenarios should be tested for each endpoint.
    3. Each test must include setup, test, and tear down steps.
    4. Tests will be written in Java using the JUnit framework (widely adopted).

  • Reported: SystemsModelingAPI 1.0a1 — Sat, 14 Oct 2023 21:39 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Deferred to RTF

    The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

Add examples for creating, updating, and deleting elements in the OpenAPI spec for REST/HTTP PSM

  • Key: SYSMOAS_-6
  • Status: closed  
  • Source: InterCAX ( Dr. Manas Bajaj)
  • Summary:

    The POST projects/

    {projectId}

    /commits endpoint in the OpenAPI spec for REST/HTTP PSM includes examples for creating elements (ElementCommitRequest), relationships (RelationshipCommitRequest), project usages (ProjectUsageCommitRequest), and others. See the attached screenshot. There is also an example (DeleteCommitRequest) that shows the commit request body when elements are to be deleted.

    It will help to add specific examples (as below) that provide details of Commit.change when elements are to be created, updated, or deleted.

    • ElementCreateCommitRequest
    • ElementUpdateCommitRequest
    • ElementDeleteCommitRequest
  • Reported: SystemsModelingAPI 1.0a1 — Tue, 20 Jun 2023 19:58 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT
  • Attachments:

Develop REST/HTTP PSM Conformance Test Suite for Commit endpoints

  • Status: closed  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    Description - The goal of this issue is to develop conformance test suite for the Commit endpoints in the REST/HTTP PSM. This includes the following endpoints:

    1. GET /projects/

    {projectId}
    /commits
    2. GET /projects/{projectId}

    /commits/

    {commitId}
    3. POST /projects/{projectId}
    /commits
    4. GET /projects/{projectId}/commits/{commitId}

    /changes
    5. GET /projects/

    {projectId}

    /commits/

    {commitId}

    /changes/

    {changeId}

    Other details:
    1. Tests should be defined for each endpoint individually.
    2. Both positive and negative scenarios should be tested for each endpoint.
    3. Each test must include setup, test, and tear down steps.
    4. Tests will be written in Java using the JUnit framework (widely adopted).

  • Reported: SystemsModelingAPI 1.0a1 — Sat, 14 Oct 2023 21:40 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

Develop REST/HTTP PSM Conformance Test Suite for Element and Relationship endpoints

  • Status: closed  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    The goal of this issue is to develop conformance test suite for the Element and Relationship endpoints in the REST/HTTP PSM. This includes the following endpoints:

    1. GET /projects/

    {projectId}/commits/{commitId}
    /elements
    2. GET /projects/{projectId}

    /commits/

    {commitId}/elements/{elementId}
    3. GET /projects/{projectId}
    /commits/{commitId}

    /roots
    4. GET /projects/

    {projectId}/commits/{commitId}
    /elements/ {elementId}
    /projectUsage
    5. GET /projects/{projectId}

    /commits/

    {commitId}

    /elements/

    {relatedElementId}

    /relationships

    Other details:
    1. Tests should be defined for each endpoint individually.
    2. Both positive and negative scenarios should be tested for each endpoint.
    3. Each test must include setup, test, and tear down steps.
    4. Tests will be written in Java using the JUnit framework (widely adopted).

  • Reported: SystemsModelingAPI 1.0a1 — Sat, 14 Oct 2023 21:41 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

Develop REST/HTTP PSM Conformance Test Suite for Branch endpoints

  • Status: closed  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    The goal of this issue is to develop conformance test suite for the Branch endpoints in the REST/HTTP PSM. This includes the following endpoints:

    1. GET /projects/

    {projectId}
    /branches
    2. GET /projects/{projectId}

    /branches/

    {branchId}
    3. POST /projects/{projectId}
    /branches
    4. DELETE /projects/{projectId}/branches/{branchId}

    Other details:
    1. Tests should be defined for each endpoint individually.
    2. Both positive and negative scenarios should be tested for each endpoint.
    3. Each test must include setup, test, and tear down steps.
    4. Tests will be written in Java using the JUnit framework (widely adopted).

  • Reported: SystemsModelingAPI 1.0a1 — Sat, 14 Oct 2023 21:41 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

Develop REST/HTTP PSM Conformance Test Suite for Tag endpoints

  • Status: closed  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    The goal of this issue is to develop conformance test suite for the Tag endpoints in the REST/HTTP PSM. This includes the following endpoints:

    1. GET /projects/

    {projectId}
    /tags
    2. GET /projects/{projectId}

    /tags/

    {tagId}
    3. POST /projects/{projectId}
    /tags
    4. DELETE /projects/{projectId}/tags/{tagId}

    Other details:
    1. Tests should be defined for each endpoint individually.
    2. Both positive and negative scenarios should be tested for each endpoint.
    3. Each test must include setup, test, and tear down steps.
    4. Tests will be written in Java using the JUnit framework (widely adopted).

  • Reported: SystemsModelingAPI 1.0a1 — Sat, 14 Oct 2023 21:41 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

Develop REST/HTTP PSM Conformance Test Suite for Query endpoints

  • Status: closed  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    The goal of this issue is to develop conformance test suite for the Query endpoints in the REST/HTTP PSM. This includes the following endpoints:

    1. GET /projects/

    {projectId}
    /queries
    2. GET /projects/{projectId}

    /queries/

    {queryId}
    3. POST /projects/{projectId}
    /queries
    4. PUT /projects/{projectId}/queries/{queryId}

    5. DELETE /projects/

    {projectId}
    /queries/ {queryId}
    6. GET /projects/{projectId}

    /queries/

    {queryId}

    /results
    7. GET /projects/

    {projectId}/queries/query-results
    8. POST /projects/{projectId}

    /queries/query-results
    Other details:
    1. Tests should be defined for each endpoint individually.
    2. Both positive and negative scenarios should be tested for each endpoint.
    3. Each test must include setup, test, and tear down steps.
    4. Tests will be written in Java using the JUnit framework (widely adopted).

  • Reported: SystemsModelingAPI 1.0a1 — Sat, 14 Oct 2023 21:42 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

Develop REST/HTTP PSM Conformance Test Suite for Meta endpoints

  • Status: closed  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    The goal of this issue is to develop conformance test suite for the Meta endpoints in the REST/HTTP PSM. This includes the following endpoints:
    1. GET /meta/datatypes
    2. GET /meta/datatypes/

    {datatypeId}

    Other details:
    1. Tests should be defined for each endpoint individually.
    2. Both positive and negative scenarios should be tested for each endpoint.
    3. Each test must include setup, test, and tear down steps.
    4. Tests will be written in Java using the JUnit framework (widely adopted).

  • Reported: SystemsModelingAPI 1.0a1 — Sat, 14 Oct 2023 21:43 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

Develop REST/HTTP PSM Conformance Test Suite for Diff and Merge endpoints

  • Status: closed  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    The goal of this issue is to develop conformance test suite for the Diff and Merge endpoints in the REST/HTTP PSM. This includes the following endpoints:
    1. GET /projects/

    {projectId}/commits/{compareCommitId}/diff
    2. GET /projects/{projectId}

    /branches/

    {targetBranchId}

    /merge
    Other details:
    1. Tests should be defined for each endpoint individually.
    2. Both positive and negative scenarios should be tested for each endpoint.
    3. Each test must include setup, test, and tear down steps.
    4. Tests will be written in Java using the JUnit framework (widely adopted).

  • Reported: SystemsModelingAPI 1.0a1 — Sat, 14 Oct 2023 21:43 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

Greater Scope

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    there is nothing in this standard specifically about SysML or KerML... which is good... I would suggest that the Scope be rewritten and the standard be called "Versioning" or something like that... there is greater use of this standard inside modeling (i.e. legacy modeling language can use this as well) as well as outside of modeling (i.e. anything that can serialized can use this standard to have versions of that serialization)... so would suggest the Scope be changed to say

    "The purpose of this standard is to specify the Versioning Application Programming Interface (API) and Services that provide standard services to access, navigate, and operate on serialized elements and in particular can be used for modeling languages."

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 12 Apr 2024 13:11 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

Not everything needs to be a UUID

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    one needs Unique IDs (UID) but not UUID (Universally Unique ID) for most things in this standard,
    and would suggest that Record be changed and that it would have

    id : UID

    {readOnly, id}

    also adding

    {id}

    here... and make Project (which is the only thing I can see that needs a UUID)

    Project
    id : UUID

    {readOnly,id, redefines id}
  • Reported: SystemsModelingAPI 1.0b2 — Fri, 12 Apr 2024 13:21 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

What Language is are these models in

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    it does not specify what language these models are in... UML, SysML, KerML, SysML2, MOF?...
    it makes a difference in, e.g., interpreting the multiplicities... I would suggest doing the models in MOF and making everything explicit (e.g. multiplicities)

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 12 Apr 2024 13:23 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

other attributes in Record not needed

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    resourceIdentifier is not needed in the record (although would be interesting)... statements about that in another issue... but remove alias, humanidentifier... and description... for example DataVersion and DataIdentity does not need a description... would suggest creating a NamedRecord where name and description are added into that and have Project, Commit, CommitReference, Query specialize that

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 12 Apr 2024 13:27 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

IRI needs defintion

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    IRI standard is referenced, but that does not give a precise definition of how to use it, especially if one wants to be interoperable among implementations... would suggest...

    Standard ProjectI IRI:

    {protocol}://{serverIRI}/projects/{projectId}/commits/{commitId}/elements/{elementId}{protocol}

    ://

    {serverIRI}

    /projects/

    {projectId}

    /commits/

    {commitId}

    the first is for Elements and the second is for externally referenced projects

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 19 Apr 2024 14:51 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

All Attributes and AssociationEnds are singular

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    all the standard modeling languages use the same convention as well as most modeling style guides... and so does KerML...

    all attributes and association ends are singular... the fact that they can be plural is taken care of by multiplicity

    would suggest this convention be followed

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 19 Apr 2024 14:53 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

many of the association ends are wrapped

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    the models used in the standard have the association ends wrapped so you can't see them... suggest that they be unwrapped and
    shown on one line

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 19 Apr 2024 14:55 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

all multiplicities explicity

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    there are some multiplicities not shown... since there is no specification in the standard about what modeling language the diagram is in... do not know how to interpret these missing multiplicities... would suggest explicitly showing all multiplicities in the diagram

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 19 Apr 2024 14:57 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

ownership dots

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    would suggest using either MOF or UML to show diagrams and to employ ownership dots... note that KerML is specified this way

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 19 Apr 2024 14:58 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

visibility needs to be consistent

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    1. Fig 6 visibility is not shown on all the attributes, needs to be consistent
    2. Fig 7 visibility is not shown on all the attributes, needs to be consistent

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 19 Apr 2024 15:01 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

JoinOperator and Operator are enumerations

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    1. Fig. 7, Operator and JoinOperator need to be shown as enumerations, with literal compartments

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 19 Apr 2024 15:03 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

inconsistency with queries

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    Fig. 7 queries (which should be a singular, query) is an associationend… whereas in fig. 5 queries is shown as an attribute (needs to be removed in fig. 5)

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 19 Apr 2024 15:04 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

Fig. 7 orderBy should be {ordered}

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    Fig. 7 orderBy should be

    {ordered}
  • Reported: SystemsModelingAPI 1.0b2 — Fri, 19 Apr 2024 15:05 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

value being 1..*

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    need to explain in the standard why value is 1..* (presuming because of the "in" operator, but the semantics of that is not specified)

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 19 Apr 2024 15:07 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

specification example

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    Need at least one example of a specification for an ExternalRelationship...

    also need to define what it means if the specification is null (i.e. presume this means that one is referring to the entire element, so this is the way one specifies that an element in a model is really a remote element from another model)... this needs to be specified

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 19 Apr 2024 15:10 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

specification and language need to be {ordered}

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    specification and language need to be

    {ordered}

    ... this will have the same kind of semantics as
    Opaque/Expression or Behavior from UML (see fig 8.2 and its description in UML 2.5.1)

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 19 Apr 2024 15:13 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

over specification of the API

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    Most of the API is over specified… as an example, getExternalRelationship has that you need to give it a Project… but you do not need a Project, you only need a ProjectId… so for this one example…
    getExternalRelationships(project:Project,commit:Commit):ExternalRelationship[0..*] should be
    getExternalRelationships(projectId:UID,commitId:UID):ExternalRelationship[0..*]

    this would follow the Interface Segregation Principle (“no client should be forced to depend on methods it does not use”)… most of the API is over specified in this way

    I have a reworked model at https://material.elparazim.com/SysMLv2API/

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 19 Apr 2024 15:23 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

should have defaults consistent in the parameters

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    the standard for functions should be, e.g.

    getExternalRelationships(projectId:UUID, branchId:UID[0..1],commitId:UID[0..1]):ExternalRelationship[0..*]

    which means if a branchId is missing use the commitId, if commitId is missing then use the head of the branchId if it is there,
    otherwise, use the default Branch and its head of the project given
    many of the API operations need to be specified this way to be consistent

    I have a reworked model at https://material.elparazim.com/SysMLv2API/

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 19 Apr 2024 15:29 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

there needs to be a stament in the standard concerning how things are serialized

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    there needs to be a statement in the standard concerning how things are serialized...

    I have reworked the model here https://material.elparazim.com/SysMLv2API/ and used two stereotypes...
    <<NS>> and <<SID>> which stand for "No Serialization" and "Serialize Id (only)"
    I believe this leads to a full understand of what will come when one serializing something from
    the APi (also examples are given for this serialization(s))

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 19 Apr 2024 15:35 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

some attributes need to be {readOnly}


need attribute /usedProject

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    ProjectUsage needs a derived attribute “usedProject”

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 19 Apr 2024 16:40 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

OCL Constraints


multiplictiy change on Tag Commit

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    Two Tags should be able to be on the same Commit… need multiplicity change

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 19 Apr 2024 16:42 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

two branches can have the same head

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    Two Branches can have the same head (Commit) … need multiplicity change
    for example to start them off with the same set of elements

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 19 Apr 2024 16:43 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

navigation between DataVersion to DataIdentity

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    There should be a navigation between DataVersion to DataIdentity... presumably DataVersion knows about DataIdentity but not vice-versa

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 19 Apr 2024 16:44 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

multiplicity change between Project and DataVersion

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    Projects may have multiple DataVersions… change Multiplicity

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 19 Apr 2024 16:45 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

Need both an internal and external ProjectUsage

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    currently in the spec a ProjectUsage refers to a project that is also local on the system (Server)...
    there needs to be a way to reference a project (external) on another server...

    I have a reworked model at https://material.elparazim.com/SysMLv2API/

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 19 Apr 2024 16:49 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

Head on Branch should be multiplicity 0..1

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    Head on Branch should be multiplicity 0..1 ... when Branch is first created there is no commit

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 19 Apr 2024 16:47 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

Semantics of ProjectUsage needs to be defined

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    What does project usage mean?... I am presuming this comes from Cameo kind of idea about ProjectUsage... but what in this spec does it mean and what can one surmise about it

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 19 Apr 2024 16:51 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

need the commit for a project

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    "usage is the set of Project Usage records representing all other Projects being used by the given Project"… this does not work, need a particular commit for this

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 19 Apr 2024 16:53 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

Data needs to be reworked

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    Data does not need to be further refined in the standard (i.e. no need for Relationship and operations like getRelationshipsByRelatedElements)... these could be there for operations that specifically deal with KerML models...
    I would suggest if doing that there should be two sections to this standard or possibly two standards... one that deals with
    versioning... the other that is specific to the serialized model

    I have a reworked model at https://material.elparazim.com/SysMLv2API/

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 19 Apr 2024 16:56 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

previousCommits must be in the same project as the Commit

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    need OCL to specify... previousCommits must be in the same project as the Commit

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 19 Apr 2024 16:57 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

locking

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    does the standard want to deal with locking on versioning systems?

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 19 Apr 2024 17:02 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

scope on Query

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    not sure one needs scope here... how would it work?... needs documentation in the spec about its use and an example

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 19 Apr 2024 17:03 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

create and delete should not be on DataIdentity

  • Status: closed  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    since DataIdentity is in the scope of the whole project, one can have multiple Branches where this DataIdentity is created in different Commits in different branches... and deleted in different Commits in different Branches...

    so these cannot be associated with the DataIdentity... DataVersion's commit is where that information must be stored...

    one could however have an operation that takes a project and branch and DataIdentity... and computes the Creation and Deletion Times from this

  • Reported: SystemsModelingAPI 1.0b2 — Mon, 22 Apr 2024 13:43 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

getId() isn't implemented for realizations of Data

  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The spec says "Each realization of Data must implement the getId() operation that provides a valid UUID." but this doesn't seem to be the case

  • Reported: SystemsModelingAPI 1.0b2 — Thu, 9 May 2024 09:42 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

Data Identity attributes don't exist

  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    createAt and deleteAt attributes don't exist in the XMI.

  • Reported: SystemsModelingAPI 1.0b2 — Thu, 9 May 2024 09:46 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:07 GMT

Why does the spec say that Data Version.id is randomly generated

  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The spec says "Data Version.id is set to a new, randomly generated UUID for the specific Data Version record.". This seems a bit superfluous and probably is overspecified.

  • Reported: SystemsModelingAPI 1.0b2 — Thu, 9 May 2024 09:48 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:06 GMT

identifiedData does not exist

  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    the spec for project says "identifiedData is a derived attribute that is the set of Data Identity records corresponding to the Data contained in the project" but this doesn't seem to exist in xmi.

  • Reported: SystemsModelingAPI 1.0b2 — Thu, 9 May 2024 09:50 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:06 GMT

usage doesn't exist

  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The spec says "usage is the set of Project Usage records representing all other Projects being used by the given Project (Project Usage.usedProject)" but I can't see this in the xmi

  • Reported: SystemsModelingAPI 1.0b2 — Thu, 9 May 2024 09:52 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:06 GMT

why redefine owningProject for Branch

  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    the spec says "• owningProject is the project that owns the given branch" - this is a redefinition of owningProject on commitReference but I don't understand why it is needed.

  • Reported: SystemsModelingAPI 1.0b2 — Thu, 9 May 2024 10:09 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:06 GMT

why is "select" typed by string?

  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The spec says that "select is a list of properties of Data (or its realizations)" so why is it typed by string and not something stronger?

  • Reported: SystemsModelingAPI 1.0b2 — Thu, 9 May 2024 10:16 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:06 GMT

Constraint property and value typed by strings

  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    property is a property of Data (or its realizations)
    value is a list of primitive objects, such as String, Boolean, Integer, Double, and UUID

    so why are they both typed by string?

  • Reported: SystemsModelingAPI 1.0b2 — Thu, 9 May 2024 10:18 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:06 GMT

How to provide other properties of Project

  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    createProject( name : String, description : String [0..1] ) : Project

    how do we create other properties of Project inherited from Record?

  • Reported: SystemsModelingAPI 1.0b2 — Thu, 9 May 2024 10:20 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:06 GMT

Why do we need both project and commit as arguments in ElementNavigationService

  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    e.g. getElements( project : Project, commit : Commit ) : Element [0..*]

    commit references project so you don't need both.

  • Reported: SystemsModelingAPI 1.0b2 — Thu, 9 May 2024 10:24 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:06 GMT

updateQuery needs more explanation

  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The argument to the function updateQuery is a query - I don't understand what this means - it also seems to be different than how updateProject works.

  • Reported: SystemsModelingAPI 1.0b2 — Thu, 9 May 2024 10:32 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:06 GMT

Does mergeIntoBranch.resolution need to be typed by DataVersion?

  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    What happens if the resolution is that an identity is deleted?

  • Reported: SystemsModelingAPI 1.0b2 — Thu, 9 May 2024 10:29 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:06 GMT

How do ProjectUsages and DataVersions interact

  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    ProjectUsages are Data and so need to use the DataIdentity/DataVersion mechanism but none of this is mentioned in the descriptions of the functions. It also doesn't aay whether you can update a project usage to reference a different commit or

  • Reported: SystemsModelingAPI 1.0b2 — Thu, 9 May 2024 10:36 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:06 GMT

createCommit Element deletion rules are model-breaking

  • Status: closed  
  • Source: Dassault Systemes ( Mr. Tomas Vileiniskis)
  • Summary:

    Within ProjectDataVersioningService PIM-level service specifications createCommit service Element deletion rules state the following:

    When a DataIdentity is deleted in a commit, all its versions (DataVersion) are also deleted, and any references from other DataIdentity are also removed to maintain data integrity. In addition, for Element Data (KerML), deletion of an Element must also result in deletion of incoming Relationships.

    This seems to be model-breaking, especially in cases of ownership-based Relationships (e.g. OwningMembership, FeatureMembership). Example:

    Namespace – (OwningMembership Relationship) --> Package packA – (OwningMembership Relationship) --> PortDefinition portA.

    When deleting Package packA, according to the rule described, an incoming OwningMembership Relationship should be deleted as well. However, the outgoing OwningMembership Relationship pointing to PortDefinition portA would remain to exist in the model leaving portA floating without any owner (OwningMembership Relationship has no source, it has been deleted).

    Simply deleting outgoing Relationships in addition to incoming ones would also not help in this case, as the PortDefinition portA would also remain without any owner in the model.

    We need to take a closer look into various Relationship kinds and their semantics in order not to break the model when manipulating via API services.

  • Reported: SystemsModelingAPI 1.0b2 — Thu, 23 May 2024 12:32 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:06 GMT

The description of Commit.change-Deleting is not clear

  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Cory Casanave)
  • Summary:

    Statements about “deleting” data versions does not communicate the intent. DataVersions are immutable and should not be “deleted”. If the DataVersion for the deletion of an identity were to be deleted, there would be no record of the delete, and merge could not work.

    In 7.1.2 it is stated: “DataVersion.identity is unique among records listed in commit.versionedData and in Commit.change”

    Therefore, there cannot be a conflicting DataVersion for the same identity in the same commit, the deleting DataVersion must remain in the change set and can’t be “deleted”. The delete should not impact any previous commit, so no DataVersions should be deleted. However, the deleting DataVersion must not be in the derived “versionedData” set.

    The other consideration is the deletion of incoming references, as documented in SYSMOAS_-82. We suggest those constraints be removed until we have full constraint propagation in the API to ensure model consistency – it is an expensive operation that could break the model.

    Based on this issue and in SYSMOAS_-82. Clearer wording should be provided for “3) Deleting data” in table 3. Suggested wording is:

    3) Deleting Data - Commit.change should include a DataVersion record with DataVersion.payload not provided, thereby indicating deletion of DataIdentity in the new commit. DataVersion.identity should be populated with the DataIdentity that will be deleted in the new commit. When a DataIdentity is deleted in a commit, the DataVersion for that identity shall not be included in the derived versionedData relationship for that commit.

  • Reported: SystemsModelingAPI 1.0b2 — Mon, 3 Feb 2025 21:46 GMT
  • Disposition: Deferred — SystemsModelingAPI 1.0b3
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 19:06 GMT