${taskforce.name} Avatar
  1. OMG Task Force

Specification Common Elements (SCE) 1.0 FTF — All Issues

  • Key: SCE
  • Issues Count: 60
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
SCE-96 More work for backwards compatibility needed SCE 1.0b1 SCE 1.0b2 Resolved closed
SCE-119 Refences to non-existing specifications SCE 1.0b1 SCE 1.0b2 Resolved closed
SCE-107 Annotation class provides no value and conflicts with downstream languages SDMN 1.0b1 SCE 1.0b2 Resolved closed
SCE-109 XSD Chapter Outdated with incorrect text. SDMN 1.0b1 SCE 1.0b2 Resolved closed
SCE-121 Element not replaced with BaseElement in Table 17 SCE 1.0b1 SCE 1.0b2 Resolved closed
SCE-88 The file filed as the SCE metamodel is in fact SDMN SDMN 1.0b1 SCE 1.0b2 Closed; Out Of Scope closed
SCE-117 Frequently changing Namespace URIs cause market fragmentation SCE 1.0b1 SCE 1.0b2 Resolved closed
SCE-53 SCEDI cannot be directly re-used as-is SDMN 1.0b1 SCE 1.0b2 Resolved closed
SCE-85 Exporter information is located in the wrong class SCE 1.0b1 SCE 1.0b2 Resolved closed
SCE-90 Using "SCE" as a prefix for class names is unnecessary SCE 1.0b1 SCE 1.0b2 Resolved closed
SCE-101 importType Property description obsolete and too restrictive SDMN 1.0b1 SCE 1.0b2 Resolved closed
SCE-91 Copyright section needs update SCE 1.0b1 SCE 1.0b2 Resolved closed
SCE-105 tag attribute is a string list in MM but just a string in XSD SCE 1.0b1 SCE 1.0b2 Resolved closed
SCE-115 Small inconsistencies between DI MM and XSD SCE 1.0b1 SCE 1.0b2 Resolved closed
SCE-111 modelElement is not optional SCE 1.0b1 SCE 1.0b2 Resolved closed
SCE-113 Label should not have a redundant text attribute SCE 1.0b1 SCE 1.0b2 Resolved closed
SCE-99 XSD copied the wrong extension elements from BPMN and lacks the important ones SCE 1.0b1 SCE 1.0b2 Resolved closed
SCE-103 Some SCE Elements are concrete instead of abstract SDMN 1.0b1 SCE 1.0b2 Resolved closed
SCE-92 Acknowledgements for SCE 1.0 contributors needed SCE 1.0b1 SCE 1.0b2 Resolved closed
SCE-27 There are editorial issues in the Specification SCE 1.0b1 SCE 1.0b2 Resolved closed
SCE-47 Inconsistent capitalization in humanID and aliasID compared to id SCE 1.0a1 SCE 1.0b2 Resolved closed
SCE-67 expressionLanguage and typeLanguage are not optional SCE 1.0b1 SCE 1.0b2 Resolved closed
SCE-37 Not enough need for vocabulary mechanisms in SCE SCE 1.0b1 SCE 1.0b2 Duplicate or Merged closed
SCE-87 Internal Relationships - various SDMN 1.0b1 SCE 1.0b2 Duplicate or Merged closed
SCE-3 SCE Metamodel Relationships do not have labels SCE 1.0b1 SCE 1.0b2 Resolved closed
SCE-25 Change RelationshipKinds from a Vocabulary to a UML Enumeration SCE 1.0b1 SCE 1.0b2 Closed; No Change closed
SCE-44 SCE vocabularies should reuse MVF SCE 1.0a1 SCE 1.0b2 Closed; No Change closed
SCE-31 Consider renaming rgb to tRGB SCE 1.0b1 SCE 1.0b2 Closed; Out Of Scope closed
SCE-34 wrong type of element in XSD for ModelArtifact -- should be a ref SCE 1.0b1 SCE 1.0b2 Duplicate or Merged closed
SCE-32 suggest AlignmentKind be renamed 'tAlignmentKind' SCE 1.0b1 SCE 1.0b2 Closed; Out Of Scope closed
SCE-33 suggest KnownColor be renamed tKnownColor SCE 1.0b1 SCE 1.0b2 Closed; Out Of Scope closed
SCE-48 Unclear scope of identifiers and use of "human" SCE 1.0a1 SCE 1.0b2 Resolved closed
SCE-63 The pattern of naming association role names in the metamodel is redundant SCE 1.0b1 SCE 1.0b2 Resolved closed
SCE-62 How can other Expressions languages be used? SCE 1.0b1 SCE 1.0b2 Resolved closed
SCE-15 Consider better Vocabulary extension / re-use model, plus specialised terms (IS-A) SDMN 1.0b1 SCE 1.0b2 Duplicate or Merged closed
SCE-14 Wrong Xrefs in text SDMN 1.0b1 SCE 1.0b2 Resolved closed
SCE-2 Common attributes expressionLanguage and typeLanguage are missing SCE 1.0b1 SCE 1.0b2 Resolved closed
SCE-28 Figure 11 Annotations Metamodel is incorrect SCE 1.0b1 SCE 1.0b2 Resolved closed
SCE-46 Fundamental problem - cannot represent the properties/characteristics of an Element PPMN 1.0b1 SCE 1.0b2 Closed; No Change closed
SCE-45 SemanticReference::conceptNamespace oddly named SCE 1.0a1 SCE 1.0b2 Duplicate or Merged closed
SCE-40 SCE is not backwards compatible with the original BPM+ specs SCE 1.0b1 SCE 1.0b2 Resolved closed
SCE-35 Incorrect Mapping from Metamodel to XSD SCE 1.0a1 SCE 1.0b2 Resolved closed
SCE-36 The description of Import in the Spec needs updating SCE 1.0b1 SCE 1.0b2 Resolved closed
SCE-9 Category class - various SDMN 1.0b1 SCE 1.0b2 Resolved closed
SCE-42 Move definition of instance elements to PMN SCE 1.0b1 SCE 1.0b2 Closed; No Change closed
SCE-12 SCERootElement.id definition mandatory but optional SDMN 1.0b1 SCE 1.0b2 Resolved closed
SCE-7 Semantic Reference mixes too many use cases SCE 1.0b1 SCE 1.0b2 Resolved closed
SCE-21 SCEModel.category needed? SDMN 1.0b1 SCE 1.0b2 Closed; No Change closed
SCE-16 Association - TYPO SDMN 1.0b1 SCE 1.0b2 Resolved closed
SCE-4 Add Labels for all SDMN Metamodel Relationships SCE 1.0b1 SCE 1.0b2 Closed; Out Of Scope closed
SCE-10 Blank cardinality safe to use? SDMN 1.0b1 SCE 1.0b2 Deferred closed
SCE-13 RootElement.name needs clarification SDMN 1.0b1 SCE 1.0b2 Resolved closed
SCE-11 Unresolved ref in text SDMN 1.0b1 SCE 1.0b2 Resolved closed
SCE-1 Adjust the structural elements of SCE such that they are backwards compatible with BPMN, CMMN, and DMN. SCE 1.0b1 SCE 1.0b2 Duplicate or Merged closed
SCE-6 Add Notations for Relationship Kinds in SCE SCE 1.0b1 SCE 1.0b2 Deferred closed
SCE-18 Reconsider dependency of SCE on other BPM+ specs SDMN 1.0b1 SCE 1.0b2 Deferred closed
SCE-19 Terms should not be defined in terms of CMMN, BPMN artefacts, but as self-standing concepts SDMN 1.0b1 SCE 1.0b2 Deferred closed
SCE-20 Consider removing references to BKPMN etc SDMN 1.0b1 SCE 1.0b2 Deferred closed
SCE-22 SCE Relationship Kinds Should Cover All BPM+ Relationships SCE 1.0b1 SCE 1.0b2 Deferred closed
SCE-23 Add Mapping of SCE Term functions to MVF in Spec SCE 1.0b1 SCE 1.0b2 Deferred closed

