1. OMG Mailing List
  2. Systems Modeling API and Services 1.0 FTF 2

Open Issues

  • Issues not resolved
  • Name: sysmod-api-ftf
  • Issues Count: 102

Issues Summary

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

Issues Descriptions

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

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

    OSLC-OP is working on publishing an OASIS multi-part specification:
    OSLC Systems Modeling Language Version 2.0. Part 1: Specification
    OSLC Systems Modeling Language Version 2.0. Part 2: Vocabulary
    OSLC Systems Modeling Language Version 2.0. Part 3: Constraints
    OSLC Systems Modeling Language Version 2.0. Part 4: Machine Readable Vocabulary Terms
    OSLC Systems Modeling Language Version 2.0. Part 4: Machine Readable Constraints
    This is the same as other OSLC servers and RDF vocabularies, and that Systems Modeling Application Programming Interface (API) and Services can reference these documents instead of directly including copies in the OMG specification zip file. The vocabulary and constraints would also be published on open-services.net and accessed using the namespace URL.

    The Part 1: Specification describes the conformance clauses an OSLC SysML server meets. It references OMG Systems Modeling Language. https://www.omg.org/spec/SysML/ for all information on SysML. It is a standard for an OSLC server supporting SysML, with vocabulary terms providing an RDF representation of the normative OMG SysML v2 XMI.

    See file:///Users/jamsden/Developer/OSLC/oslc-op/oslc-specs/specs/am/architecture-management-spec.html which is a similar specification following the same pattern.

    I expect to have a draft project specification published by OASIS soon.

  • Reported: SystemsModelingAPI 1.0b1 — Fri, 5 Apr 2024 17:35 GMT
  • Updated: Tue, 11 Jun 2024 16:48 GMT
  • Attachments:

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

  • Key: SYSMOAS_-2
  • Status: open  
  • 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
  • Updated: Tue, 11 Jun 2024 16:48 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: open  
  • 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
  • Updated: Tue, 11 Jun 2024 16:46 GMT

Read-only API providers

  • Status: open  
  • 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
  • Updated: Sun, 9 Jun 2024 21:10 GMT

DataVersion.identity multiplicity

  • Status: open  
  • 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
  • Updated: Wed, 29 May 2024 00:12 GMT

Description of deletion in createCommit row seems wrong

  • Status: open  
  • 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
  • Updated: Wed, 29 May 2024 00:12 GMT

Provide details on deleting a project that has commits with data

  • Key: SYSMOAS_-5
  • Status: open  
  • 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
  • Updated: Sun, 26 May 2024 23:53 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: Thu, 23 May 2024 12:33 GMT

derived relation without a specification of how it is derived

  • Key: SYSMOAS_-7
  • Status: open  
  • 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
  • Updated: Sun, 19 May 2024 16:47 GMT

humanIdentifier attribute is missing in API JSON schema for Commit entity

  • Key: SYSMOAS_-8
  • Status: open  
  • 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
  • Updated: Tue, 14 May 2024 00:13 GMT
  • Attachments:

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: Thu, 9 May 2024 10:36 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: Thu, 9 May 2024 10:32 GMT

Does mergeIntoBranch.resolution need to be typed by DataVersion?

  • Status: open  
  • 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
  • Updated: Thu, 9 May 2024 10:29 GMT

changeTypes argument not in the table

  • Status: open  
  • 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
  • Updated: Thu, 9 May 2024 10:26 GMT

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: Thu, 9 May 2024 10:24 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: Thu, 9 May 2024 10:20 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: Thu, 9 May 2024 10:18 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: Thu, 9 May 2024 10:16 GMT

Does Project own queries


Definition ExternalData is unclear

  • Status: open  
  • 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
  • Updated: Thu, 9 May 2024 10:13 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: Thu, 9 May 2024 10:09 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: Thu, 9 May 2024 09:52 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: Thu, 9 May 2024 09:50 GMT

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: Thu, 9 May 2024 09:48 GMT

