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.

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.

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.

The current SDMN XSDs were developed with a faulty translation of UML class relationships to the XSD elements.
To resolve this issue we need to specify the XSD patterns that correspond to the UML class relationships and then update the XSDs.

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

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.

The metamodel describes tag as list of strings but the XML schema has just a single string. Also the name does not indicate a list.

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.

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

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

Many SCE classes include "SCE" as a prefix (e.g., "SCEModel"). This is not necessary for the UML metamodel and is redundant in the XML schema since elements are marked with namespaces.

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

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.

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.

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.

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

to be MOF compliant

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.

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.

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.

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.

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.

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

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

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

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.

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.

if this is to be the target of using substitutionGroup, then

<xsd:element name="modelArtifact" type="sce:tModelArtifact" minOccurs="0" maxOccurs="unbounded">

should be:

<xsd:element ref="sce:ModelArtifact" minOccurs="0" maxOccurs="unbounded"/>

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

all types should start with 't'

all types should start with 't'

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

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

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.

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

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

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

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.

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.

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

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

to be MOF compliance