The spec should have more descriptions of how SDMN can be used by the other languages. This might affect some SDMN structures.

Defer to the RTF

There are examples and specification text needed to describe how SDMN can be used by other BPM+ languages, particularly the legacy ones of BPMN, CMMN, and DMN. There may be some extensions to BPMN (for example) needed, but since there are no metamodel or schema changes required for SDMN, we will defer until the RTF.

The current Data Associations (as well as those in BPMN) allow mapping between two data structures. But there are situations where 2 or more structures should be mapped to another structure. This capability should be added to SDMN. This may involve some signification metamodel adjustments.

Defer to the RTF

This is a useful capability, but it not something we can apply at this time. We will Defer.

BPMN Messages are similar to Data Objects. In a sense, they are the Data Objects between Pools. And they can have data structures as well.

Defer to the RTF

No time to do this right now if it is to be done.

tbd.

Remove MultiplicityKind from ItemDefinition

Remove the multiplicityKind attribute from the ItemDefinition element.

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

Update Copyright section

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

The application of resolutions for previous issues missed a few things and there are some general editorial problems that still need fixing.

Fix Additional Editorial Issues

Here is a brief description of the specification changes:

• The Scope section is updated to match the style of content in the Overview section
• In The SDMN Metamodel Color coding table: remove references to DMN-13 as should have been done for SDMN-87) this includes a figure replacement with attached figure
• In Section 10.1 DataItems; fix third paragraph incomplete sentence
• The isCollection attribute is added to the DataItem attribute table and XSD (it had been left off during the resolution of SDMN-99)
• The Folder itemKind references child and parent attributes of a DataItem that do not exist. that text is removed.
• Section 10.2.1 the text "the left boundary of" is used twice, but it is unnecessary and should be removed.
• Section 10.3.5 during the resolution of SDMN-95, text was inadvertently added but should be removed.
• The mapping to BPM+ table (Section 11) had inaccurate listing for multiplicity and was lacking isCollection
• The multiplicity mapping to BPMN is removed since it is not needed (isCollection already is used by BPMN)
• In the CMMN ItemKind mapping (section 11), fixed references to incorrect elements and properties.
• The multiplicity mapping to DMN is removed since it is not needed (isCollection already is used by DMN)
• Section 14.3.1: fixed incorrect clause references and removed duplicated sentences.
• Section 15.2 XSD: replace named attribute "namespace", which doesn't exist, with "targetNamespace", which does.
• The notation section for multiplicity/collection indicator should also mention isCollection

itemKind is meant to define the nature of the DataItem.

In the current version, itemKind is erroneously an attribute of the ItemDefinition, it should be an attribute of the DataItem.

The itemKind should be moved as an attribute of the DataItem

Move ItemKind to DataItem and Adjust Specification as Necessary

Here is a brief description of the changes:
In the Metamodel:

• The itemKind attribute was moved from the ItemDefinition element to the DataItem element
• The multiplicityKind attribute was removed from the ItemDefinition element. It is already in the DataItem element and is not needed in ItemDefinition.
• The attached figures were updated as a result of the metamodel changes

In the Specification:

• The ItemKind section was moved from the ItemDefinition chapter to the DataItem Chapter
  • Some text changes in the section were necessary as a result of the move (e.g., replacing ItemDefinition with DataItem, etc).
• The ItemKind named "DataType" was renamed to "Information" to match what is in BPMN
• The MultiplicityKind Values table mentions ItemDefinition. These mentions were removed since they no longer apply.
• Chapter 11 mapping definitions were updated

The current version for the notation depictions of SDMN Edges includes a label. There is no need for SDMN Edges to have labels and it would be confusing to have them included.

Remove label indicator from Edge depiction figures

All the figures in the Notation section for SDMNEdge (16.3.5.3) should have the label indicator removed.

In the specification section for Edge Resolutions, the two entries for the connections for ItemDefinitions does not provide enough detail to for the identification of the proper elements to be depicted.

Clarify Notation Depiction definitions for ItemDefinition Edges

Add more clarification: e.g.,
For ItemDefinition subcomponents:
(new table) Change "ItemComponent" to "itemComponent with sub-components"
For ItemDefinition references:
(new table) Change "typeRef" to "itemComponent that contains a typeRef"

In the diagram, it looks like some of connectors provide inconsistent or conflicting relationships.

Fix Connection Errors in the SDMN Diagram Example

Some connectors were replaced and others removed to fit with how containment, composition, and reference work.

SDMN inherits the import element from SCE, but it also contains its own copy of import. This is probably a left over from an earlier version of the XSD.

Remove redundant Import element from the SDMN Schema

SDMN's copy of Import should be removed.