Issues Descriptions

More work for backwards compatibility needed

  • Key: SCE-96
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    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.

  • Reported: SCE 1.0b1 — Tue, 16 Jan 2024 20:01 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    Update SCE to further backwards compatibility.

    Additional changes to the metamodel and XSD have been identified that will:

    • facilitate backwards compatibility with existing BPM+ specs
    • make XML files easier to read, e.g. semantic first, diagrams at the bottom
    • make the semantic model less sensitive to sequencing issues, which have been plaguing BPMN model interchange a lot
    • make XML Schema files easier to construct, i.e. no need to list all root elements in the Model class

    Part of this will be to refactor several core elements:

    • RootElement and Element will be merged into one class called BaseElement that will be the root of the class hierarchy as in BPMN.
    • A new empty sub-class of BaseElement will be called RootElement as in BPMN. This provides a marker class and xsd:substitutionGroup for downstream languages to use for including their elements into a Model. RootElement will therefore be contained by Model.
    • Several classes contained in Model will make use of using RootElement as a xsd:substitutionGroup to hook into Model
    • Import will no longer be a subclass of RootElement. This relationship is not needed. Instead it will be a BaseElement.
    • ExternalRelationship is renamed to Relationship
    • Enumeration values start with an uppercase letter
    • Association's source, target and direction are optional

    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.


  • Updated: Mon, 16 Sep 2024 14:12 GMT
  • Attachments:

Refences to non-existing specifications

  • Key: SCE-119
  • Status: closed  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    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.

  • Reported: SCE 1.0b1 — Fri, 22 Mar 2024 21:01 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    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.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

Annotation class provides no value and conflicts with downstream languages

  • Key: SCE-107
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The Annotation class, an abstract class, is no longer necessary since Documentation and Category are no longer subclassing it. With only Attachment subclassing Annotation, it provides no value. It also adds additional structural overhead that is not needed. Further, using the name "Annotation" conflicts with downstream language PPMN that want to use it for an unrelated language element.

  • Reported: SDMN 1.0b1 — Wed, 31 Jan 2024 17:52 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    Remove Annotation

    Remove Annotation Class from Metamodel and Schema

  • Updated: Mon, 16 Sep 2024 14:12 GMT
  • Attachments:

XSD Chapter Outdated with incorrect text.

  • Key: SCE-109
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    XSD Chapter Outdated with incorrect text that was copied from the DMN specification.

  • Reported: SDMN 1.0b1 — Wed, 31 Jan 2024 23:42 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    Fix text in XSD Chapter

    Update class names and element names and refer to QNames instead of href (as how BPMN and CMNN handles this).

  • Updated: Mon, 16 Sep 2024 14:12 GMT

