Systems Modeling API and Services Avatar
  1. OMG Specification

Systems Modeling API and Services — Open Issues

  • Acronym: SystemsModelingAPI
  • Issues Count: 61
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
SYSMOAS11-63 Broken links on frontispiece SystemsModelingAPI 1.0b3 open
SYSMOAS11-61 createCommit Element deletion rules are model-breaking SystemsModelingAPI 1.0b2 open
SYSMOAS11-60 How do ProjectUsages and DataVersions interact SystemsModelingAPI 1.0b2 open
SYSMOAS11-62 The description of Commit.change-Deleting is not clear SystemsModelingAPI 1.0b2 open
SYSMOAS11-58 Does mergeIntoBranch.resolution need to be typed by DataVersion? SystemsModelingAPI 1.0b2 open
SYSMOAS11-57 Why do we need both project and commit as arguments in ElementNavigationService SystemsModelingAPI 1.0b2 open
SYSMOAS11-59 updateQuery needs more explanation SystemsModelingAPI 1.0b2 open
SYSMOAS11-55 Constraint property and value typed by strings SystemsModelingAPI 1.0b2 open
SYSMOAS11-54 why is "select" typed by string? SystemsModelingAPI 1.0b2 open
SYSMOAS11-56 How to provide other properties of Project SystemsModelingAPI 1.0b2 open
SYSMOAS11-51 identifiedData does not exist SystemsModelingAPI 1.0b2 open
SYSMOAS11-52 usage doesn't exist SystemsModelingAPI 1.0b2 open
SYSMOAS11-53 why redefine owningProject for Branch SystemsModelingAPI 1.0b2 open
SYSMOAS11-48 getId() isn't implemented for realizations of Data SystemsModelingAPI 1.0b2 open
SYSMOAS11-49 Data Identity attributes don't exist SystemsModelingAPI 1.0b2 open
SYSMOAS11-50 Why does the spec say that Data Version.id is randomly generated SystemsModelingAPI 1.0b2 open
SYSMOAS11-44 previousCommits must be in the same project as the Commit SystemsModelingAPI 1.0b2 open
SYSMOAS11-46 scope on Query SystemsModelingAPI 1.0b2 open
SYSMOAS11-47 create and delete should not be on DataIdentity SystemsModelingAPI 1.0b2 open
SYSMOAS11-45 locking SystemsModelingAPI 1.0b2 open
SYSMOAS11-42 need the commit for a project SystemsModelingAPI 1.0b2 open
SYSMOAS11-43 Data needs to be reworked SystemsModelingAPI 1.0b2 open
SYSMOAS11-41 Semantics of ProjectUsage needs to be defined SystemsModelingAPI 1.0b2 open
SYSMOAS11-39 Head on Branch should be multiplicity 0..1 SystemsModelingAPI 1.0b2 open
SYSMOAS11-40 Need both an internal and external ProjectUsage SystemsModelingAPI 1.0b2 open
SYSMOAS11-35 multiplictiy change on Tag Commit SystemsModelingAPI 1.0b2 open
SYSMOAS11-34 OCL Constraints SystemsModelingAPI 1.0b2 open
SYSMOAS11-36 two branches can have the same head SystemsModelingAPI 1.0b2 open
SYSMOAS11-38 multiplicity change between Project and DataVersion SystemsModelingAPI 1.0b2 open
SYSMOAS11-33 need attribute /usedProject SystemsModelingAPI 1.0b2 open
SYSMOAS11-37 navigation between DataVersion to DataIdentity SystemsModelingAPI 1.0b2 open
SYSMOAS11-30 should have defaults consistent in the parameters SystemsModelingAPI 1.0b2 open
SYSMOAS11-31 there needs to be a stament in the standard concerning how things are serialized SystemsModelingAPI 1.0b2 open
SYSMOAS11-32 some attributes need to be {readOnly} SystemsModelingAPI 1.0b2 open
SYSMOAS11-28 specification and language need to be {ordered} SystemsModelingAPI 1.0b2 open
SYSMOAS11-26 value being 1..* SystemsModelingAPI 1.0b2 open
SYSMOAS11-27 specification example SystemsModelingAPI 1.0b2 open
SYSMOAS11-29 over specification of the API SystemsModelingAPI 1.0b2 open
SYSMOAS11-22 visibility needs to be consistent SystemsModelingAPI 1.0b2 open
SYSMOAS11-24 inconsistency with queries SystemsModelingAPI 1.0b2 open
SYSMOAS11-23 JoinOperator and Operator are enumerations SystemsModelingAPI 1.0b2 open
SYSMOAS11-25 Fig. 7 orderBy should be {ordered} SystemsModelingAPI 1.0b2 open
SYSMOAS11-20 all multiplicities explicity SystemsModelingAPI 1.0b2 open
SYSMOAS11-18 All Attributes and AssociationEnds are singular SystemsModelingAPI 1.0b2 open
SYSMOAS11-19 many of the association ends are wrapped SystemsModelingAPI 1.0b2 open
SYSMOAS11-21 ownership dots SystemsModelingAPI 1.0b2 open
SYSMOAS11-15 What Language is are these models in SystemsModelingAPI 1.0b2 open
SYSMOAS11-13 Greater Scope SystemsModelingAPI 1.0b2 open
SYSMOAS11-16 other attributes in Record not needed SystemsModelingAPI 1.0b2 open
SYSMOAS11-17 IRI needs defintion SystemsModelingAPI 1.0b2 open
SYSMOAS11-14 Not everything needs to be a UUID SystemsModelingAPI 1.0b2 open
SYSMOAS11-9 Develop REST/HTTP PSM Conformance Test Suite for Tag endpoints SystemsModelingAPI 1.0a1 open
SYSMOAS11-12 Develop REST/HTTP PSM Conformance Test Suite for Diff and Merge endpoints SystemsModelingAPI 1.0a1 open
SYSMOAS11-11 Develop REST/HTTP PSM Conformance Test Suite for Meta endpoints SystemsModelingAPI 1.0a1 open
SYSMOAS11-10 Develop REST/HTTP PSM Conformance Test Suite for Query endpoints SystemsModelingAPI 1.0a1 open
SYSMOAS11-8 Develop REST/HTTP PSM Conformance Test Suite for Branch endpoints SystemsModelingAPI 1.0a1 open
SYSMOAS11-7 Develop REST/HTTP PSM Conformance Test Suite for Element and Relationship endpoints SystemsModelingAPI 1.0a1 open
SYSMOAS11-6 Develop REST/HTTP PSM Conformance Test Suite for Commit endpoints SystemsModelingAPI 1.0a1 open
SYSMOAS11-3 Develop Conformance Test Suite for OSLC PSM SystemsModelingAPI 1.0a1 open
SYSMOAS11-5 Develop REST/HTTP PSM Conformance Test Suite for Project endpoints SystemsModelingAPI 1.0a1 open
SYSMOAS11-4 Add examples for creating, updating, and deleting elements in the OpenAPI spec for REST/HTTP PSM SystemsModelingAPI 1.0a1 open