The DataItem markers for "locked" and "hidden" do not have any semantic backing. This should either be defined or they should be removed.

Remove unnecessary DataItem Markers

we will remove the extraneous markers from the spec:

• Hidden items: no semantic backing
• Linked items: changing semantic backing, can be added later
• Locked items: no semantic backing
• With pre-assigned data: can be added later.

This mainly involves deleting table items with the notation. But it also affects the Hello Patient example used throughout the spec

This issue is to collect any typos found during the FTF.
It should be one of the last issues resolved and balloted.

Fix Specification Errors

This issue collects any typos found in the specification that can't be resolved by other issue topics.

• Remove OMG doc numbers for other specifications. We will rely on the Normative References section to show where to get the latest specifications.
• In the Normative References Section:
  • Add the path to the Diagram Definition specification in the Normative References section.
    Change the path for the SCE specification to the proper path (e.g., /SCE/ instead of /SDMN/)
• Remove redundant "OMG" prefixes to the named specifications in the Normative References section and Non-Normative References section.
• Fix this in Section 2.2: "The implementation claiming conformance to the Shared Data Modeling Conformance SHALL comply with all of the requirements set forth in Clauses 8Error! Reference source not found., 9, and 10; and it should be conformant with the Visual Notation Conformance in Clause 14." - Error!
• Section 3.1
• Section 3.2 - Remove non-normative references, they are not needed.
• Section 6.5 Abbreviations: Remove rows on BHMN, BKPMN, MDMI, MOF, PPMN, RFC, and SysMl - they is not used in the specification
• Section 6.6: update listed clauses to reflect changes in the structure of the document
• Section 7 Overview: multiple editorial changes throughout the section - mostly removing references to other specifications that have not yet been completed or are not specifically relevant to SDMN. Not all changes will be marked with a comment.
  • Replace figure 1 to remove other specifications that are not yet completed.
• Remove this in Section 11.4 Model Artifacts
  • third paragraph (just after the figure): change "Connector connection" to "connection"
  • Notation subsection, first sentence: "Full details of Model Artifacts are available in the section entitled “ElementType”, above, but the notation of the elements is provided here for convenience."
• The use of bold text for "BPM+" is inconsistent. Update text so that all instances of "BPM+" is in bold.
  This was a copy/paste error.
• In Section 10.1 DataItem:
  • remove extraneous text (including paragraphs 1, 5, and 6). just focus on defining DataItems.
  • 7th paragraph, change "ItemAwareElement" to "DataItem"
• In Section 10.1.1 DataItem, sub-section Notation: Change "The use of text, color, size, and lines for a Reference Connector SHALL follow..." to "The use of text, color, size, and lines for a DataItem SHALL follow"
• Section 10.2 remove redundant figures for CompositionConnector, ContainmentConnector, and ReferenceConnector.
• In Section 10.2.1 the table for ItemDefinition attributes, the row for muliplicityKind: change "default: ExactlyOne" to "default = ExactlyOne" (the : to =)
• In Section 11.3.4: replace figure 29, it shows markers that are no longer being used.
• Section 14 SDMN Examples. remove all references to KPMN or knowledge package.

------
The itemKind and multiplicityKind attributes were mistakenly shown as mandatory. The resolutions for Issues SCE-7 and SCE-8 required that they be optional. Thus, the following fixes are needed:

• The DataItem Metamodel figure is updated (the figure is not shown here since it will be updated by other issues)
• The third row for the DataItem Attributes and/or Associations table (for multiplicityKind) is changed from "String [1]" to "String [0..1]"
• The ItemDefinition Metamodel figure is updated (the figure is not shown here since it will be updated by other issues)
• The forth row for the ItemDefinition Attributes and/or Associations table (for multiplicityKind) is changed from "String [1]" to "String [0..1]"
• The third row for the ItemDefinition Attributes and/or Associations table (for itemKind) is changed from "String [1]" to "String [0..1]"

SCE will be changing its packaging structure, thus, SDMN will need to change its similar structures.

Update SDMN to reflect changes in SCE

SCE is dramatically simplifying many of its structures. The Issues that affect SDMN are:
SCE-40/SCE-41 - this will result in the simplification of the packaging structures in SDMN
SCE-90/SCE-95 - removed the SCE prefix from all class names

SCE-2/SCE-52 - this will result in the removal of two properties in SDMN, but this is being handled by SDMN-75
SCE-7/SCE-8 could have had an impact, but SDMN-27/SDMN-86 made changes that rendered the SCE changes irrelevant.

The shared data model element introduces an extra layer that is not needed and complicates the serialization of models.

Merge SDMNModel and SharedDataModel