Element not replaced with BaseElement in Table 17

  • Key: SCE-121
  • Status: closed  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    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.

  • Reported: SCE 1.0b1 — Mon, 1 Apr 2024 17:21 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    Replace Element with BaseElement in Table 17

    Complete the resolution of SCE-96

  • Updated: Mon, 16 Sep 2024 14:12 GMT

The file filed as the SCE metamodel is in fact SDMN

  • Key: SCE-88
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    This file linked to from the SCE catalog page (https://www.omg.org/spec/SCE )
    https://www.omg.org/spec/SCE/20211101/SCE.xmi does not include the SCE package but seems to be the SDMN package which imports SCE (there are proprietary hrefs to SCE.mdzip) though the file has more than the official SDMN metamodel.

    Further the files on this catalog page https://www.omg.org/spec/SCE which have SCE in their name have descriptions which refer to SDMN not SCE e.g.
    "Shared Data Model and Notation (SDMN) XSD" is the description for SCE/20211101/SCE-Library.xsd

  • Reported: SDMN 1.0b1 — Mon, 22 Aug 2022 06:29 GMT
  • Disposition: Closed; Out Of Scope — SCE 1.0b2
  • Disposition Summary:

    Out of scope for the FTF

    The FTF is not is a position to correct this issue. The correct files have been submitted to the OMG for replacement on the web site. Furthermore, we will ensure that the proper updated files are submitted at the completion of this FTF.

  • Updated: Mon, 16 Sep 2024 14:12 GMT
  • Attachments:

Frequently changing Namespace URIs cause market fragmentation

  • Key: SCE-117
  • Status: closed  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    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.

  • Reported: SCE 1.0b1 — Mon, 5 Feb 2024 23:57 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    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.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

SCEDI cannot be directly re-used as-is


Exporter information is located in the wrong class

  • Key: SCE-85
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    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.

  • Reported: SCE 1.0b1 — Mon, 8 Jan 2024 19:08 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    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.

  • Updated: Mon, 16 Sep 2024 14:12 GMT
  • Attachments:

Using "SCE" as a prefix for class names is unnecessary


importType Property description obsolete and too restrictive

  • Key: SCE-101
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The description of the import element was copied from BPMN and contains information that are not appropriate to SCE, which is an infrastructure specification and not specific to any modeling language.
    Note that this text was updated by SCE-36, but the update was not comprehensive enough

  • Reported: SDMN 1.0b1 — Mon, 29 Jan 2024 20:29 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    Update importType Property Description

    Reduce the description of the import element to a generic explanation of the mechanism without implying support for certain import types by SCE-based languages.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

Copyright section needs update

  • Key: SCE-91
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The copyright section contains the RFP version copyrights, but not the FTF ones.

  • Reported: SCE 1.0b1 — Mon, 15 Jan 2024 18:34 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    Update copyright section

    Update the years of contribution based on OMG-recognized contributors and taskforce membership.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

tag attribute is a string list in MM but just a string in XSD


Small inconsistencies between DI MM and XSD

  • Key: SCE-115
  • Status: closed  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    The following names differ between Diagram Interchange MM and XSD:

    • SCEDI::Diagram.sharedStyleRef
    • SCEDI::Diagram.localStyle
    • SCEDI::DiagramElement.sharedStyleRef
    • SCEDI::DiagramElement.localStyle
    • SCEDI::Style.labelHorizontalAlignement
  • Reported: SCE 1.0b1 — Fri, 2 Feb 2024 20:38 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    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.

  • Updated: Mon, 16 Sep 2024 14:12 GMT
  • Attachments:

modelElement is not optional

  • Key: SCE-111
  • Status: closed  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    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.

  • Reported: SCE 1.0b1 — Fri, 2 Feb 2024 16:13 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    Make modelElement optional

    Make modelElement optional in spec, MM & XSD.

  • Updated: Mon, 16 Sep 2024 14:12 GMT
  • Attachments:

Label should not have a redundant text attribute

  • Key: SCE-113
  • Status: closed  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    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.

  • Reported: SCE 1.0b1 — Fri, 2 Feb 2024 16:27 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    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.

  • Updated: Mon, 16 Sep 2024 14:12 GMT
  • Attachments:

XSD copied the wrong extension elements from BPMN and lacks the important ones

  • Key: SCE-99
  • Status: closed  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    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.

  • Reported: SCE 1.0b1 — Fri, 26 Jan 2024 21:56 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    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.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

Some SCE Elements are concrete instead of abstract

  • Key: SCE-103
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    During resolutions of SCE-7 and SCE-96, the three elements RootElement, KindSet, and Kind have been accidentally set as concrete but should have been abstract. In general, all SCE elements should be abstract and then specialized by concrete elements defined by the languages that are based on SCE. Some exceptions to this include concrete DI elements and the Model Artifacts (e.g., Group), which can be directly used by other languages without specializations. But that is not the case for the three classes mentioned before.

    In addition, the XSD complex types tModelArtifact, tBaseElement, tElementType, tTypedElement, and tAnnotation are not abstract although their corresponding element definitions and metamodel classes are abstract.

  • Reported: SDMN 1.0b1 — Mon, 29 Jan 2024 20:43 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    Mark abstract elements as such

    During some of the other issue resolutions, three elements, RootElement, KindSet, and Kind are set as concrete and should be abstract. In general, all SCE elements should be abstract and then specialized by concrete elements defined by the languages that are based on SCE. Some exceptions to this include concrete DI elements and the Model Artifacts (e.g., Group), which can be directly used by other languages without specializations.

    In addition, the XSD complex types tModelArtifact, tBaseElement, tElementType, tTypedElement, and tAnnotation are made abstract in correspondence to their already abstract element definitions and metamodel classes.

    sce:tModel and scedi:diagramElement are annotated with explanations why their complex types are not abstract or completely absent.

  • Updated: Mon, 16 Sep 2024 14:12 GMT
  • Attachments:

Acknowledgements for SCE 1.0 contributors needed

  • Key: SCE-92
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The acknowledgement section contains the information from the RFP, but not the FTF

  • Reported: SCE 1.0b1 — Mon, 15 Jan 2024 18:36 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    Update acknowledgements

    Add paragraphs to acknowledge the SCE contributors to section "4.1 Acknowledgements" based on taskforce membership in the FTF

  • Updated: Mon, 16 Sep 2024 14:12 GMT

There are editorial issues in the Specification

  • Key: SCE-27
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Fix all identified typos in the beta Spec, if they have not been identified in other issues

  • Reported: SCE 1.0b1 — Tue, 4 Oct 2022 18:59 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    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"

  • Updated: Mon, 16 Sep 2024 14:12 GMT
  • Attachments:

Inconsistent capitalization in humanID and aliasID compared to id

  • Key: SCE-47
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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

  • Reported: SCE 1.0a1 — Tue, 18 Jul 2023 18:58 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    Update capitalization for humanID and aliasID

    "humanID" should be changed to "humanId"
    "aliasID" should be changed to "aliasId"

  • Updated: Mon, 16 Sep 2024 14:12 GMT
  • Attachments:

expressionLanguage and typeLanguage are not optional

  • Key: SCE-67
  • Status: closed  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    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.

  • Reported: SCE 1.0b1 — Sat, 23 Dec 2023 23:31 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    Set expressionLanguage and typeLanguage to optional

    These attributes should have been set to option through SCE-52. This issue will correct it.

  • Updated: Mon, 16 Sep 2024 14:12 GMT
  • Attachments:

Not enough need for vocabulary mechanisms in SCE

  • Key: SCE-37
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    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.

  • Reported: SCE 1.0b1 — Sat, 28 Jan 2023 00:12 GMT
  • Disposition: Duplicate or Merged — SCE 1.0b2
  • Disposition Summary:

    Vocabulary refactored to KindSet in SCE-7

    Vocabularies are going to be refactored as part of issue SCE-7 in proposal SCE-8.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

Internal Relationships - various

  • Key: SCE-87
  • Status: closed  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    Error: para 2 refers to SDMNVocabulary, but it probably should be SCEVocabulary (or else the UML is wrong).

    8.4.3 RelationshipKind

    The description here & UML are repeated in 9.1 under SCE Library - is this intended - a cross-reference might be better, especially since the RelationshipKind Instances table is repeated.

  • Reported: SDMN 1.0b1 — Thu, 21 Apr 2022 22:08 GMT
  • Disposition: Duplicate or Merged — SCE 1.0b2
  • Disposition Summary:

    This issue has been fixed

    The resolution for issue SCE-37/SCE-39 fixed this typo.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

SCE Metamodel Relationships do not have labels

  • Key: SCE-3
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    to be MOF compliant

  • Reported: SCE 1.0b1 — Mon, 18 Jul 2022 19:46 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    Add Labels for all SCE Metamodel Relationships

    It is a MOF requirement that associations must be named (not just role names).

  • Updated: Mon, 16 Sep 2024 14:12 GMT
  • Attachments:

Change RelationshipKinds from a Vocabulary to a UML Enumeration

  • Key: SCE-25
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

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

  • Reported: SCE 1.0b1 — Tue, 6 Sep 2022 15:37 GMT
  • Disposition: Closed; No Change — SCE 1.0b2
  • Disposition Summary:

    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.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

SCE vocabularies should reuse MVF

  • Key: SCE-44
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Though Vocabulary in SCE would correspond to Dictionary in MVF, since SemanticElement in SCE corresponds with MVFEntry in MVF.

  • Reported: SCE 1.0a1 — Mon, 17 Jul 2023 18:52 GMT
  • Disposition: Closed; No Change — SCE 1.0b2
  • Disposition Summary:

    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.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

Consider renaming rgb to tRGB

  • Key: SCE-31
  • Status: closed  
  • Source: University of Utah ( Mr. Robert Lario)
  • Summary:

    I would suggest all acronyms be capitalized. All types start with 't'.

  • Reported: SCE 1.0b1 — Thu, 29 Dec 2022 03:33 GMT
  • Disposition: Closed; Out Of Scope — SCE 1.0b2
  • Disposition Summary:

    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.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

wrong type of element in XSD for ModelArtifact -- should be a ref

  • Key: SCE-34
  • Status: closed  
  • Source: University of Utah ( Mr. Robert Lario)
  • Summary:

    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

  • Reported: SCE 1.0b1 — Thu, 29 Dec 2022 03:47 GMT
  • Disposition: Duplicate or Merged — SCE 1.0b2
  • Disposition Summary:

    Fixed as part of SCE-81

    Fixed as part of SCE-81

  • Updated: Mon, 16 Sep 2024 14:12 GMT

suggest AlignmentKind be renamed 'tAlignmentKind'

  • Key: SCE-32
  • Status: closed  
  • Source: University of Utah ( Mr. Robert Lario)
  • Summary:

    all types should start with 't'

  • Reported: SCE 1.0b1 — Thu, 29 Dec 2022 03:36 GMT
  • Disposition: Closed; Out Of Scope — SCE 1.0b2
  • Disposition Summary:

    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.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

suggest KnownColor be renamed tKnownColor

  • Key: SCE-33
  • Status: closed  
  • Source: University of Utah ( Mr. Robert Lario)
  • Summary:

    all types should start with 't'

  • Reported: SCE 1.0b1 — Thu, 29 Dec 2022 03:39 GMT
  • Disposition: Closed; Out Of Scope — SCE 1.0b2
  • Disposition Summary:

    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.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

Unclear scope of identifiers and use of "human"

  • Key: SCE-48
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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.

  • Reported: SCE 1.0a1 — Tue, 18 Jul 2023 19:06 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    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.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

The pattern of naming association role names in the metamodel is redundant

  • Key: SCE-63
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    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.

  • Reported: SCE 1.0b1 — Mon, 18 Dec 2023 18:55 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    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"

  • Updated: Mon, 16 Sep 2024 14:12 GMT
  • Attachments:

How can other Expressions languages be used?

  • Key: SCE-62
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    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.

  • Reported: SCE 1.0b1 — Mon, 18 Dec 2023 18:51 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    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.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

Consider better Vocabulary extension / re-use model, plus specialised terms (IS-A)

  • Key: SCE-15
  • Status: closed  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    Currently, extension of a Vocabulary has to be done by creating a new instance of SCEVocabulary or a descendent, e.g. BKPMNVocabulary, that individually recreates the membership of the 'term' property of the vocabulary, including all the terms of the original vocabulary (say SCE RelationshipKinds) along with the required extension terms.

    With small vocabularies, this works, but creates a static definition that will go out of date if the top-level standard (SCE) is re-issued with new terms in say SCE RelationshipKinds. Any extension of this done by exhaustive listing of the original terms will only capture those from the older version. Normally, the intention of extension is to obtain a resulting vocabulary consisting of your extension terms plus whatever is considered to be the 'core' (original) vocabulary today - which is usually different from its first publication.

    With larger vocabularies, e.g. in the 100+ terms range, the approach is likely to be unwieldy and error-prone, as well as having the above problem.

    I suggest that the requirements we have are:

    • how to easily re-use an entire vocabulary, and extend it - recursively
    • how to do so, such that if the re-used original is updated, the downstream extended versions automatically pick this up (via tooling updates etc)
    • potentially, enable vocabulary extension with exclusion, e.g. include a vocabulary (50 terms), exclude two that don't make sense, and add 18 more.
    • document not just Vocabulary but the method of extension, in the SCE spec.

    Further requirements that could be considered:

    • enable the IS-A relationship to be asserted in vocabularies. This allows specialised forms of existing terms to be defined within a vocabulary or an extension, not just now sibling terms. For example, one could imagine the term SCE RelationshipKinds::miscellaneous being specialised into various terms specific to some domain. Or Correlation being specialised into CausalCorrelation and SpuriousCorrelation.
    • specialisation would allow the SCE 'Category' concept to be solved using just Vocabulary as well. See https://issues.omg.org/issues/lists/sdmn-ftf#issue-49088
    • whether this Vocabulary modelling approach is intended to become an OMG pattern / guidance / standard...

    A change proposal for all this would include:

    • a way of defining a vocabulary that allows re-use of an entire Vocabulary without having to exhaustively identify all the original terms, plus add one or more? extensions, plus add exclusions.
    • a way of asserting the IS-A relationship, i.e. TermA1 IS-A TermA. This should be possible within a single Vocabulary, and also from terms in an extension to those in an included Vocabulary.

    Both of these are not too hard to do, but will create breaking changes in SCE, SDMN, BKPMN, and PPMN at least.

    Finally, there is an alternative modelling pattern that John Butler has used in PPMN that specialises Vocabulary classes before defining instances. The effect of this is that a given Vocabulary can only contain (at runtime) exactly those terms defined for it, whereas the more generic pattern defined in SCE doesn't prevent wrong terms being included in a Vocabulary at runtime, because there is no static typing that prevents it. Both ways work, so a decision should be made on which pattern is preferred (or even that both could be used, with criteria given for why / when).

  • Reported: SDMN 1.0b1 — Tue, 3 May 2022 11:46 GMT
  • Disposition: Duplicate or Merged — SCE 1.0b2
  • Disposition Summary:

    Vocabularies refactored to KindSet by SCE-7

    Vocabularies are going to be refactored as part of issue SCE-7 in proposal SCE-8.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

Wrong Xrefs in text

  • Key: SCE-14
  • Status: closed  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    Section text:
    Clause 10.4 describes in detail the meta-model used to keep the layout and the look of SCE-dependent Diagrams.
    Clause 10.5 presents in tables a library of the SCE element depictions and an unambiguous resolution between a
    referenced SCE model element and its depiction.

    There is no section 10.4 or 10.5; probably the intent was to refer to 11.3 and 11.4. Proper Word Xrefs are needed...

  • Reported: SDMN 1.0b1 — Tue, 26 Apr 2022 14:48 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    Fix Xrefs in text

    In section 11.3.1
    The text "Clause 10.4" should be changed to "Clause 11.3.4"
    The text "Clause 10.5" should be changed to "Clause 11.4"

  • Updated: Mon, 16 Sep 2024 14:12 GMT

Common attributes expressionLanguage and typeLanguage are missing

  • Key: SCE-2
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    They are optional properties and can be used by multiple languages, including the original BPM+ languages.

  • Reported: SCE 1.0b1 — Tue, 5 Jul 2022 21:45 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    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.

  • Updated: Mon, 16 Sep 2024 14:12 GMT
  • Attachments:

Figure 11 Annotations Metamodel is incorrect

  • Key: SCE-28
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    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.

  • Reported: SCE 1.0b1 — Fri, 7 Oct 2022 17:25 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    Replace Figure 11

    A number of figures need to be replaced because they are inconsistent with the current version of the SCE specification

  • Updated: Mon, 16 Sep 2024 14:12 GMT
  • Attachments:

Fundamental problem - cannot represent the properties/characteristics of an Element

  • Key: SCE-46
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    ElementType seems to have no way to represent the properties of the type, and TypedElement seems to have no way to represent the values of any properties.
    All you can represent is ElementRelationships.
    8.1.3 says "entity-type “Thoroughbred Horse” that is used to specific the basic characteristics of thoroughbred horses." but there is nothing I can see that could represent those characteristics, nor their values for the Element Secretariat.

  • Reported: PPMN 1.0b1 — Tue, 18 Jul 2023 18:55 GMT
  • Disposition: Closed; No Change — SCE 1.0b2
  • Disposition Summary:

    This issue should be handled by specifications that use SCE

    The intent for SCE is just to provide the ability to identify elements that are instances and others as their types.
    Downstream languages should provide the capability of adding properties to the elements if needed.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

SemanticReference::conceptNamespace oddly named

  • Key: SCE-45
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Name is odd if it's meant to represent a specific version. For example OWL uses versionIRI for this.

  • Reported: SCE 1.0a1 — Mon, 17 Jul 2023 18:56 GMT
  • Disposition: Duplicate or Merged — SCE 1.0b2
  • Disposition Summary:

    The property conceptNamespace is being removed through SCE-7/SCE-8

    The issue resolving semantic references and kindsets removed this property, so this issue can be closed.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

SCE is not backwards compatible with the original BPM+ specs

  • Key: SCE-40
  • Status: closed   Implementation work Blocked
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    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

  • Reported: SCE 1.0b1 — Tue, 7 Mar 2023 21:48 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    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.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

Incorrect Mapping from Metamodel to XSD

  • Key: SCE-35
  • Status: closed   Implementation work Blocked
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    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.

  • Reported: SCE 1.0a1 — Tue, 17 Jan 2023 22:55 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    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.

  • Updated: Mon, 16 Sep 2024 14:12 GMT
  • Attachments:

The description of Import in the Spec needs updating

  • Key: SCE-36
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    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.

  • Reported: SCE 1.0b1 — Fri, 27 Jan 2023 23:57 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    Update the description of Import in the Spec

    Correct some inaccuracies in the description in Table 16.
    Mostly deleting irrelevant information.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

Category class - various

  • Key: SCE-9
  • Status: closed  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    Section 8.2.3 first para,
    TYPO: "A Category, which have user-defined semantics" have -> has

    Figure 12 caption
    TYPO: ".. a Groups referencing Categories ..."

    General comment: Categories, as described and illustrated in the examples seems like a terminological device, very similar to vocabularies. If vocabularies were not flat, i.e. items could relate to other items via the IS-A (subsumption) relation, then the effect of Categories could be achieved just by allowing SCEElements to have SemanticReferences as their categories / classifiers. Any vocabulary that is extensible, e.g. RelationshipKind is in reality likely to be extended with both new top-level terms and specialised forms of some of the existing terms.

    John Butler (09-04-2022): Good point. Could just use SemanticReference as the type of the property “category” on SCEElement and then it could be as rich as one would want.

    Property RelationshipDirection:
    ERROR: the backward and none enumeration literals have the same definition.

  • Reported: SDMN 1.0b1 — Thu, 21 Apr 2022 22:06 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    Fix typos related to Category

    Fix typos as identified in the issue.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

Move definition of instance elements to PMN

  • Key: SCE-42
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    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.

  • Reported: SCE 1.0b1 — Wed, 22 Mar 2023 16:11 GMT
  • Disposition: Closed; No Change — SCE 1.0b2
  • Disposition Summary:

    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.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

SCERootElement.id definition mandatory but optional

  • Key: SCE-12
  • Status: closed  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    The definition of id: String [1] is:
    This attribute is used to uniquely identify a SCERootElement. The id is REQUIRED if this element is referenced or intended to be referenced by something else. If the element is not currently referenced and is never intended to be referenced, the id MAY be omitted.

    This seems a problematic definition for a mandatory attribute...

  • Reported: SDMN 1.0b1 — Thu, 21 Apr 2022 21:58 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    Make SCERootElement.id optional

    The id is currently mandatory but the definition describes it as optional.
    To fix this conflict, the id will be set to optional ([0..1]) but with explanation that is must be used if the element is referenced by another element.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

Semantic Reference mixes too many use cases

  • Key: SCE-7
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The Semantic Reference mixes the use cases of referencing an external concept and defining a kind in an extensible set of kinds.

  • Reported: SCE 1.0b1 — Wed, 25 May 2022 23:33 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    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.

    • SCEKindSet will include a kind relationship to the new class Kind [0..*]
    • Add a new class Kind that specializes SCERootElement (not SCEElement as SemanticReference did)
      • Include a conceptReference (URI) property since it does not get the property from SCEElement. We still need to connect Kinds to external definitions.

    Use of KindSets for example in SDMN

    • Languages using SCE, e.g., SDMN will have a specialization of the SCEKindSet to provide the specific context for the list of terms (e.g., ItemKindSet)
      • Redefine the “kind” association to be to the new Specialized Kind (see next)
    • Specialize Kind to provide the specific Kinds that are needed (e.g., ItemKind)
    • The class that needs the KindSet will include a relationship to the Specialized Kind and the relationship will be named “[KindName]Ref”
    • An instance library will be created for the new KindSet
    • An Informative section of the spec can show an instance diagram of the Kinds that will be a part of the new KindSet
  • Updated: Mon, 16 Sep 2024 14:12 GMT
  • Attachments:

SCEModel.category needed?

  • Key: SCE-21
  • Status: closed  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    SCEModel has an attribute category, and also inherits categoryRef from SCEElement; both of type Category. Is this intended?

    John Butler response (09-04-2022): I suspect not. Probably an oversight.

  • Reported: SDMN 1.0b1 — Thu, 21 Apr 2022 22:01 GMT
  • Disposition: Closed; No Change — SCE 1.0b2
  • Disposition Summary:

    Remove the category relationship from SCEModel

    For the purposes of backwards compatibility (with BPMN) we will leave the Category element to remain as-is. This issue can be brought up again in a later version if necessary.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

Association - TYPO

  • Key: SCE-16
  • Status: closed  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    Typo (para 1, sentence 3): 'A modeler can set the direct of the'

  • Reported: SDMN 1.0b1 — Thu, 21 Apr 2022 22:09 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    Fix the typo

    the word "direct" should be "direction"

  • Updated: Mon, 16 Sep 2024 14:12 GMT

Add Labels for all SDMN Metamodel Relationships

  • Key: SCE-4
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    to be MOF compliance

  • Reported: SCE 1.0b1 — Mon, 18 Jul 2022 19:47 GMT
  • Disposition: Closed; Out Of Scope — SCE 1.0b2
  • Disposition Summary:

    Close because this issue was submitted to the wrong Task Force

    This issue should have been submitted to the SDMN FTF.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

Blank cardinality safe to use?

  • Key: SCE-10
  • Status: closed  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    Under Conventions (and therefore likely apply to many OMG docs), it says:

    The cardinality of any content part is specified using the following operators:
    o <none> — exactly once
    o etc

    This is probably an OMG standard practice, but a blank cardinality standing for [1] is problematic, because you can't tell on a model which relationships have been fully analysed to be cardinality = [1], and which ones have not been analysed, or are in contention in a draft - and due to this, some unanalysed relationships may end up in final standards. (This probably applies to every BPM+ standard).

    John Butler comment (09-04-2022): I thought there was a UML standard for that and I used to think it was “” (0..). But I was told differently recently so I decided to go look it up and in version 2.5.1 it states “If no multiplicity is shown on the diagram, no conclusion may be drawn about the multiplicity in the model.” So I guess I’ll have to agree with you on that.

  • Reported: SDMN 1.0b1 — Thu, 21 Apr 2022 21:17 GMT
  • Disposition: Deferred — SCE 1.0b2
  • Disposition Summary:

    Defer to the RTF

    Since blank cardinality is defaulted to 1..1, the current metamodels are not inaccurate.
    However, we agree that explicitly marking them would add clarity. This can be done in an RTF.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

RootElement.name needs clarification

  • Key: SCE-13
  • Status: closed  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    Description of SCERootElement.name : String [0..1] is:

    The name attribute is a text description or label of the element. In general, the name is optional, but many elements will require a name. The definition of each specialization of SCERootElement may identify this requirement.

    The second sentence seems subjective. The final sentence one is not clear.

  • Reported: SDMN 1.0b1 — Thu, 21 Apr 2022 21:59 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    Improve description of RootElement.name

    Clarify that specializations of RootElement may require name to be mandatory.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

Unresolved ref in text

  • Key: SCE-11
  • Status: closed  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    This section contains an unresolved xref.

  • Reported: SDMN 1.0b1 — Thu, 21 Apr 2022 21:20 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    Fix unresolved reference in Section 6.6

    The text now reads: see the section entitled “Error! Reference source not found.” Section 7 "Overview" should be referenced.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

Adjust the structural elements of SCE such that they are backwards compatible with BPMN, CMMN, and DMN.

  • Key: SCE-1
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

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

  • Reported: SCE 1.0b1 — Tue, 5 Jul 2022 21:41 GMT
  • Disposition: Duplicate or Merged — SCE 1.0b2
  • Disposition Summary:

    Backwards compatibility is being handled by SCE-40/SCE-41

    Another issue was generated on this topic and a proposal is in progress that will duplicate any resolution for this issue.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

Add Notations for Relationship Kinds in SCE

  • Key: SCE-6
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    This will ensure that all downstream languages will use the same notation if they have connectors based on the RelationshipKinds.

  • Reported: SCE 1.0b1 — Wed, 27 Jul 2022 22:27 GMT
  • Disposition: Deferred — SCE 1.0b2
  • Disposition Summary:

    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.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

Reconsider dependency of SCE on other BPM+ specs

  • Key: SCE-18
  • Status: closed  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    The scope of SCE is documented as follows:

    The primary goal of SCE is to provide a set of structural elements that are common to other OMG specifications. The proposed specifications, BKPMN, PPMN, and SDMN, are structured to be dependent on the elements defined in SCE.

    It's unusual that a more foundational spec mentions the dependencies other specs have on it, even if it was originally derived / extracted from such specs. These are likely to be fragile references in the long term, and don't (as far as I can see) add anything useful to the spec. The BKPMN etc specs of course have to mention SCE in their dependencies.

    Whether BPM+ even needs to be mentioned as a dependency is a question in my mind - if SCE provides general capabilities, it is surely useable for all kinds of things, e.g. MDMI.

    Additionally, I might have expected that the SCE model wasn't just defined as 'common things to BKPMN, SDMN and PPMN', but in terms of some coherent capabilities, e.g. 'a simple meta-modelling language' or so. IN section 8.1.5 it is stated that SCE is likely to be used as a basis for building models in languages utilising SCE.

    John Butler response (09-04-2022): Agree with all that. Though I will say that others might ask why we didn’t just use one of the other OMG languages already out there. The fact that the BPM+ languages including BPMN, CMMN and DMN have similar elements is what kind of drove us to this.

    Proposed change:
    consider a more definitional description of what SCE is about, rather than just a collection of elements common to BKPMN etc. Reduce / remove direct conceptual dependency of SCE on those specs such that SCE may serve a more generic purpose within OMG specfications.

  • Reported: SDMN 1.0b1 — Thu, 21 Apr 2022 21:13 GMT
  • Disposition: Deferred — SCE 1.0b2
  • Disposition Summary:

    This type of narrative issue should be deferred to the RTF

    Given the number of technical issues that need to be addressed, this type of narrative issue, which won't fundamentally change the content of the specification, should be deferred

  • Updated: Mon, 16 Sep 2024 14:12 GMT

Terms should not be defined in terms of CMMN, BPMN artefacts, but as self-standing concepts

  • Key: SCE-19
  • Status: closed  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    Terms like Case, DataItem, DataState etc are all defined as elements of CMMN, SDMN etc. E.g. 'Case' = 'A CMMN element....'.

    Proposed change:
    Terms like 'Case' etc should have standard definitions that do not need to refer to some model like CMMN. I think every term in the glossary could be improved by removing these model / standard references.

    Even better, a common glossary could be created for all of BPM+, and either published as a separate doc, or included by reference in each BPM+ doc.

    John Butler response: Agreed. Yes, I’m thinking that perhaps a companion, non-normative document could be created to discuss the genesis of the language. A reference to that document wouldn’t be fragile and the contents could be updated without requiring update to this spec.

  • Reported: SDMN 1.0b1 — Thu, 21 Apr 2022 21:15 GMT
  • Disposition: Deferred — SCE 1.0b2
  • Disposition Summary:

    Defer to the RTF

    We agreed that we will defer for now.
    Also a full BPM+ glossary or companion guide would be useful and should be provided at some point.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

Consider removing references to BKPMN etc

  • Key: SCE-20
  • Status: closed  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    It is not clear why there are references specifically to e.g. BKPMN, SDMN, or even BPM+.

    Proposed change:
    Why not just say 'classes outside this model' in places where BKPMN etc classes are mentioned.

    John Butler response (09-04-2022): Same reason as above generally but I agree that this should be removed.

  • Reported: SDMN 1.0b1 — Thu, 21 Apr 2022 21:19 GMT
  • Disposition: Deferred — SCE 1.0b2
  • Disposition Summary:

    Defer to the RTF

    We have accepted that this should be done, but it can wait until the RTF.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

SCE Relationship Kinds Should Cover All BPM+ Relationships

  • Key: SCE-22
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    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.

  • Reported: SCE 1.0b1 — Mon, 8 Aug 2022 20:20 GMT
  • Disposition: Deferred — SCE 1.0b2
  • Disposition Summary:

    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.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

Add Mapping of SCE Term functions to MVF in Spec

  • Key: SCE-23
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The changes to the current SCEVocabulary models should be mapped to MVF.

  • Reported: SCE 1.0b1 — Tue, 30 Aug 2022 20:13 GMT
  • Disposition: Deferred — SCE 1.0b2
  • Disposition Summary:

    Defer to the RTF

    This mapping will be useful but it is something that can wait until the RTF.

  • Updated: Mon, 16 Sep 2024 14:12 GMT