Both background and some arrows (e.g. BPMN -> DMN) are black or near black.
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.
As part of the simplification of SDMN, remove this class. This is in line with removing DataState and Location.
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
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.
The legend is redundant and not needed in the specification examples.
An arrowhead would make the connector consistent with the CompositionConnector and would make the source and target DataItems clearer.
The spec doesn't clearly specify the constraints on the types of items that can be imported for an SDMN model.
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.
The DataItem markers for "locked" and "hidden" do not have any semantic backing. This should either be defined or they should be removed.
The spec should have more descriptions of how SDMN can be used by the other languages. This might affect some SDMN structures.
This issue is to collect any typos found during the FTF.
It should be one of the last issues resolved and balloted.
SCE will be changing its packaging structure, thus, SDMN will need to change its similar structures.
The shared data model element introduces an extra layer that is not needed and complicates the serialization of models.
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.
Update copyright section
Update the years of contribution based on OMG-recognized contributors and taskforce membership.
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.
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.
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.
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.
In the diagram, it looks like some of connectors provide inconsistent or conflicting relationships.
The application of resolutions for previous issues missed a few things and there are some general editorial problems that still need fixing.
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
tbd.
XSD Chapter Outdated with incorrect text that was copied from the DMN specification.
The Annotation class, an abstract class, is no longer necessary since Documentation and Category are no longer subclassing it. With only Attachment subclassing Annotation, it provides no value. It also adds additional structural overhead that is not needed. Further, using the name "Annotation" conflicts with downstream language PPMN that want to use it for an unrelated language element.
During resolutions of SCE-7 and SCE-96, the three elements RootElement, KindSet, and Kind have been accidentally set as concrete but should have been abstract. In general, all SCE elements should be abstract and then specialized by concrete elements defined by the languages that are based on SCE. Some exceptions to this include concrete DI elements and the Model Artifacts (e.g., Group), which can be directly used by other languages without specializations. But that is not the case for the three classes mentioned before.
In addition, the XSD complex types tModelArtifact, tBaseElement, tElementType, tTypedElement, and tAnnotation are not abstract although their corresponding element definitions and metamodel classes are abstract.
The description of the import element was copied from BPMN and contains information that are not appropriate to SCE, which is an infrastructure specification and not specific to any modeling language.
Note that this text was updated by SCE-36, but the update was not comprehensive enough
Theoretically, SCEDI should be able to be re-used by other BPM+ languages (e.g., SDMN) without the other language creating simple marker classes that do not extend the SCE classes. However, SCEDI was developed with abstract classes. If these classes were changed to concrete, the other languages can remove their unnecessary classes from their languages.
