SysML initial reference implementation should not support versioning

[jamsden]

The current implementation uses a separate service provider for each project commit. That's fine, but we don't necessarily know the relationship between commits on changes to a project, and commits on elements in a project. Nor do we want to have to migrate commit history to locate consistent references to related elements.

So I suggest that we start by simply importing only the head versions of projects and elements from the REST Service API as a convenience for getting initial data.

This will keep the commit/{commitId} components out of the Resource URI paths so they are concept URIs, not version URIs, and avoids introducing something we would want to undo when configuration management is supported.

Then we need to think about how to introduce configuration management into Eclipse/Lyo and Lyo Designer. At that point, we can support user specification of a local Configuration-Context for their UI, and use that to resolve the concept URIs into specific versions.

Again, this keeps the focus on OSLC integration in a global configuration context instead of closed-world SysML only.

This will also significantly reduce the time to import data from the REST Services API, and hopefully will result in more meaningful data for developing examples and demos.

To me, getting the integration right with SysML is more important than model versions. Those versions won't be very useful if then can't be integrated with anything else, including SysML elements in other repositories, in a reasonable way. OSLC has solved this, SysML SST hasn't addressed it yet - they're thinking too much about single closed repositories.

[jadelkhoury]

We will not be able to "keep the commit/{commitId} components out of the Resource URI paths". the commitId is part of the resource URI, and if we want to keep track of the soruce, we need to have this information somehow.

Most interesting is of course is if we demonstrate how an OSLC CM approach would look like. Like Query, I think this can help the Sysml team appreciate the OSLC approach (Compared to theirs).

Introducing CM into Eclipse/Lyo and Lyo Designer would of course be how we can easily enable this, but I don't think I can promise to put the effort needed to realize this.

[jamsden]

But keeping the commit id in the URI path is an anti-pattern for OSLC and doesn't scale to support integration with other lifecycle resources in a global configuration. So I specifically want to remove the commit id from the OSLC URIs and use the Configuration-Context header instead.

I'm not sure I understand the REST Service API configuration model. It looks like any arbitrary collection of changes to an arbitrary set of model elements can be updated with a specific commit id. That's fine for allowing access to specific versions of specific resources. But I think it requires the client to manage a collection of commits and what resources they apply to in order to have a consistent set of related versioned resources that change over time. I don't know if the server knows about the relationships between commits in a timeline, and how to traverse commits when a commit id is included in a resource path that does not directly apply to that resource. There's no tagging or configuration identifier that can be used to identify groups of related versioned resources from different commits.