SystemsModelingAPI 1.0b2 FTF Avatar
  1. OMG Issue

SYSMOAS — 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="">
        <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){})
    owningMembership &lt;&gt; null and 
    owningMembership.oclIsKindOf(FeatureValue) implies
        let featureWithValue : Feature = 
            owningMembership.oclAsType(FeatureValue).featureWithValue in
        featuringType = featureWithValue.featuringType
        forAll(mem | ownedFeature.selectByKind(BindingConnector)-&gt;
            exists(binding |
                binding.relatedFeature-&gt;includes(result) and

    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: Wed, 14 Feb 2024 00:22 GMT