Community
Participate
Working Groups
We haven't really abstracted our workspace-based repository from the available operations in the resource modeling subproject. There needs to be extension mechanisms added in to allow vendors to define their own concept of a repository that can contain SML model units. The user experience should be similar irregardless of the repository that is used to store the units. The user is expected to: - Add/remove units from the repository - Navigate through instances - Select instances to have them exported into an SML-IF model - Reference a unit inside another unit - Validate a set of SML units
The resource management in the context of a repository seems to be more related with Data Collection project.
This is in line with the SML common library notion of repository; the idea is to be able to import/export to SMLIF using any type of SML repository. The current implementation assumes a file respository structure for the SML library
Ali, per our discussion I am adding 180068 as a dependency for this defect. 180068 requires a set of API to navigate the SML repository. These two requests are related through the SML repository generic definition and extensibility, to be done using this defect
Created attachment 66186 [details] Design document
I'm not sure if the concept of rule bindings is completely modeled. There are three cases of rule bindings: a rule is not bound to anything, a rule is bound to a specific instance, and a rule is bound globally to all instances in a SML-IF document. Case 1 is supported simply by creating a rule and not binding it to anything. Case 3 appears to be supported by ISMLIFIdentity.bindRule() since a binding is added without specifying a document. However, I don't see that Case 2 is supported. I assume this could be supported by adding a ISMLIFIdentity.bindRule(ruleAlias,documentAlias). Another perhaps more OO way of supporting rule bindings is to pass in the actual ISMLDocumentDefinition instance for the rule argument and the ISMLDocumentInstance instance for the document argument, and I presume for the SML-IF model we would just use the first found alias for each. I was also wondering if there should be any type or behavioral distinction between the two different types of ISMLDocumentDefinition instances, since some can be Schematron rules and some can be schema that is validated against the ISMLDocumentInstance instances.
Other than the repository operations (i.e. import/export/validate), the implementation of this enhancement is complete. There is a new plug-in checked under resource-modeling called: "org.eclipse.cosmos.rm.repository". org.eclipse.cosmos.rm.repository/src-core contains the provisional APIs and org.eclipse.cosmos.rm.repository/src-core-impl contains the file system repository implementation. Everything required for the June milestone should be there. The data visualization component can connect to the repository and fetch documents based on a set of criteria. There is also a plug-in checked in under tests/resource-modeling called: org.eclipse.cosmos.rm.repository.tests which uses JUnits to exercise the code. Sheldon, let me know if there is anything that is impeding you from completing your work.
I'm marking this enhancement as fixed. The import and export operations have been refactored and integrated with the repository plug-in. The validate operation is not integrated with the repository plug-in until there are use cases requiring this to be complete. I don't suspect that it's too much work but I need to be convinced that there are use cases needing this to be done before I spend more time on this enhancement. The validate operation can of course be used in standalone mode or inside the Eclipse SDK environment. The repository plug-in has a total of 66 JUnits.
closing