Issues Descriptions

Broken links on frontispiece

  • Status: open  
  • Source: Fondazione Bruno Kessler ( Tommaso Fonda)
  • Summary:

    The following links on the very first page of the PDF as released on the Github SysML v2 Release repository are broken:
    Standard document URL
    Machine Readable File(s)
    Normative (all links from the third to the last)

  • Reported: SystemsModelingAPI 1.0b3 — Mon, 11 Aug 2025 07:42 GMT
  • Updated: Mon, 11 Aug 2025 12:52 GMT

createCommit Element deletion rules are model-breaking

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

How do ProjectUsages and DataVersions interact

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

The description of Commit.change-Deleting is not clear

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

Does mergeIntoBranch.resolution need to be typed by DataVersion?


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

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

updateQuery needs more explanation

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

Constraint property and value typed by strings

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

why is "select" typed by string?

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

How to provide other properties of Project

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

identifiedData does not exist

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

usage doesn't exist

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

why redefine owningProject for Branch

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

getId() isn't implemented for realizations of Data

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

Data Identity attributes don't exist


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

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

previousCommits must be in the same project as the Commit


scope on Query

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

create and delete should not be on DataIdentity

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT


need the commit for a project

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

Data needs to be reworked

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

Semantics of ProjectUsage needs to be defined

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

Head on Branch should be multiplicity 0..1





two branches can have the same head

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

multiplicity change between Project and DataVersion



navigation between DataVersion to DataIdentity

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

should have defaults consistent in the parameters

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

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

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT


specification and language need to be {ordered}

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

value being 1..*

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

specification example

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

over specification of the API

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

visibility needs to be consistent

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

inconsistency with queries

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

JoinOperator and Operator are enumerations



all multiplicities explicity

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

All Attributes and AssociationEnds are singular

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

many of the association ends are wrapped

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

ownership dots

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

What Language is are these models in

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

Greater Scope

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

other attributes in Record not needed

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

IRI needs defintion

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

Not everything needs to be a UUID

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

Develop REST/HTTP PSM Conformance Test Suite for Tag endpoints

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

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

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

Develop REST/HTTP PSM Conformance Test Suite for Meta endpoints

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

Develop REST/HTTP PSM Conformance Test Suite for Query endpoints

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

Develop REST/HTTP PSM Conformance Test Suite for Branch endpoints

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

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

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

Develop REST/HTTP PSM Conformance Test Suite for Commit endpoints

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

Develop Conformance Test Suite for OSLC PSM

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

Develop REST/HTTP PSM Conformance Test Suite for Project endpoints

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT

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

  • Status: open  
  • 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
  • Updated: Fri, 20 Jun 2025 21:11 GMT
  • Attachments: