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

Specification Common Elements (SCE) 1.0 FTF — Open Issues

  • Key: SCE
  • Issues Count: 37
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
SCE-48 Unclear scope of identifiers and use of "human" SCE 1.0a1 open
SCE-47 Inconsistent capitalization in humanID and aliasID compared to id SCE 1.0a1 open
SCE-46 Fundamental problem - cannot represent the properties/characteristics of an Element PPMN 1.0b1 open
SCE-45 SemanticReference::conceptNamespace oddly named SCE 1.0a1 open
SCE-44 SCE vocabularies should reuse MVF SCE 1.0a1 open
SCE-40 SCE is not backwards compatible with the original BPM+ specs SCE 1.0b1 open
SCE-42 Move definition of instance elements to PMN SCE 1.0b1 open
SCE-28 Replace Incorrect Metamodel Figure SCE 1.0b1 open
SCE-12 SCERootElement.id definition mandatory but optional SCE 1.0b1 open
SCE-21 SCEModel.category needed? SCE 1.0b1 open
SCE-16 Association - TYPO SCE 1.0b1 open
SCE-4 Add Labels for all SDMN Metamodel Relationships SCE 1.0b1 open
SCE-15 Consider better Vocabulary extension / re-use model, plus specialised terms (IS-A) SCE 1.0b1 open
SCE-37 Not enough need for vocabulary mechanisms in SCE SCE 1.0b1 open
SCE-7 Modify the Semantic Reference Capability in SCE SCE 1.0b1 open
SCE-36 Update the description of Import in the Spec SCE 1.0b1 open
SCE-35 Refactor SCE XSDs based updated method of translating from UML Metamodel Diagrams SCE 1.0a1 open
SCE-25 Change RelationshipKinds from a Vocabulary to a UML Enumeration SCE 1.0b1 open
SCE-34 wrong type of element in XSD for ModelArtifact -- should be a ref SCE 1.0b1 open
SCE-33 suggest KnownColor be renamed tKnownColor SCE 1.0b1 open
SCE-32 suggest AlignmentKind be renamed 'tAlignmentKind' SCE 1.0b1 open
SCE-31 Consider renaming rgb to tRGB SCE 1.0b1 open
SCE-27 Fix Typos in Spec SCE 1.0b1 open
SCE-6 Add Notations for Relationship Kinds in SCE SCE 1.0b1 open
SCE-22 SCE Relationship Kinds Should Cover All BPM+ Relationships SCE 1.0b1 open
SCE-23 Add Mapping of SCE Term functions to MVF in Spec SCE 1.0b1 open
SCE-20 Consider removing references to BKPMN etc SCE 1.0b1 open
SCE-19 Terms should not be defined in terms of CMMN, BPMN artefacts, but as self-standing concepts SCE 1.0b1 open
SCE-18 Reconsider dependency of SCE on other BPM+ specs SCE 1.0b1 open
SCE-14 Wrong Xrefs in text SCE 1.0b1 open
SCE-13 SCERootElement.name documentation SCE 1.0b1 open
SCE-11 Unresolved ref in text SCE 1.0b1 open
SCE-10 Blank cardinality safe to use? SCE 1.0b1 open
SCE-9 Category class - various SCE 1.0b1 open
SCE-3 Add Labels for all SCE Metamodel Relationships SCE 1.0b1 open
SCE-2 Move the default expression and default type properties from SDMN to SCE SCE 1.0b1 open
SCE-1 Adjust the structural elements of SCE such that they are backwards compatible with BPMN, CMMN, and DMN. SCE 1.0b1 open

Issues Descriptions

Unclear scope of identifiers and use of "human"

  • Key: SCE-48
  • Status: open  
  • Source: agnos.ai UK Ltd ( 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
  • Updated: Tue, 18 Jul 2023 19:06 GMT

Inconsistent capitalization in humanID and aliasID compared to id

  • Key: SCE-47
  • Status: open  
  • Source: agnos.ai UK Ltd ( 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
  • Updated: Tue, 18 Jul 2023 18:58 GMT

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

  • Key: SCE-46
  • Status: open  
  • Source: agnos.ai UK Ltd ( 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
  • Updated: Tue, 18 Jul 2023 18:55 GMT

SemanticReference::conceptNamespace oddly named

  • Key: SCE-45
  • Status: open  
  • Source: agnos.ai UK Ltd ( 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
  • Updated: Mon, 17 Jul 2023 18:56 GMT

SCE vocabularies should reuse MVF

  • Key: SCE-44
  • Status: open  
  • Source: agnos.ai UK Ltd ( 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
  • Updated: Mon, 17 Jul 2023 18:52 GMT

SCE is not backwards compatible with the original BPM+ specs

  • Key: SCE-40
  • Status: open   Implementation work Blocked
  • Source: BPM Advantage Consulting ( 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
  • Updated: Wed, 22 Mar 2023 16:15 GMT

Move definition of instance elements to PMN

  • Key: SCE-42
  • Status: open  
  • Source: BPM Advantage Consulting ( 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
  • Updated: Wed, 22 Mar 2023 16:11 GMT

Replace Incorrect Metamodel Figure

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

    Replace Figure 11 Annotations, which shows the older version of SCEElement.

  • Reported: SCE 1.0b1 — Fri, 7 Oct 2022 17:25 GMT
  • Updated: Mon, 13 Mar 2023 19:37 GMT

SCERootElement.id definition mandatory but optional

  • Key: SCE-12
  • Status: open  
  • 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: SCE 1.0b1 — Thu, 21 Apr 2022 21:58 GMT
  • Updated: Tue, 7 Mar 2023 18:10 GMT

SCEModel.category needed?

  • Key: SCE-21
  • Status: open  
  • 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: SCE 1.0b1 — Thu, 21 Apr 2022 22:01 GMT
  • Updated: Thu, 2 Feb 2023 01:00 GMT

Association - TYPO

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

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

  • Reported: SCE 1.0b1 — Thu, 21 Apr 2022 22:09 GMT
  • Updated: Thu, 2 Feb 2023 01:00 GMT

Add Labels for all SDMN Metamodel Relationships

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

    to be MOF compliance

  • Reported: SCE 1.0b1 — Mon, 18 Jul 2022 19:47 GMT
  • Updated: Thu, 2 Feb 2023 01:00 GMT

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

  • Key: SCE-15
  • Status: open  
  • 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: SCE 1.0b1 — Tue, 3 May 2022 11:46 GMT
  • Updated: Tue, 31 Jan 2023 21:34 GMT

Not enough need for vocabulary mechanisms in SCE

  • Key: SCE-37
  • Status: open  
  • Source: BPM Advantage Consulting ( 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
  • Updated: Tue, 31 Jan 2023 21:34 GMT

Modify the Semantic Reference Capability in SCE

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

    More details to follow

  • Reported: SCE 1.0b1 — Wed, 25 May 2022 23:33 GMT
  • Updated: Tue, 31 Jan 2023 21:34 GMT

Update the description of Import in the Spec

  • Key: SCE-36
  • Status: open  
  • Source: BPM Advantage Consulting ( 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
  • Updated: Fri, 27 Jan 2023 23:57 GMT

Refactor SCE XSDs based updated method of translating from UML Metamodel Diagrams

  • Key: SCE-35
  • Status: open  
  • Source: BPM Advantage Consulting ( 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
  • Updated: Tue, 24 Jan 2023 20:49 GMT

Change RelationshipKinds from a Vocabulary to a UML Enumeration

  • Key: SCE-25
  • Status: open  
  • Source: BPM Advantage Consulting ( 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
  • Updated: Mon, 9 Jan 2023 20:56 GMT

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

  • Key: SCE-34
  • Status: open  
  • Source: University of Utah ( 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
  • Updated: Thu, 29 Dec 2022 03:47 GMT

suggest KnownColor be renamed tKnownColor

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

    all types should start with 't'

  • Reported: SCE 1.0b1 — Thu, 29 Dec 2022 03:39 GMT
  • Updated: Thu, 29 Dec 2022 03:39 GMT

suggest AlignmentKind be renamed 'tAlignmentKind'

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

    all types should start with 't'

  • Reported: SCE 1.0b1 — Thu, 29 Dec 2022 03:36 GMT
  • Updated: Thu, 29 Dec 2022 03:36 GMT

Consider renaming rgb to tRGB

  • Key: SCE-31
  • Status: open  
  • Source: University of Utah ( 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
  • Updated: Thu, 29 Dec 2022 03:33 GMT

Fix Typos in Spec

  • Key: SCE-27
  • Status: open  
  • Source: BPM Advantage Consulting ( 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
  • Updated: Tue, 4 Oct 2022 19:00 GMT

Add Notations for Relationship Kinds in SCE

  • Key: SCE-6
  • Status: open  
  • Source: BPM Advantage Consulting ( 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
  • Updated: Tue, 6 Sep 2022 15:38 GMT

SCE Relationship Kinds Should Cover All BPM+ Relationships

  • Key: SCE-22
  • Status: open  
  • Source: BPM Advantage Consulting ( 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
  • Updated: Tue, 6 Sep 2022 15:38 GMT

Add Mapping of SCE Term functions to MVF in Spec

  • Key: SCE-23
  • Status: open  
  • Source: BPM Advantage Consulting ( 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
  • Updated: Tue, 30 Aug 2022 20:13 GMT

Consider removing references to BKPMN etc

  • Key: SCE-20
  • Status: open  
  • 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: SCE 1.0b1 — Thu, 21 Apr 2022 21:19 GMT
  • Updated: Thu, 28 Jul 2022 21:21 GMT

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

  • Key: SCE-19
  • Status: open  
  • 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: SCE 1.0b1 — Thu, 21 Apr 2022 21:15 GMT
  • Updated: Thu, 28 Jul 2022 21:21 GMT

Reconsider dependency of SCE on other BPM+ specs

  • Key: SCE-18
  • Status: open  
  • 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: SCE 1.0b1 — Thu, 21 Apr 2022 21:13 GMT
  • Updated: Thu, 28 Jul 2022 21:20 GMT

Wrong Xrefs in text

  • Key: SCE-14
  • Status: open  
  • 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: SCE 1.0b1 — Tue, 26 Apr 2022 14:48 GMT
  • Updated: Thu, 28 Jul 2022 21:18 GMT

SCERootElement.name documentation

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

    Description of 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: SCE 1.0b1 — Thu, 21 Apr 2022 21:59 GMT
  • Updated: Thu, 28 Jul 2022 21:17 GMT

Unresolved ref in text

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

    This section contains an unresolved xref.

  • Reported: SCE 1.0b1 — Thu, 21 Apr 2022 21:20 GMT
  • Updated: Thu, 28 Jul 2022 21:17 GMT

Blank cardinality safe to use?

  • Key: SCE-10
  • Status: open  
  • 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: SCE 1.0b1 — Thu, 21 Apr 2022 21:17 GMT
  • Updated: Thu, 28 Jul 2022 21:16 GMT

Category class - various

  • Key: SCE-9
  • Status: open  
  • 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: SCE 1.0b1 — Thu, 21 Apr 2022 22:06 GMT
  • Updated: Thu, 28 Jul 2022 21:15 GMT

Add Labels for all SCE Metamodel Relationships

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

    to be MOF compliant

  • Reported: SCE 1.0b1 — Mon, 18 Jul 2022 19:46 GMT
  • Updated: Mon, 18 Jul 2022 19:46 GMT

Move the default expression and default type properties from SDMN to SCE

  • Key: SCE-2
  • Status: open  
  • Source: BPM Advantage Consulting ( 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
  • Updated: Tue, 5 Jul 2022 21:45 GMT

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

  • Key: SCE-1
  • Status: open  
  • Source: BPM Advantage Consulting ( 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.
    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
  • Updated: Tue, 5 Jul 2022 21:41 GMT