SharedDataModel will be removed.
SDMNModel will be renamed to SharedDataModel.
Connectors will be now contained in the new SharedDataModel.
The spec and XSD will be changed appropriately

Through the way that SDMN defines the relationships between Data Items, it provides the capability for graphically modeling Item Definitions. In some sense, the Data Item view is a subset of the full set of Item Definitions in the model.
Since there is a market need for Item Definition modeling as well as Data Item Library modeling, adding the Item Definition View makes sense.
SDMN already provides the capability of adding additional views, so this update would not change the basic structure of SDMN.

Add notational elements for Item Definition Diagram (IDD)

SDMN will allow modeling tools to provide a standard notation for modeling ItemDefinitions, including their composition and referencing capabilities.

The legend is redundant and not needed in the specification examples.

Remove the Legend from Example diagram

The legend in the diagram is not necessary and should be removed. This diagram is used in multiple places in the specification.

An arrowhead would make the connector consistent with the CompositionConnector and would make the source and target DataItems clearer.

Add arrowhead to Containment Connector

This change will make the connector consistent with the Composition connector and will make it easier to identify the source and target of the connector.
Figures 4, 21, 26, and 35 will be changed; and the Containment Connector figure in Table 20 will be changed; and the figure in Table 43 will be changed.

As part of the simplification of SDMN, remove this class. This is in line with removing DataState and Location.

Remove ItemFormat from SDMN

As part of the simplification of SDMN, remove this class. This is similar to removing DataState, and Location.

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

Clarification constraints on SDMN Import inherited from SCE is not needed

This is considered a feature of the BPM+ specifications to allow all types of imports. E.g., because BPMN also has this feature, BPMN would be able to freely import SDMN files. Thus, we will close with no change.

The notion of Containment Connector is not needed if the Notion of Parent DataItem is not needed. If needed it should be aligned with that of UML

With Data Item Modeling this issue can be closed

Based on discussions: We agreed that both Data Item and Item Definition modeling are needed in SDMN. In that case this issue is no longer needed.

For ItemDefinitions, the reference relationship affects the content (structure) of the source ItemDefinition. For DataItems, the ReferenceConnector does not affect the structure of the source DataItem. The proposal for the graphical elements for ItemDefinition modeling plans on re-using the ReferenceConnector line. Thus, there is a conflict.
Either the ItemDefinition should use a different line style or the ReferenceConnector should be redefined.
However, based on an analysis of the definition of the ReferenceConnector it could be argued that the basic Association connector (inherited from SCE) provides the same semantic capability. Thus, the ReferenceConnector would be better to be redefined to match the semantics of the ItemDefinition reference relationship.

Redefined ReferenceConnector to match the semantics of the ItemDefinition reference relationship

For ItemDefinitions, the reference relationship affects the content (structure) of the source ItemDefinition. For DataItems, the ReferenceConnector does not affect the structure of the source DataItem. The proposal for the graphical elements for ItemDefinition modeling plans on re-using the ReferenceConnector line. Thus, there is a conflict.
Based on an analysis of the definition of the ReferenceConnector it could be argued that the basic Association connector (inherited from SCE) provides the same semantic capability. Thus, the ReferenceConnector would be better to be redefined to match the semantics of the ItemDefinition reference relationship.
Thus, when a DataItem references an ItemDefinition, it is identifying the underlying type structure. Likewise, when a DataItem references another DataItem, it is identifying one of the sub-structures for the source DataItem. Of course, the target DataItem may not yet have a referenced ItemDefinition.
The change resulted in a change to the example diagram (see attached)

The XML namespace URI of the original SDMN submission uses a dated version stamp, which if changed with each revision could lead to model interchange issues, i.e. different tools supporting different versions with incompatible XML namespaces (see also SCE-117).

In addition, the following sentence about imports was accidentally copied from DMN is invalid for SDMN:

SDMN files MAY import non-SDMN files (such as XSDs and PMMLs) if the contained elements use external
definitions.

Use fixed Namespace URI and xsi:schemaLocation

Use the fixed Namespace URI https://www.omg.org/spec/SDMN/ (without a dated version stamp as permitted by section 3.1.2 and annex A of the OMG Policy for Versioning of Specification URIs, File URIs, and XML Namespaces (smsc/2018-08-01)) and adopt the mechanism introduced by SCE-117 to allow tool interoperability between backwards-compatible SDMN versions.

In addition, an invalid sentence about imports that was accidentally copied from DMN is removed.

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

Replace Figure 1

Figure 1 did not render properly in the PDF.
Also remove the lines that represent "new standards" since they always won't be "new".
Also, add PMN to the figure since it is part of the BPM+ stack.