The Kinds should be instances of Kind from SCE not instances of UML InstanceSpecification. It needs to be converted from UML to use the SCE metamodel itself. See SCE model files for an example. Pete Rivett has XSLT to automate this.

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

Basically all lines between model elements in all the BPM+ models (BPMN, CMMN, DMN, SDMN, BKPMN, Parties, and PPMN) should be (theoretically maybe) derived from one of the SCE Relationship Kinds.
And if we define the basic notation for each of these relationships, then all subsequent models will provide consistent relationship notations.

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.

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.

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.

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.

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