Data Identity attributes don't exist


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: Thu, 9 May 2024 09:42 GMT

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

  • Status: open  
  • 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
    • Add Apache License Version 2.0 comment headers to the .ttl files.
    • Add OASIS copyright notice.
    • 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](file:///Users/jamsden/Developer/OSLC/oslc-op/oslc-specs/specs/core/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 SysML v2 non-versioned namespace for the vocabulary terms: @prefix oslc_sysmlv2: <http://www.omg.org/spec/sysmlv2/2.0#> .
    • Set rdfs:comment in the vocab file to be the first paragraph in the eCore description with the markup stripped out.
    • Fix ShapeChecker errors

    The resource shape constraint updates include:

    • Used updated SysML.ecore and KerML.ecore source files for generating shapes files.
    • Add the ResourceShapeConstraints element to the shapes.ttl file
    • Generate Turtle intead of RDF/XML
    • Add Apache License Version 2.0 comment headers to the .ttl files.
    • Add OASIS copyright notice.
    • Add inherited oalc_am:Resource properties to the shapes for KerML and SysML v2 Element
    • Update the versioned namespace for the resource shape constraints: @prefix : <https://www.omg.org/spec/SysML/shapes/20240801#> .
    • Set dcterms:description in the shapes files to the first paragraph in the eCore description (retaining the markup).
    • Separate the class name prefix from the attribute name with _ for the ResourceShapes
    • Add cardinality, range and valueType to shape properties.
    • Fixed ShapeChecker errors
  • Reported: SystemsModelingAPI 1.0b2 — Wed, 1 May 2024 14:30 GMT
  • Updated: Thu, 2 May 2024 17:58 GMT
  • Attachments:

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: Tue, 30 Apr 2024 14:43 GMT

how is /versionData calculated

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

    the standard should specify how the commits (and previousCommit(s) ) are transverse to get all the elements

  • Reported: SystemsModelingAPI 1.0b2 — Fri, 19 Apr 2024 16:48 GMT
  • Updated: Tue, 23 Apr 2024 09:33 GMT

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: Tue, 23 Apr 2024 09:20 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: Mon, 22 Apr 2024 16:09 GMT

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: Mon, 22 Apr 2024 16:07 GMT


Branches are mutable


wrong multiplicity on DataVersion

  • Status: open  
  • 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
  • Updated: Mon, 22 Apr 2024 16:06 GMT

previousCommits must be in the same project as the Commit


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: Mon, 22 Apr 2024 16:05 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: Mon, 22 Apr 2024 16:05 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: Mon, 22 Apr 2024 16:05 GMT


Head on Branch should be multiplicity 0..1


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: Mon, 22 Apr 2024 16:03 GMT

multiplictiy change on Tag Commit





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: Mon, 22 Apr 2024 16:01 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: Mon, 22 Apr 2024 16:01 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: Mon, 22 Apr 2024 16:01 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: Mon, 22 Apr 2024 16:01 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: Mon, 22 Apr 2024 16:00 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: Mon, 22 Apr 2024 15:59 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: Mon, 22 Apr 2024 15:59 GMT

JoinOperator and Operator are enumerations


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: Mon, 22 Apr 2024 15:58 GMT

created needs to be consistent

  • Status: open  
  • 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
  • Updated: Mon, 22 Apr 2024 15:58 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: Mon, 22 Apr 2024 15:58 GMT

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: Mon, 22 Apr 2024 15:57 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: Mon, 22 Apr 2024 15:57 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: Mon, 22 Apr 2024 15:57 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: Mon, 22 Apr 2024 15:56 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, 12 Apr 2024 19:31 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, 12 Apr 2024 19:30 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, 12 Apr 2024 19:30 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, 12 Apr 2024 19:29 GMT

Develop REST/HTTP PSM Conformance Test Suite for Query endpoints

  • Key: SYSMOAS-31
  • 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: Tue, 9 Apr 2024 23:04 GMT

Develop REST/HTTP PSM Conformance Test Suite for Tag endpoints

  • Key: SYSMOAS-30
  • 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: Tue, 9 Apr 2024 23:04 GMT

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

  • Key: SYSMOAS-33
  • 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: Tue, 9 Apr 2024 23:04 GMT

Develop REST/HTTP PSM Conformance Test Suite for Meta endpoints

  • Key: SYSMOAS-32
  • 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: Tue, 9 Apr 2024 23:04 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: Tue, 9 Apr 2024 23:04 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: Tue, 9 Apr 2024 23:04 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: Tue, 9 Apr 2024 23:04 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: Tue, 9 Apr 2024 23:04 GMT

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

  • Key: SYSMOAS-28
  • 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: Tue, 9 Apr 2024 23:04 GMT

Develop REST/HTTP PSM Conformance Test Suite for Branch endpoints

  • Key: SYSMOAS-29
  • 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: Tue, 9 Apr 2024 23:04 GMT

Develop REST/HTTP PSM Conformance Test Suite for Commit endpoints

  • Key: SYSMOAS-27
  • 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: Tue, 9 Apr 2024 23:04 GMT

Develop REST/HTTP PSM Conformance Test Suite for Project endpoints

  • Key: SYSMOAS-26
  • 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: Tue, 9 Apr 2024 23:04 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: Tue, 9 Apr 2024 23:04 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: Tue, 9 Apr 2024 23:04 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: Tue, 9 Apr 2024 23:04 GMT

humanIdentifier attribute is missing in API JSON schema for Commit entity

  • Key: SYSMOAS-11
  • Status: open  
  • 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
  • Updated: Tue, 9 Apr 2024 23:04 GMT
  • Attachments:

Include typing hierarchy into SysML2 OSLC vocabulary

  • Key: SYSMOAS-12
  • Status: open  
  • 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
  • Updated: Tue, 9 Apr 2024 23:04 GMT

Include typing hierarchy into SysML2 OSLC vocabulary

  • Key: SYSMOAS_-9
  • Status: open  
  • 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
  • Updated: Tue, 9 Apr 2024 23:04 GMT

Cleanup OSLC API Resource Shapes and Vocabulary artifacts from OCL code

  • Key: SYSMOAS-13
  • Status: open  
  • 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
  • Updated: Tue, 9 Apr 2024 23:04 GMT

Cleanup OSLC API Resource Shapes and Vocabulary artifacts from OCL code

  • Status: open  
  • 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
  • Updated: Tue, 9 Apr 2024 23:04 GMT

Query conformance and derived properties

  • Key: SYSMOAS-21
  • Status: open  
  • 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
  • Updated: Tue, 9 Apr 2024 23:04 GMT

Query conformance and derived properties

  • Status: open  
  • 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
  • Updated: Tue, 9 Apr 2024 23:04 GMT

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

  • Key: SYSMOAS-9
  • 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: Tue, 9 Apr 2024 23:04 GMT
  • Attachments:

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

  • Key: SYSMOAS_-6
  • 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: Tue, 9 Apr 2024 23:04 GMT
  • Attachments:

derived relation without a specification of how it is derived

  • Key: SYSMOAS-10
  • Status: open  
  • 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
  • Updated: Tue, 9 Apr 2024 23:04 GMT

Provide details on deleting a project that has commits with data

  • Key: SYSMOAS-8
  • Status: open  
  • 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
  • Updated: Tue, 9 Apr 2024 23:04 GMT

Develop Conformance Test Suite for OSLC PSM

  • Key: SYSMOAS-4
  • 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: Tue, 9 Apr 2024 23:04 GMT

Develop Conformance Test Suite for OSLC PSM

  • Key: SYSMOAS_-4
  • 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: Tue, 9 Apr 2024 23:04 GMT

Filtering commit differences by change type

  • Key: SYSMOAS-5
  • Status: open  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    In the PIM, ProjectDataVersioningService.diffCommits(...) operation returns a set of differences between two commits (baseCommit and compareCommit). This includes elements added, updated, or deleted in the compareCommit compared to the baseCommit.
    The set of differences returned from the diffCommits operations can be large, even though served using pagination.
    In many scenarios, consumers of the API may only be interested in specific types of changes, e.g. elements added, or updated, or deleted.
    Can we add an additional argument to the diffCommits operation that returns a filtered set of differences based on a change type versus all the differences.

  • Reported: SystemsModelingAPI 1.0a1 — Sun, 14 May 2023 22:36 GMT
  • Updated: Mon, 8 Apr 2024 18:24 GMT
  • Attachments:

Filtering commit changes by change type

  • Key: SYSMOAS-6
  • Status: open  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    In the PIM, ProjectDataVersioningService.getCommitChange(...) operation returns a set of changes in a given commit compared to the previous commit(s). This includes elements added, updated, or deleted in the given commit. The set of changes returned from the getCommitChange(...) operations can be large, even though served using pagination. In many scenarios, consumers of the API may only be interested in specific types of changes, e.g. elements added, or updated, or deleted.
    Can we add an additional argument to the getCommitChange(...) operation that returns a filtered set of changes based on a change type versus all the changes?

  • Reported: SystemsModelingAPI 1.0a1 — Sun, 14 May 2023 22:37 GMT
  • Updated: Mon, 8 Apr 2024 18:24 GMT
  • Attachments:

API query should have a bnf specification

  • Key: SYSMOAS-20
  • Status: open  
  • Source: International Business Machines ( Mr. Eran Gery)
  • Summary:

    The query is only described using abstract syntax. While most of the API REST commands are fairly straightforward, it is not the case for query. There needs to be a BNF production that specifies the concrete syntax for query, which is the string that would be passed in the body of the post command

  • Reported: SystemsModelingAPI 1.0a1 — Thu, 24 Aug 2023 11:36 GMT
  • Updated: Mon, 8 Apr 2024 18:24 GMT
  • Attachments:

Develop Conformance Test Suite for the REST/HTTP PSM

  • Key: SYSMOAS-2
  • Status: open  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    The goal of this task is to develop conformance test cases for the REST/HTTP 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 REST/HTTP PSM.

  • Reported: SystemsModelingAPI 1.0a1 — Fri, 12 May 2023 22:13 GMT
  • Updated: Mon, 8 Apr 2024 18:24 GMT
  • Attachments:

DataVersion::payload multiplicity

  • Key: SYSMOAS-17
  • Status: open  
  • Source: IncQuery Labs Ltd. ( Dr. Gábor Bergmann)
  • Summary:

    In the Project Data Versioning PIM (Sec 7.1.2, Fig. 5), the relationship between DataVersion and its payload Data is inconsistent with the representation of deletion in Commits.

    As per page 71, Commit::change "is the set of DataVersion records representing Data that is created, updated, or deleted in the
    Commit". This implies that Data being deleted by the Commit must be expressed as a DataVersion object somehow.

    The approach followed by the JSON/RPC PSM is that the DataVersion has an identity that identifies the Data, but the payload is null. However, in the PIM, the multiplicity of DataVersion::payload does not allow it to be null. So seemingly the PIM cannot actually express a Commit that deletes things.

  • Reported: SystemsModelingAPI 1.0a1 — Mon, 31 Jul 2023 17:32 GMT
  • Updated: Mon, 8 Apr 2024 18:24 GMT

No easy way to retrieve all elements under specified model scope

  • Key: SYSMOAS-14
  • Status: open  
  • Source: Dassault Systemes ( Mr. Tomas Vileiniskis)
  • Summary:

    In the API PIM, under ElementNavigationService, there's a getElements service which is dedicated for dumping the entire model content at a given commit.

    This is an overkill for a use case when only part of the model content (e.g. a package) is required to do analysis (or any other task) on.

    While theoretical a workaround could be used via getRelationshipsByRelatedElement by retrieving all of the owned elements under specified owner, this would result in gazillion separate calls and would not be efficient under slower networks.

    Proposal - introduce a new service getOwnedElements with an ability to collect all of the owned elements recursively under specified root or enrich getElements with optional arguments allowing to achieve the same.

  • Reported: SystemsModelingAPI 1.0b1 — Fri, 14 Jul 2023 10:43 GMT
  • Updated: Mon, 8 Apr 2024 18:24 GMT
  • Attachments:

Need to remove action control nodes from Statemachines GBNF productions

  • Key: SYSML2-572
  • Status: open  
  • Source: International Business Machines ( Mr. Eran Gery)
  • Summary:

    Currently state machines GBNF allows for inclusion of control nodes:
    fork, join, merge, final
    They are not currently supported by SysML v2 state semantics and concrete syntax and need to be removed

  • Reported: SystemsModelingAPI 1.0b1 — Mon, 4 Dec 2023 18:30 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT