The PSM sections of the specification include the code from the PSM machine readable files. This is duplication and a potential source of error, whilst not especially helpful to be provided outside of an IDE editor.
Additional changes to the metamodel and XSD have been identified that will facilitate backwards compatibility with BPM+ specs and to make XML model files easier to construct.
Update SCE to further backwards compatibility.
Additional changes to the metamodel and XSD have been identified that will:
Part of this will be to refactor several core elements:
These metamodel figures have been updated:
Note: the following figure was updated after the convenience document was posted.
Note: the following figure was updated after the convenience document was posted.
Note: the following figure was updated after the convenience document was posted.
For context, SCE contains references to KPMN & PPMN as standards that had planed to use SCE. However, the KPMN Finalization Task Force decided not to finish their specification and did not submit an FTF report. As a result, KPMN is not a viable specification for SCE to reference. PPMN has yet to be finalized and although its Finalization Task Force is active, it is not far enough along to be sure that it will pass all checks & votes in time and be adopted.
Remove references to non-existing specifications
Remove all references to KPMN and PPMN.
The removal of these references has no effect on SCE as a language because they have only served to provide context.
A later RTF may reintroduce these references, when the other specifications have actually been adopted.
The resolution of SCE-96, which replaced Element with BaseElement, has not been applied in Table 17 "ElementRelationship Attributes and/or Associations" in the types and descriptions of sourceRef and targetRef.
Replace Element with BaseElement in Table 17
Complete the resolution of SCE-96
Based on experience with DMN, frequently changing namespace URIs, i.e. with every minor revision, cause market fragmentation across supported specification versions, as it cannot be assumed that all vendors update to the latest version of the spec at the same time, if at all.
This forces users to do unnecessary version migrations or their models would not be opened by a tool as invalid or outdated.
Revisions by an RTF only have a mandate to fix bugs and should therefore only add a limited amount of new language elements. Thus only a small percentage of models created using the new spec version actually use new features. So the majority of models could still be opened and edited in older tools if it weren't for the namespace to completely prevent that.
Use fixed Namespace URI and xsi:schemaLocation
Use namespace URIs and file URLs without a dated version stamp as permitted by the OMG Policy for Versioning of Specification URIs, File URIs, and XML Namespaces (smsc/2018-08-01). We are aware that using these comes with backwards-compatibility requirements (which should count for RTFs anyways) and the file URLs are redirected to dated URLs for each version.
In addition, the xsi:schemaLocation attribute is used to indicate which exact version of a schema is used for each namespace. As a side effect it allows most XML tools to automatically perform schema validation without any additional configuration. This last point may sound trivial but experience with BPMN has shown that many implementers did not perform an XML schema validation when they implemented import and export of BPMN files. So automatically enabling it could help to prevent interchange issues and lead to better tool interoperability.
The hope is to avoid or at least reduce friction due to market fragmentation across different versions and avoid unnecessary version migrations for users. In summary, SCE-based files created with newer versions are perfectly fine to open and edit with older tools unless new language features are used.
The export of BPM+ languages is centered around the SCEModel element. This is the base class for all model elements. Other packages, based on SCEPackage, can be within the SCEModel, but they would not have a separate exporter or exporter version. Currently, all sub-packages could be assigned separate version, but this does not make sense.
Move exporter and exporterVersion to the SCEModel class
The export of BPM+ languages is centered around the SCEModel element. This is the base class for all model elements. Other packages, based on SCEPackage, can be within the SCEModel, but they would not have a separate exporter or exporter version. Currently, all sub-packages could be assigned separate version, but this does not make sense.
Thus, exporter and exporter version should be moved to the SCEModel Class.
Many SCE classes include "SCE" as a prefix (e.g., "SCEModel"). This is not necessary for the UML metamodel and is redundant in the XML schema since elements are marked with namespaces.
Remove SCE prefix
Remove SCE prefix from all UML class names and all XML types and elements
The copyright section contains the RFP version copyrights, but not the FTF ones.
Update copyright section
Update the years of contribution based on OMG-recognized contributors and taskforce membership.
The metamodel describes tag as list of strings but the XML schema has just a single string. Also the name does not indicate a list.
Rename to tags and make it a list in XSD
Rename "tag" to "tags" (in line with SCE-82) and make it a list of strings in the XML schema.
The following names differ between Diagram Interchange MM and XSD:
Update DI MM names based on XSD
The names in the DI XSDs have been changed by SCE-84 or have already been like that in DMN & CMMN.
The attribute modelElement of DiagramElement is currently required but should be optional for backwards compatibility and for special situations where the DiagramElement does not depict a BaseElement from the Model, e.g., a BPMN DataAssociation connected to a SequenceFlow.
This was an oversight in SCE-84.
Make modelElement optional
Make modelElement optional in spec, MM & XSD.
The attribute text of the class Label should not have been copied from DMN because it is not a "Common Element", i.e., it doesn't exist in BPMN & CMMN. Also it doesn't conform to the design principle of Diagram Interchange to avoid redundancy.
Remove text from Label
Remove text from Label in spec, MM & XSD.
As part of this we are also improving the Label class diagram to show how it gets its text from the name of the BaseElement.
SCE copied extension classes from BPMN that were meant for extensibility of the metamodel and are explicitly declared to not show in the XML schema because the XML already has built-in extension mechanisms. That's what the X in XML stands for 
The XSD is missing the extensionElements container that BPMN, CMMN & DMN are using to store XML extension elements in a way that schema validation is not ambigious.
The SCE XSD even includes the statements that BPMN made about these classes, e.g.:
ExtensionDefinition: This type is not applicable when the XML schema interchange is used, since XSD Complex Types already satisfy this requirement.
ExtensionAttributeDefinition/ExtensionAttributeValue: This type is not applicable when the XML schema interchange is used; since the XSD mechanisms for supporting "AnyAttribute" and "Any" type already satisfy this requirement.
extensionDefinitionRef/extensionAttributeValueRef: This association is not applicable when the XML schema interchange is used, since the XSD mechanisms for supporting anyAttribute and any element already satisfy this requirement.
BPMN had the classes ExtensionDefinition, ExtensionAttributeDefinition, ExtensionAttributeValue only in the UML metamodel but not in the XML schema. During the RFP phase, SCE had already removed the classes from its UML metamodel and specification text because UML also has built-in extension mechanisms. However, it seems like they were automatically generated into the XML schema and are still in there.
In addition, the XSD also contains Adornment types that are based on the extension type, which should have not been in the XSD.
Add extensionElements container and remove other extension classes
SCE XSD MUST have the extensionElements container that BPMN, CMMN & DMN tools have been successfully using for vendor extensions and even extension standards that several vendors agreed on, e.g. BPMN I18n. This is needed for backwards compatibility and in general to enable use of XML's extension mechanism.
The types ExtensionDefinition, ExtensionAttributeDefinition, and ExtensionAttributeValue are removed from the XSD, because they are not meant to be in the XML schema.
The Adornment types are removed, because they are based on these extension types that should not have been in the XSD. Are later revision of SCE may add Adornments again. But it would have to be done in a way that uses XML's extension mechanism.
Furthermore, the type tExtension is removed from SCE as it only exists in BPMN and has never been used in practice as shown in the BPMN MIWG. It would be trivial for an SCE-based revision of BPMN to introduce that type as an extension of tRootElement.
The acknowledgement section contains the information from the RFP, but not the FTF
Update acknowledgements
Add paragraphs to acknowledge the SCE contributors to section "4.1 Acknowledgements" based on taskforce membership in the FTF
Fix all identified typos in the beta Spec, if they have not been identified in other issues
Fix Specification Errors
Add the path to the Diagram Definition specification in the Normative References section.
Remove redundant "OMG" prefixes to the named specifications in the Non-Normative References section.
Section 8.1
Replace Figure 2. The humanId attribute should have been removed from SCERootElement and the aliasIds attribute should have been pluralized in the figure by issue SCE-48/SCE-82.
Section 8.1.5
Remove Figure 4: The SCE Packaging Elements Metamodel, it is redundant.
Section 8.1.5.1
Remove Figure 6: The SCE Packaging Elements Metamodel, it is redundant.
Section 8.2
In second paragraph, replace ending "." with ":"
Replace Figure 3. The humanId attribute should have been removed from SCERootElement and the aliasIds attribute should have been pluralized in the figure by issue SCE-48/SCE-82.
Section 8.2.3 Category
In second paragraph after Figure 12:
replace “Resonsibilities” with “Responsibilities” (add a “p”)
Section 8.4.3 RelationshipKind
in second paragraph
replace "...by one of the six instances..." with "...by one of the seven instances..."
Table 34 mapping for BPMN RootElement:
change references for "SCEElement" to "SCERootElement"
change "identifier" to "id"
Table 36 mapping for CMMN CMMNElement:
change references for "SCEElement" to "SCERootElement"
change "identifier" to "id"
Table 38 mapping for DMN base elements:
change references for "SCEElement" to "SCERootElement"
change "identifier" to "id"
id is not an acronym but short for identifier. So for consistency with the "id" property, and camelcase rules, they should be humanId and aliasId
Update capitalization for humanID and aliasID
"humanID" should be changed to "humanId"
"aliasID" should be changed to "aliasId"
SCE-52 introduced default values expressionLanguage and typeLanguage but did not set the cardinality to [0..1] in metamodel and spec text. In the XSD they are already optional. This is also needed for backwards compatibility to existing specs.
Set expressionLanguage and typeLanguage to optional
These attributes should have been set to option through SCE-52. This issue will correct it.
As part of finalizing an minimum viable product for SCE, remove the vocabulary mechanism. There has been much discussion about the topic and the necessity for the capability has been questioned.
In any case, the current mechanism doesn't work, especially which the proposed change to Semantic Reference.
We may need to include some sort of extendible enumeration capability at some point. This will be handled in conjunction with review of BKPMN, PPMN, PMN, and SDMN enumeration requirements.
to be MOF compliant
Add Labels for all SCE Metamodel Relationships
It is a MOF requirement that associations must be named (not just role names).
RelationshipKinds should be well-known set of kinds. These kinds have semantic meaning and have notational impacts. Thus, they should be part of the normative spec through a standard enumeration (or perhaps sub-classes).
Maintain how RelationshipKinds are defined through an extendible library
The vocabulary mechanism has been replaced by KindSets in SCE-8.
In terms of this issue, there are downstream specifications, such as PPMN, that will use and extend the RelationshipKinds library.
Thus, we should close this issue (i.e., not convert to a fixed enumerated list).
It can also be noted that downstream specs do not have to use the library mechanism and can define their own enumerated set of relationship Kinds.
Though Vocabulary in SCE would correspond to Dictionary in MVF, since SemanticElement in SCE corresponds with MVFEntry in MVF.
The refactoring of Vocabularies to KindSets changed the scope of this issue
SCE-7 involved the restructuring of the Vocabulary and SemanticReference capabilities. KindSets are simple, extendable lists and are not related to MVF the way vocabularies would be.
Thus, we can close with no change.
I would suggest all acronyms be capitalized. All types start with 't'.
Changes to the base DC and DI schemas are out of scope for SCE
This would involve changes to the base DC and DI schemas which should be handled by a Diagram Interchange RTF. All the BPM+ specs use these base schemas, thus SCE should not change.
if this is to be the target of using substitutionGroup, then
<xsd:element name="modelArtifact" type="sce:tModelArtifact" minOccurs="0" maxOccurs="unbounded">
should be:
<xsd:element ref="sce:ModelArtifact" minOccurs="0" maxOccurs="unbounded"/>
the wrong type of element in XSD for ModelArtifact – should be a ref
all types should start with 't'
Changes to the base DC and DI schemas are out of scope for SCE
This would involve changes to the base DC and DI schemas which should be handled by a Diagram Interchange RTF. All the BPM+ specs use these base schemas, thus SCE should not change.
all types should start with 't'
Changes to the base DC and DI schemas are out of scope for SCE
This would involve changes to the base DC and DI schemas which should be handled by a Diagram Interchange RTF. All the BPM+ specs use these base schemas, thus SCE should not change.
The documentation for id says "uniquely identify" but not the scope - within a single model, universally?
And for humanID (sic) it's also vague: "the uniqueness of this identifier within a model or relative to some other context."
The intended usage is unclear - calling it "human" does not seem helpful since it's presumably not for human consumption e.g. for display on a diagram?
And "human" is also wrong if the model was generated by a tool, i.e. the "modeler" is not a human.
Without further rules, or a compliance point, interoperability becomes unnecessarily hard.
Remove humanId and make aliasIds a list
The humanId was added to make SCE consistent with KerML (as it was being developed). However, the final beta version of KerML (ptc/2023-06-01) does not include humanId (perhaps because of the inconsistencies identified by this issue). Thus, we can remove it.
Further, we should update the aliasId property - to aliasIds and update its description as necessary.
The current pattern will often be named with SCE as a prefix (e.g., sceKindSet for the association between SCEModel and SCEKindSet. It is redundant to use the "sce" prefix for association role names and can be confusing in the context of namespaces and target elements. A more descriptive role name should be used, such as the type of element the association is target.
Remove "sce" as a prefix for association role names
Change the pattern of naming association role names in the metamodel.
The "sce" prefix is removed from the role names.
For example, change the "sceKindSet" role name to "kindSet"
How can other Expressions languages (other than FEEL) be used?
SCE itself doesn't provide ways of dealing with expressions other than defining the default languages. It will be updated by languages that use SCE and have Expressions. The expression itself will have an attribute to define (that is, override the default) language.
This should be explained in SCE.
Describe how other Expression Languages can be used
Add text to the table entry for the expressionLanguage attribute for the SCEModel class that describes how the language can be overridden by downstream languages.
They are optional properties and can be used by multiple languages, including the original BPM+ languages.
Include expressionLanguage and typeLanguage with default values
The expressionLanguage and typeLanguage properties, which are now part of SDMN, will be added to SCE. The properties will be added to the SCEModelPackage class - although this location may change because of other issues.
Figure 11 Annotations shows the older version of SCEElement. Original version did not have a "root" element. One was added in another issue with then made this figure incorrect. This issue was caused by that change.
Replace Figure 11
A number of figures need to be replaced because they are inconsistent with the current version of the SCE specification
Name is odd if it's meant to represent a specific version. For example OWL uses versionIRI for this.
As part of our approach to create a MVP SCE, we should refactor the packaging mechanisms so that BPMN, CMMN, and particularly DMN can use the SCE infrastructure
Restructure SCE Packaging to be backwards compatible with current BPM+ specifications
This will be a major change but will help with the adoption of the new BPM+ specs and can allow BPMN, CMMN, and DMN to also utilize SCE (at some point). Right now the old BPM+ specs will not be able to use SCE.
The basic idea is to simplify the packaging structures to be compatible with the old specs and still allow new capabilities (such as instance packages).
This will affect the spec doc, the metamodel, and the schemas.
---------
The proposal is to simplify the packaging mechanisms so that the existing BPM+ languages can use SCE. The current SCE packaging structure is too complex.
Further, the approach of the FTF is to create the MVP version of SCE and get that to work (i.e., get working implementations). If we find later that we need more capabilities, then SCE can be updated, from this backwards compatible base, to include those capabilities.
Basically, the SCE packaging would be reduced to a single class called SCEModel, which is the top level container for defining and exchanging model elements. This maps to the “Definitions” class from BPMN, CMMN, and DMN. The SCEDI class is contained within SCEModel and would hold the diagrams associated with the models.
Thus, the new SCE metamodel would be simplified to this (there are more details for SCEModel, but this represents the basic packaging):
see attachment
The current SCEModelPackage, SCEModel, and SCEDefinitions have been collapsed into the single SCEModel class.
The SCEProfile class is removed. There are no specific use cases for this class yet. Thus, the MVP approach is to remove it until needed.
Most of the BPM+ languages do not need instance elements in the models. Thus, the MVP approach is to remove it in SCE and add it where needed. For those languages that need to include instances (of types) such as PMN and PPMN, they can create an instance package based on SCEModel within their metamodels. We can work with the PPMN FTF to build that structure.
Without the addition packages of Profile and Instances, the base SCEPackage is not needed either. This can be added back without affecting the downstream languages if necessary.
The current SCE XSDs were developed with a faulty translation of UML class relationships to the XSD elements.
To resolve this issue we need to specify the XSD patterns that correspond to the UML class relationships and then update the XSDs.
Use same MM-XSD Mapping as in BPMN, CMMN & DMN
Use the MM-XSD mapping approach that BPMN pioneered for the BPM+ ecosystem to remain backwards compatible (for SCE-40) and allow vendors to reuse their existing language tooling based on that mapping. SDMN is following the same approach in SDMN-111.
The Import section has some inaccuracies and should be refactored to be a very general mechanism as a foundation for the specs that use SCE. Further import constraints will have to be defined for each language.
Update the description of Import in the Spec
Correct some inaccuracies in the description in Table 16.
Mostly deleting irrelevant information.
The inclusion of instance elements for modeling and exchange is limited in BPM+ to PMN and PPMN (which is dependent on PMN). It is not currently considered to be a generic enough feature to be included in SCE, since most BPM+ languages do not need it.
Thus, in the interest in creating an MVP SCE, it is suggested here that the instance definition elements be removed in SCE and placed in PMN where it is first needed.
This issue was identified through issue SCE-40, which deals with making SCE backwards compatible to the original BPM+ languages. However, there are other elements besides the SCEIntances package that need to be moved, such as TypedElement.
The proposal for this issue will be layered upon (dependent on) the resolution for SCE-40.
Remove definition of instance elements (to be moved to PMN)
The inclusion of instance elements for modeling and exchange is limited in BPM+ to PMN and PPMN (which is dependent on PMN). It is not currently considered to be a generic enough feature to be included in SCE, since most BPM+ languages do not need it.
Thus, in the interest in creating an MVP SCE, it is suggested here that the instance definition elements be removed in SCE and placed in PMN where it is first needed.
This issue was identified through issue SCE-40, which deals with making SCE backwards compatible to the original BPM+ languages. However, there are other elements besides the SCEIntances package that need to be moved, such as TypedElement.
The proposal for this issue will be layered upon (dependent on) the resolution for SCE-40.
More recent discussions have moved to the approach of leaving the capability with SCE but let downstream specs use it or not. Thus, we may close with no change.
The Semantic Reference mixes the use cases of referencing an external concept and defining a kind in an extensible set of kinds.
Split SemanticReference into conceptReference and Kind + rename Vocabulary into KindSet
The SCEVocabulary class will be renamed to SCEKindSet and SemanticReference will be renamed to Kind (which are the terms of the KindSet). This separates the terms of a KindSet with Semantic References. Other changes will be reflected in the details of the metamodel (see Convenience Document).
Further, a property named "conceptReference" of type URI [0..1] will be added to SCEElement to provide the reference capability.
This will affect other aspects of Vocabularies and creating extendable lists. Going forward, SCEKindSets and Kinds will be used for extendable lists.
Use of KindSets for example in SDMN
to be MOF compliance
Close because this issue was submitted to the wrong Task Force
This issue should have been submitted to the SDMN FTF.
This will probably affect the packaging structures more than anything.
If done properly, it may be possible for current BPM+ vendors to overlay those models on top of SCE.
Mr. Falko Menge has already done some testing of the BPMN schema utilizing SCE. There are some breakages that may be fixed through SCE adjustments.
We may need to reconsider the PPMN requirements for Instance packages as part of SCE (and move to PPMN directly).
This will ensure that all downstream languages will use the same notation if they have connectors based on the RelationshipKinds.
Defer to the RTF
This can be done in the RTF. However, the SDMN and PPMN RTFs will ensure that there are no inconsistencies between their notation for these relationship connectors in their respective specs.
Basically all lines between model elements in all the BPM+ models (BPMN, CMMN, DMN, SDMN, BKPMN, Parties, and PPMN) should be (theoretically maybe) derived from one of the SCE Relationship Kinds.
And if we define the basic notation for each of these relationships, then all subsequent models will provide consistent relationship notations.
Defer to the RTF
Since the KindSet mechanism allows for extensions to libraries such as RelationshipKinds, the current set of library instances can be extended in the future.
The changes to the current SCEVocabulary models should be mapped to MVF.
Defer to the RTF
This mapping will be useful but it is something that can wait until the RTF.
The Kinds should be instances of Kind from SCE not instances of UML InstanceSpecification. It needs to be converted from UML to use the SCE metamodel itself. See SCE model files for an example. Pete Rivett has XSLT to automate this.
The changes to the current SCEVocabulary models should be mapped to MVF.
Basically all lines between model elements in all the BPM+ models (BPMN, CMMN, DMN, SDMN, BKPMN, Parties, and PPMN) should be (theoretically maybe) derived from one of the SCE Relationship Kinds.
And if we define the basic notation for each of these relationships, then all subsequent models will provide consistent relationship notations.
This will ensure that all downstream languages will use the same notation if they have connectors based on the RelationshipKinds.
The acknowledgement section contains information from the RFP, but not the FTF
Update Acknowledgements
Add acknowledgements for SDMN 1.0 contributors from FTF Participation
The current SDMN XSDs were developed with a faulty translation of UML class relationships to the XSD elements.
To resolve this issue we need to specify the XSD patterns that correspond to the UML class relationships and then update the XSDs.
Use same MM-XSD Mapping as in BPMN, CMMN & DMN
Use the MM-XSD mapping approach that BPMN pioneered has since been used for all other languages of the BPM+ ecosystem, e.g. DMN & CMMN, to remain backwards compatible and allow vendors to reuse their existing language tooling based on that mapping.
This also follows the decision of SCE-81.
