The next version of the API spec should have a special Service that would allow the Provider to self-describe in terms of:

• which version of the API is the vocabulary of the Provider,
• which Services it is conformant with,
• it there are multiple Conformance Levels for a Service, which one is declared,
• which version of which modeling language will be the content of the projects (this is currently assumed to be SysML, but we should leave the room open here)
• and maybe other attributes in the future.

Moreover, some of these answers may be Project-dependent.

My understanding is that OSLC already has some of these as part of its Discovery feature, but not all; while the REST PSM has nothing.

Som

Reasoning

The current project version structure resembles Git: it consists of immutable commits, with the only mutable objects being tags and branches that point to commits.

However, there are engineering and modeling systems that we would like to expose their contents using the SysML API even though their collaboration model does not fit this. Some or all work happens in context of live collaboration boards with mutable content but without a history expressed as a sequence of immutable, named commits.

Proposal

I think we need another version concept in the standard, that of a whiteboard.

In some sense, this is a mutable counterpart to the Commit concept. It contains elements, though without immutability subsequent read operations or queries may return different results at different times. Similarly to the concept of parent Commits, a Whiteboard may be based on a single base Commit and express a delta compared to it; it should be possible to read the whiteboard as a parent commit + delta, without having to read the entire combined content. It may also be possible to submit an update in order to mutate the whiteboard state (though here we should take care to make this idempotent), or to rebase the whiteboard to a different base commit.

Just like branches, there would be 0 or more of named whiteboards associated with a project, and one of them may be designated as the default whiteboard. Also just like branches, whiteboards would have some content at any time; this content can be directly accessed or used in queries. Just like with branches, the Service makes no guarantee of immutability; subsequent queries of the same whiteboard may yield different results.

However, with a branch it is always possible to get the current state as a Commit and keep this reference for future queries. On the other hand, in case of a whiteboard, it may be possible to baseline it; this is essentially a commit operation that creates a commit out of the current state of the whiteboard (indicating the base of the whiteboard as the parent of the new commit), and sets the whiteboard base to this new commit.

For multi-tenant repositories we need the ability to group projects with into organizations with their RBAC.

Based on a discussion with Ed. I'm not sure if it's a spec of a tooling issue.

On the Pilot Implementation side, it is now the default to not write derived property values or implied relationships to the repository.
This can reduce the JSON size by a factor of 10 or more. It was pretty much the expectation that this would be the only way to save large models efficiently in a repository (or to an interchange file, for that matter).

We still have the option to write JSON including derived properties and/or implied relationships, to accommodate clients that don’t have the ability to recreate those values.
For example, at the moment some visualizers requires that the derived properties be stored in the repository. But this is never really going to work at scale.

Probably the right way to handle this is to never store derived properties and implied relationships in the repository.
Then, for clients that can’t recreate these, have a server-side service that does the derivations and produces JSON for the client that looks as if the derived values had been storied in the repository.

Proposal:
Provide an API endpoint or an option to calculate the derivations and produce the full JSON on retrieval
Provide an API endpoint or an option to strip the derivations from the full JSON on storing

The spec says for the getRootElements method, "Get all the root elements in the given project at the given commit." but it doesn't say how to determine root elements.

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))

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/

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

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)

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

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.

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.

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.

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

commit references project so you don't need both.

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

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?

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?

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

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

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

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.

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.

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

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.

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

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

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

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

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

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

"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

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

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

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/

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

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

Would suggest OCL for ProjectUsage and CommitReference constraints

suggestions in model at https://material.elparazim.com/SysMLv2API/

ProjectUsage needs a derived attribute “usedProject”

Projects may have multiple DataVersions… change Multiplicity

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

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

“created” attribute in Project, CommitReference, Commit should be

... these are not the only ones

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

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/

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

specification and language need to be

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

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

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

Fig. 7 orderBy should be

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)

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

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

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

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

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

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

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

also adding

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

Project
id : UUID

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)

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

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/

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

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/

/branches/

/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).

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/

/tags/

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

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/

/queries/

5. DELETE /projects/

/queries/

/results
7. GET /projects/

/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).

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/

/commits/

/changes
5. GET /projects/

/commits/

/changes/

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

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/

/branches/

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

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/

/commits/

/roots
4. GET /projects/

/commits/

/elements/

/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).

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/

5. DELETE /projects/

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

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.

The POST projects/

/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