We have received lots of complaints about the acronym "BKPMN" from a lot of sources. The name is hard to remember, hard to pronounce, breaks the 4-letter acronym pattern, and can be confused with BPMN. It can also easily be misspelled as seen in several parts of the spec and even in this issue description.

SCE is replacing the SCEVocabulary element with the SCEKindSet element (and related elements).
SDMN uses the vocabulary mechanism and thus will need to be updated appropriately.

Update the spec, metamodels, and xsds.

Update the spec, metamodels, and xsds.

This issue will collect all the typos and resolve them in one issue for Ballot 1.

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

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

to be MOF compliant

to be MOF Compliant

The first sentence in the section lists the SCE Diagram shapes, not the BKPMN Diagram shapes.
The sentence above Table 67 and the header for Table 67 use the term "Data Items" (from SDMN), but should say "BKPMN Diagram Elements"

Text in the description doesn't match the contents of the section. There are too many items referenced.
The text "BKPMNEdge can be used to represent an Ownership Connector, Parent-Child Connector, Relationship Connector, or a Data Association." includes elements not in the section. Only the Relationship Connector is in the section.

Both background and some arrows (e.g. BPMN -> DMN) are black or near black.

It has unnamed Associations and Properties which are not permitted

The spec doesn't clearly specify the constraints on the types of items that can be imported for a BKPMN model.

The current BKPMN 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.

OperationalDocumentRef properties are mismatched between the metamodel diagrams, the descriptive table, and the XSD

BKPMN has a lot of metadata intended to provide information about the contents of the package (i.e., the label on the box). All the metadata elements should be reviewed with the goal of simplifying the V1.0 version of the spec and to include only the essential metadata.

SCE is replacing the SCEVocabulary element with the SCEKindSet element (and related elements).
BKPMN uses the vocabulary mechanism and thus will need to be updated appropriately.

And to make clear that Parties is a component of the knowledge package.

This seems like another place where unnecessarily constraining formal modelling as been used. I would have expected something more like a resource model with multiple descriptive meta-data items of standard types (i.e. String Uri, Date etc), e.g. what we have in openEHR - https://specifications.openehr.org/releases/BASE/latest/resource.html#_resource_package .

I would expect to see formal models of these classes at the BPMN/CMMN levels, and / or SDMN, and for BKPMN possibly to just have the ability to extract a total set of data items from the constituent plans.

The section header is 'Determining Applicability' - is this correct?

According to the documentation, Applicability appears to be a computational model of entry or pre-conditions to be matched when determining applicable plans at runtime. Such conditions would normally be defined on the plans themselves. I would expect just a documentary description of applicability at the BKPKMN package level.

I would expect to see a process like that shown in Figure 18 (Process for Determining the Applicability of a BKPMN Package) to be defined in BPMN and CMMN, not BKPMN.

Based on the documentation, 'Metric' would be a more obvious name for this class. The word 'Measure' is usually associated with units of measure.

Similar comment as for Effect - is this really relevant at the BKPMN package level, rather than at the level of constituent plans?

It is not clear why a BKPMN package would need 'Effect' elements - are they meant to document post-conditions of the execution of a BPMN plan? If so, they should be built into the plan definition, not into the containing package. A containing package could have more than one plan...

Description says: An Effect is some change to the environment or data that may occur when the behaviors of BPM+ Knowledge Package is performed. The bold part implies that a change in pretty much anything can be an 'effect'. Possibly something like 'change to a state variable within the case (entity or system) on which a workflow is executing' might be better.

Attributes like eventRef, impactKindRef etc would seem to be replicating what are likely to be goals or post-conditions stated within BPMN or CMMN plans contained within a BKPMN package. Is this the intention? If multiple plans are grouped together in one BKPMN package, is the set of events/milestones, impacts etc obtained by summing all such elements from the constituent plans?

The approach to defining kinds of knowledge element using subclassing seems likely to be fragile in the longer term - each time a new subtype is needed, the standard has to be re-issued. I don't see any obvious logic or theoretical basis for the collections of types Applicability, Effect, LifecycleEvent, Measure, RiskFactor, and Recommendation.

It seems to me that Applicability, Effect, Impact, etc should just be kinds of documentation rather than structurally modelled items. And they probably should not be fixed either - different BPMN / CMMN plans will have different ways of documeting things.

It is not clear from the description of this class what the purpose of 'instances' in a BKPMN package is. If the model were a BPM+ workflow + DMN logic, are the instances example (or real) runs?

Class BKPMNModel attributes:

purpose: has its own type Purpose. Couldn't the purpose be included in inherited documentation? I would have expected that there could have been an attribute SCEElement.purpose: Documentation might have been just as good, and one less class.
manifest: is the manifest not generatable from the structure? Maintaining a separate documentary manifest is likely to duplicate and become inconsistent w.r.t. the Model structure.

Class BKPMNModelPackage has 6 attributes in addition to those inherited from SCEModelPackage. Is it clear that these attributes are not more generally applicable, and could be included at the SCE level?

Attributes:

completed: might not be easy to maintain; the approach we use is semver.org, and sub-v1.0.0 versions for drafts, and for later major versions, v2.0.0-rc17 versoin strings.
published: attribute likely to be difficult to maintain. The rules for maintaining this attribute value in sync with the version and versionDate attributes are somewhat arcane.
jursidiction: This attribute defines the countries or other areas (such as states) where the BKPMNModelPackage is in effect.
likely to be problematic to keep up to date. Attributes to do with use of models should not normally be in said models
effectivePeriodStard, effectivePeriodEnd: for similar reasons, likely to be difficult to establish values and difficult to maintain over time.

It would appear from the documentation that the completed, published, version and versionDate attributes are really trying to express phases of an artefact lifecycle, but in a complex way. It would be much better to create a lifecycleState attribute and define its state machine. A model for doing this can be found at https://specifications.openehr.org/releases/AM/latest/Identification.html#_lifecycle_model (openEHR Archetype Identification specification).

With respect to the effectivePeriodxx attributes, what does 'in effect' mean? For whom? Org A may stop using a particular package, while Org B uses it for another 2 years. Or is the idea that the dates are set centrally? By whom?

Generally speaking, an approach that explicitly models lifecycleState, and incorporates release management (i.e. the idea of target publishable versions), plus a disciplined version naming scheme based on semver.org will probably work better than trying to maintain the above attributes within instance data.

Fig 5 UML - classes like OrderSetHandlerRef, QuestionnaireHandlerRef, DevelopmentMethod seem very specific and possibly project / context specific. Is the BKPMN model reaching a bit too far in its early stages?