Shared Data Model and Notation Avatar
  1. OMG Specification

Shared Data Model and Notation — All Issues

  • Acronym: SDMN
  • Issues Count: 57
  • Description: All Issues
Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
SDMN-5 DataItem class - semantics of various properties SDMN 1.0a1 open
SDMN-1 Class DataItemRelationship no longer in UML SDMN 1.0a1 open
SDMN-2 Semantics of Connector class SDMN 1.0a1 open
SDMN-6 ItemDefinition class naming and semantics SDMN 1.0a1 open
SDMN-25 Incorrect Reference in DI text SDMN 1.0a1 open
SDMN-45 Fig 1 does not render properly in PDF SDMN 1.0b1 open
SDMN-26 Copy/Paste Errors in SDMNShape Resolution Section SDMN 1.0a1 open
SDMN-41 Add BPMN Messages to SDMN SDMN 1.0b1 open
SDMN-3 Unclear semantics of DataState class SDMN 1.0a1 open
SDMN-12 DataAssociation class named misleadingly; is it really a Connector? SDMN 1.0a1 open
SDMN-4 Semantics of Location and descendants SDMN 1.0a1 open
SDMN-13 Connector types rationalisation possible? SDMN 1.0a1 open
SDMN-29 Data item folder shape SDMN 1.0a1 open
SDMN-47 Parent DataItem (folder) SDMN 1.0a1 open
SDMN-28 Locations should not be part of SDMN SDMN 1.0a1 open
SDMN-11 Are special Folder semantics really needed for CompositionConnector and ContainmentConnector? Or at all in SDMN. SDMN 1.0a1 open
SDMN-42 Update SDMN to Reflect SCE's Moving from Vocabularies to KindSets SDMN 1.0a1 open
SDMN-31 Pre-Assigning Values for DataItems is questionable SDMN 1.0a1 open
SDMN-10 Are CompositionConnector and ContainmentConnector really different? SDMN 1.0a1 open
SDMN-62 Remove Item Format from SDMN SDMN 1.0b1 open
SDMN-49 Containment Connector SDMN 1.0b1 open
SDMN-48 Composition Connector SDMN 1.0a1 open
SDMN-50 No Notation for Item Definitions SDMN 1.0b1 open
SDMN-9 ItemDefinition.semanticReferenceRef semantics requires updating SDMN 1.0a1 open
SDMN-75 The default expression and default type properties from SDMN are redundant when SCE adds them SDMN 1.0a1 open
SDMN-88 The Legend in the DataItem Diagram Example is not necessary SDMN 1.0b1 open
SDMN-83 Add arrowhead to Containment Connector SDMN 1.0b1 open
SDMN-44 Clarify constraints on SDMN Import inherited from SCE SDMN 1.0b1 open
SDMN-103 ReferenceConnector for DataItems does not match the semantics of ItemDefinition reference relationships SDMN 1.0b1 open
SDMN-7 SDMN itemKinds - too broad, too complex, too ad hoc? SDMN 1.0a1 open
SDMN-43 Incorrect Mapping from Metamodel to XSD SCE 1.0b1 open
SDMN-8 MultiplicityKind - replace with enum SDMN 1.0a1 open
SDMN-109 There are no semantics defined for some of the DataItem markers SDMN 1.0b1 open
SDMN-27 Vocabularies should not be in SDMN SDMN 1.0a1 open
SDMN-39 SDMN metamodel is not valid MOF SDMN 1.0a1 open
SDMN-74 Integration from SDMN to BPMN, CMMN, and DMN is not clear SDMN 1.0b1 open
SDMN-70 Refactor all SDMN Elements to inherit from SCEElement instead of ElementType SDMN 1.0a1 open
SDMN-72 Unresolved ref in text SDMN 1.0a1 open
SDMN-69 There are editorial issues in the Specification SDMN 1.0b1 open
SDMN-93 There are SCE Structural changes that affect the structure SDMN SDMN 1.0b1 open
SDMN-113 SDMN has too many layers of abstraction for packaging models SDMN 1.0b1 open
SDMN-33 SDMN can be simplified to use SCEDI directly SDMN 1.0a1 open
SDMN-56 Update DMN Dependencies? SDMN 1.0a1 open
SDMN-38 SDMN Metamodel Relationships do not have labels SDMN 1.0a1 open
SDMN-81 Create Capability of Data Associations across multiple Data Items - not just one to one SDMN 1.0b1 open
SDMN-115 Copyright section needs update SDMN 1.0b1 open
SDMN-116 Acknowledgements for SDMN 1.0 contributors needed SCE 1.0b1 open
SDMN-125 Labels are not needed for SDMN Connectors SDMN 1.0b1 open
SDMN-121 Notation Depiction Definitions for ItemComponents is not clear SDMN 1.0b1 open
SDMN-119 SDMN XSD has a redundant Import element SDMN 1.0b1 open
SDMN-123 Update Copyright section BKPMN 1.0b1 open
SDMN-137 XML Namespace URI needs updating SDMN 1.0b1 open
SDMN-135 There are Connection Errors in the SDMN Diagram Example SDMN 1.0b1 open
SDMN-129 Additional Editorial Issues SDMN 1.0b1 open
SDMN-127 XSD Chapter Outdated with incorrect text BKPMN 1.0b1 open
SDMN-130 ItemKind is in the Wrong Location SDMN 1.0b1 open
SDMN-133 MultiplicityKind attribute is redundant in ItemDefinition SDMN 1.0b1 open

Issues Descriptions

DataItem class - semantics of various properties

  • Key: SDMN-5
  • Status: open  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    Various comments on the following propreties:

    dataItemRef: QName: "... A DataItem can have only one of dataItemRef or ItemDefinitionRef as a set attribute. Neither of them is required, though ..."

    ERROR? - I could not find ItemDefinitionRef within DataItem; perhaps it was meant to be ItemDefinition or metaDefinitionRef; ItemDefinition does contain ItemDefinitionRef.

    locationRef : Location [0..*] A list of potential Locations for the DataItem.

    MISSING: this provides no idea what kind of 'location' is meant here; there are technical possibilities in the descendant types, but it doesn't tell us the semantics - is the location a source-of-truth repository where an instance of the item is maintained? Locations of copies? Something else?

    preAssignment : Assignment [0..1] Specifies an optional pre-assignment DMN Expression. The expression will provide values for one or more of the simple type itemComponents of the ItemDefinition set for the DataItem.

    ERROR? I could not locate 'itemComponents' in the model - probably what is meant is DMN1-3 ItemDefinition.itemComponent (singular name, multiple cardinality).

    Proposed change:

    ItemDefinitionRef is referenced in DataItem.dataItemRef, but doesn't exist in the model. Correction needed somewhere.

    DataItem.locationRef (possibly renamed as per SDMN-4) needs to be better defined. The current definition provides no idea what kind of 'location' is meant here; there are technical possibilities in the descendant types, but it doesn't tell us the semantics - is the location a source-of-truth repository where an instance of the item is maintained? Locations of copies? Something else? Without a clearer distinction between information entities and physical ones, this might be difficult to clarify.

    DataItem.preAssignment and (other properties in the model - need to do a global search) refer to 'itemComponents', which is not defined in the model. Possibly what is meant is DMN1-3 ItemDefinition.itemComponent

  • Reported: SDMN 1.0a1 — Thu, 21 Apr 2022 14:23 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT

Class DataItemRelationship no longer in UML

  • Key: SDMN-1
  • Status: open  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    The class DataItemRelationship seems to have gone in the UML models I have. From what I can see, Connector is now a direct descendant of ElementRelationshipType.

    Aside: I would have expected this class to have a name like ConnectorType, or indeed, DataItemRelationshipType.

    The UML diagrams in the PDF spec is different from in MagicDraw.

  • Reported: SDMN 1.0a1 — Thu, 21 Apr 2022 13:22 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT

Semantics of Connector class

  • Key: SDMN-2
  • Status: open  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    SharedDataModel has property connector[0..*]: Connector

    Is the meaning of the class Connector connector types or instances? The documentation of this property is:

    This is a list of the Connectors (Composition, Containment, Reference, and Data Association) that are included in the SharedDataModel.

    It is not clear whether this is a list of possible Connector types or a list of actual Connector instances. The type Connector has outgoing relationships targetRef and sourceRef, which suggests an instance level concept; I am not sure how this relates to the idea of Connector as a specialised ElementRelationshipType, which appears to be as a definer of relationship types.

    Proposed change:

    improve documentation of SharedDataModel.connectors to clarify whether it is a list of connector types used within a model, or connector instances.

  • Reported: SDMN 1.0a1 — Thu, 21 Apr 2022 13:26 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT
  • Attachments:

ItemDefinition class naming and semantics

  • Key: SDMN-6
  • Status: open  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    SDMN ItemDefinition would seem to be a major extension of the DMN ItemDefinition class. It is documented as: "The itemDefinition element is the mechanism for providing the data structure of DataItems. It is contained within a SDMNDefinitions"

    Since SDMN is intended to be a formalism for defining data models / items in a simple way (i.e. simpler than using UML), I would not expect it to contain classes that depend on anything in DMN. If DMN were being written now, I would suggest it would reference SDMN::ItemDefinition. If there are solid semantics for the split between SDMN::ItemDefinition and DMN::ItemDefinition, I would suggest they should be preserved by modelling both within SDMN, and making future versions of DMN refer to that.

    The DMN form appears to model data items, rather than 'anything', which appears to be the scope of SDMN ItemDefinition. It is therefore not obvious to me that the inheritance is right. We might expect something more like:

    ItemDefinition (abstract)
    +--- DataItemDefinition (more or less the DMN version)
    +--- XXXItemDefinition

    where the XXXItemDefinition is various meta-classes representing e.g. document, class, - all the other kinds of itemKindRef, with appropriate meta-modelling attributes.

  • Reported: SDMN 1.0a1 — Thu, 21 Apr 2022 14:38 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT

Incorrect Reference in DI text

  • Key: SDMN-25
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The text references an SDMN element that no longer exists (or was renamed). The text reads: "All other properties that are REQUIRED for the unambiguous depiction of the SDMN element are derived from the referenced SDMN element [SDMNElementRef]."
    At the end of the sentence should read: "[SDMNDiagramElement]" instead of "[SDMNElementRef]".

  • Reported: SDMN 1.0a1 — Tue, 26 Apr 2022 16:25 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT

Fig 1 does not render properly in PDF

  • Key: SDMN-45
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

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

  • Reported: SDMN 1.0b1 — Tue, 7 Mar 2023 18:37 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT
  • Attachments:

Copy/Paste Errors in SDMNShape Resolution Section

  • Key: SDMN-26
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The first sentence in the section lists the SCE Diagram shapes, not the SDMN Diagram shapes.

  • Reported: SDMN 1.0a1 — Tue, 26 Apr 2022 17:16 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT

Add BPMN Messages to SDMN

  • Key: SDMN-41
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    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.

  • Reported: SDMN 1.0b1 — Wed, 21 Sep 2022 18:12 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT

Unclear semantics of DataState class

  • Key: SDMN-3
  • Status: open  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    Class description:
    DataItems can optionally reference a DataState element, which is the state of the data contained in the DataItem.
    The definition of these DataStates, e.g., possible values and any specific semantic are out of scope of this
    specification. Therefore, SDMN adopters can use the DataState element and the SDMN extensibility capabilities to
    define their DataStates.

    It is not clear what kind of 'states' are intended here. Is the intention that users of SDMN invent their own local lifecycle models for certain kinds of data? Since an SDMN DataItem can be literally anything, from a single Quantity to an entire document, such lifecycles could widely vary, and it is not clear that they would even apply to many kinds of DataItem.

    Proposed change:

    Suggest the description of DataItem.dataStateRef be improved, possibly with some examples.

    If the intention really is to support lifecycle states (e.g. of a document, from draft to approved, or similar) then a more comprehensive facility including a state machine or at least a set of possible states (perhaps in some DataStateType class or vocabulary) would seem to be better, since it is likely to lead to more interoperable SDMN instances.

  • Reported: SDMN 1.0a1 — Thu, 21 Apr 2022 13:38 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT

DataAssociation class named misleadingly; is it really a Connector?

  • Key: SDMN-12
  • Status: open  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    DataAssociation is a Connector type documented as:

    The DataAssociation class is a Connector and used to model how data is mapped between two DataItems. The source of the association is mapped to the target.

    The word 'association' tends to imply a UML association, i.e. the alternative to Composition.

    Additionally, a data mapping is often not 1:1, as implied by this model, which possibly indicates that it is not a Connector, but a mapping that may associate 1:N or N:N other items, with an algorithm to define the transformation.

    Further, the arrow type is not very evocative of the idea of mapping - and also not easily distinguishable from the Reference Connector arrow type.

    Proposed change
    Suggest a better name for DataAssociation class would be DataMapping or similar.

    Consider whether this class really is a Connector type, or should be understood as its own relationship.

    Improve the symbol to be more evocative of the idea of mapping.

  • Reported: SDMN 1.0a1 — Thu, 21 Apr 2022 20:27 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT

Semantics of Location and descendants

  • Key: SDMN-4
  • Status: open  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    Firstly I would expect to see Locations in the Party model, and shared by all other BPM+ specs. This is probably intended; just noting it here.

    The documentation of Location is:
    Location is an abstract class where its concrete specializations identify a particular place or position. Locations are contained within a SDMNPackage and can be referenced by DataItems.

    Better wording of the first sentence:
    Location is an abstract class whose concrete specializations identify a particular place or position.

    Semantically, it should possibly say 'a particular addressable place ...', since this part of the model is about locations that can be identified by address. There arguably should be a derived attribute, function or even data property to carry such an address. If derived, it would be a stringified form of a structural address.

    Addresses are likely to take different structural forms, e.g. street address, geo-spatial (lat/long) address, cadastral map references and so on.

    There is a sub-type for NetworkAddress, which is not a 'location' in the physical sense. I would call it a kind of address rather than a kind of location.

    On the other hand, GeoSpatialExtent is documented as: A location that is a volume in the world such as a container or a room. This is arguably a kind of location - although perhaps an object - presumably movable - is also intended. It is not clear how it is addressed. If movable things are intended, then the 'address' is some sort of identifier of the container, e.g. truck, plane, test-tube in a lab etc.

    A useful resource for thinking about some of these types is BFO2.0, which can be found here: http://gbadske.org/Files/BFO2-Reference.pdf - see p3 for the is-a hierarchy.

    Another reference is how we do this in openEHR, which separates 'place' from 'address'. See https://specifications.openehr.org/releases/UML/latest/index.html#Diagrams___19_0_3_8fe028d_1648920292880_630012_5562

    Proposed Change:

    The Locations part of the model needs to be adjusted to correctly distinguish between 'places' and 'addresses', and also between physical and informational entities. It appears that the real need of the model is to be able to form references to any kind of entity.

    It might therefore be clearer to change DataItem.locationRef to DataItem.locator, meaning a reference that can be resolved to find the target entity. The Location class could also be renamed to Locator, and the subtypes could be as follows:

    * PhysicalLocator
        * SpatialLocator - locators for entities fixed in space
            * PlaceAddress, meaning a building, site, home etc address
            * GeospatialLocator, meaning lat/long, possibly altitude as well 
            * possibly type(s) for any other common types of map / cadastral reference
        * ObjectLocator: locator for movable objects
    * DataLocator, meaning a (probably) URI resolvable to obtain a data item
    

    The type SpaceTime is not a Locator as such, it just adds a time period, presumably to indicate validity. It would be better to remove this type and add the two attributes startTime and endTiime as optional attributes in Locator.

    Properties in other classes that are currently named 'locationRef' could potentially be renamed 'locator'.

  • Reported: SDMN 1.0a1 — Thu, 21 Apr 2022 14:08 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT

Connector types rationalisation possible?

  • Key: SDMN-13
  • Status: open  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    See previous issues.

    If CompositionConnector and ContainmentConnector were collapsed to just one type, and DataAssociation was modelled as a complex N:N relationship, and ReferenceConnector considered the equivalent of a UML association (call it AssociationConnector), then we would just have:

    • CompositionConnector
    • AssociationConnector

    as descendants of Connector.

    This simplification would imply that the subtyping approach could be removed altogether, and Connector be a concrete type with a boolean such as isComposition to indicate that it is a Composition; if False, it is an association.

    The class currently called DataAssociation could be modelled as a new class Mapping, probably just inheriting from SCEElement, with multiple source items and one target i.e. an N:1 mapping, plus a transformation function taking the N source items as arguments.

  • Reported: SDMN 1.0a1 — Thu, 21 Apr 2022 20:48 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT


Parent DataItem (folder)

  • Key: SDMN-47
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    We do not believe this notion is required in SDMN but if it is proven to required the icon should not be the same as a BPMN Case Model

  • Reported: SDMN 1.0a1 — Mon, 3 Apr 2023 18:41 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT

Locations should not be part of SDMN

  • Key: SDMN-28
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Location is a physical attribute and should be left out of SDMN which should remain a Logical Data model.

  • Reported: SDMN 1.0a1 — Tue, 26 Apr 2022 19:43 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT

Are special Folder semantics really needed for CompositionConnector and ContainmentConnector? Or at all in SDMN.

  • Key: SDMN-11
  • Status: open  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    In the detailed description of both these types is the following (bullets 3 & 4):

    • If element within a folder-type DataItem container is updated (e.g., through a change in the value of a

    property), the container will not be updated. I.e., the container is not aware of changes to existing contained
    DataItems.

    • If DataItem within a non-folder-type DataItem container is updated (e.g., through a change in the value of

    a property), the container will also be updated. I.e., the container is aware of changes to contained
    DataItems.

    This seems just to be saying that Folder 'containment' of other items is not really containment, such that the containing object is not considered to be changed when a sub-part is. This is contrary to the very idea of containment, and likely indicates that Folder 'containment' should really just be referencing. If a 'Folder' is deleted for example, are all the items within it deleted? If so, this indicates that a Folder is not a reference object but a true container, and the above special logic is not needed.

    My suspicion is that the semantics of Folders is not that clear in SDMN, and knowing what SDMN's primary purpose is, it it not clear that Folder is even needed there - it seems just to be some kind of document-organising concept in CMMN. It might simplify SDMN significantly to get rid of it.

    Proposed change:
    At least the documentation of Folder needs to be improved to make the semantics clear OR perform analysis to determine if it can be removed from SDMN altogether.

  • Reported: SDMN 1.0a1 — Thu, 21 Apr 2022 20:21 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT

Update SDMN to Reflect SCE's Moving from Vocabularies to KindSets

  • Key: SDMN-42
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    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.

  • Reported: SDMN 1.0a1 — Tue, 11 Oct 2022 17:06 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT

Pre-Assigning Values for DataItems is questionable

  • Key: SDMN-31
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    The approach taken is not ideal

  • Reported: SDMN 1.0a1 — Tue, 26 Apr 2022 19:54 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT

Are CompositionConnector and ContainmentConnector really different?

  • Key: SDMN-10
  • Status: open  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    Description of CompositionConnector:

    A CompositionConnector is used to define a relationship between DataItems. This relationship will specify that

    one DataItem is contained within another DataItem. This relationship supports the composition of DataItems.

    Description of ContainmentConnector:

    A ContainmentConnector is used to define a relationship between DataItems. This relationship will specify that

    one DataItem is contained within another DataItem. This relationship supports the containment of DataItems,
    including the parent and child association that exists between CMMN CaseFileItems.

    These are effectively the same and are aiming to replicate the UML composition relationship. The detailed description given in four bullet points for each class is also the same.

    The ContainmentConnector type seems to add needless complexity, possibly to accommodate some slight difference in CMMN data object semantics? If so, this should be abstracted away in SDMN, and dealt with in some SDMN / CMMN binding layer.

    Proposed change:
    Either:

    • If the semantics of Composition and Containment are truly different, then make it clear how in the documentation.
      Or:
    • Remove ContainmentConnector from the model.
  • Reported: SDMN 1.0a1 — Thu, 21 Apr 2022 20:16 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT

Remove Item Format from SDMN

  • Key: SDMN-62
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

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

  • Reported: SDMN 1.0b1 — Mon, 2 Oct 2023 16:58 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT

Containment Connector

  • Key: SDMN-49
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    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

  • Reported: SDMN 1.0b1 — Mon, 3 Apr 2023 18:47 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT

Composition Connector

  • Key: SDMN-48
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    The definition and visualization of a Composition Connector should be aligned with that of UML

  • Reported: SDMN 1.0a1 — Mon, 3 Apr 2023 18:44 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT

No Notation for Item Definitions


ItemDefinition.semanticReferenceRef semantics requires updating

  • Key: SDMN-9
  • Status: open  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    The definition of this property says:
    This attribute was added because ItemDefinition is based on the DMN ItemDefinition, which is not based on the SCE specification and thus, does not have a built in SemanticReference as
    part of its definition.

    Refer to comments in https://issues.omg.org/issues/SDMN-6

    Proposed change:
    It is suggested to make the SDMN definition of ItemDefinition either standalone or incorporate a copy of the DMN form, if it truly fits (but this is debatable; see SDMN-6).

    The property mentioned in this issue would then no longer be needed.

  • Reported: SDMN 1.0a1 — Thu, 21 Apr 2022 20:02 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT
  • Attachments:

The default expression and default type properties from SDMN are redundant when SCE adds them


The Legend in the DataItem Diagram Example is not necessary


Add arrowhead to Containment Connector


Clarify constraints on SDMN Import inherited from SCE

  • Key: SDMN-44
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

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

  • Reported: SDMN 1.0b1 — Sat, 28 Jan 2023 00:02 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT

ReferenceConnector for DataItems does not match the semantics of ItemDefinition reference relationships

  • Key: SDMN-103
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    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.

  • Reported: SDMN 1.0b1 — Thu, 28 Dec 2023 19:38 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT
  • Attachments:

SDMN itemKinds - too broad, too complex, too ad hoc?

  • Key: SDMN-7
  • Status: open  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    I am not convinced that SDMN DataItems need to cover entity types so broad as Conceptual, Document, Folder, Physical, UMLClass, XSDComplexType and so on. I suggest that in an SDMN model, any technical data definition type - at least DataType, XSDComplexType, WSDLMessage, XSDElement, XSDSimpleType - should just be represented in SDMN as a technical DataType metatype.

    With respect to other item types:

    • Conceptual - documented as representing non-physical / mental entity; if the intention is to represent something that can at least be named, e.g. a CPG name or id, then this should be covered by a Data Type capable of carrying such a name or reference.
    • Document - either this is a reference to a document, in which case it is just a DataType capable of carrying an identifier, or else it is to do with the content, in which case, it is a complex DataType representing the document content; the variable definitions of Document in BMPN versus CMMN might be problematic here.
    • Folder - this is a CMMN Case File Item, according to the documentation; can this not be captured by an appropriate kind of URI or other identifier?
    • Physical - a reference to a physical BPMN entity, location etc; from an abstract SDMN model definition perspective, this could presumably be carried in a suitable data item for which a Datatype instance will be constructed;
    • UMLClass - it is unclear how this can be an SDMN DataItem - more explanation would be useful.
    • Unknown/Unspecified - documented as a CMMN Unknown/Unspecified type; would it not be better to include type unknown-ness or optionality within the SDMN meta-model rather than make it a kind of DataItem?

    I would suggest that SDMN would make more sense as a slimmed down UML static model formalism, with some extras to do with data quality and currency.

  • Reported: SDMN 1.0a1 — Thu, 21 Apr 2022 15:35 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT
  • Attachments:

Incorrect Mapping from Metamodel to XSD

  • Key: SDMN-43
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    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.

  • Reported: SCE 1.0b1 — Tue, 17 Jan 2023 22:56 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT

MultiplicityKind - replace with enum


There are no semantics defined for some of the DataItem markers



SDMN metamodel is not valid MOF

  • Key: SDMN-39
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    It has unnamed Associations and Properties which are not permitted

  • Reported: SDMN 1.0a1 — Mon, 22 Aug 2022 03:46 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT

Integration from SDMN to BPMN, CMMN, and DMN is not clear

  • Key: SDMN-74
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

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

  • Reported: SDMN 1.0b1 — Tue, 7 Nov 2023 15:59 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT

Refactor all SDMN Elements to inherit from SCEElement instead of ElementType

  • Key: SDMN-70
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    As part of Issue 2/51 we reset the Connector element to SCEElement instead of ElementRelationshipType (which inherits from ElementType).
    In our discussions we agreed to reset all relevant SDMN Elements to SCEElement.

  • Reported: SDMN 1.0a1 — Thu, 12 Oct 2023 18:00 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT
  • Attachments:

Unresolved ref in text

  • Key: SDMN-72
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    (SCE doc) 6.6 Structure of this Document

  • Reported: SDMN 1.0a1 — Fri, 3 Nov 2023 21:29 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT

There are editorial issues in the Specification


There are SCE Structural changes that affect the structure SDMN


SDMN has too many layers of abstraction for packaging models


SDMN can be simplified to use SCEDI directly



SDMN Metamodel Relationships do not have labels


Create Capability of Data Associations across multiple Data Items - not just one to one

  • Key: SDMN-81
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    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.

  • Reported: SDMN 1.0b1 — Tue, 28 Nov 2023 18:46 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT

Copyright section needs update

  • Key: SDMN-115
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

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

  • Reported: SDMN 1.0b1 — Mon, 15 Jan 2024 18:28 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT

Acknowledgements for SDMN 1.0 contributors needed

  • Key: SDMN-116
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

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

  • Reported: SCE 1.0b1 — Mon, 15 Jan 2024 18:29 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT

Labels are not needed for SDMN Connectors


Notation Depiction Definitions for ItemComponents is not clear

  • Key: SDMN-121
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    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.

  • Reported: SDMN 1.0b1 — Wed, 24 Jan 2024 17:38 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT

SDMN XSD has a redundant Import element

  • Key: SDMN-119
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    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.

  • Reported: SDMN 1.0b1 — Tue, 16 Jan 2024 17:29 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT

Update Copyright section

  • Key: SDMN-123
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

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

  • Reported: BKPMN 1.0b1 — Sat, 27 Jan 2024 23:52 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT

XML Namespace URI needs updating

  • Key: SDMN-137
  • Status: open  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    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.

  • Reported: SDMN 1.0b1 — Tue, 6 Feb 2024 22:42 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT

There are Connection Errors in the SDMN Diagram Example

  • Key: SDMN-135
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

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

  • Reported: SDMN 1.0b1 — Tue, 6 Feb 2024 22:02 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT

Additional Editorial Issues

  • Key: SDMN-129
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

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

  • Reported: SDMN 1.0b1 — Tue, 6 Feb 2024 16:49 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT
  • Attachments:

XSD Chapter Outdated with incorrect text

  • Key: SDMN-127
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    XSD Chapter Outdated with incorrect text that was copied from the DMN specification.

  • Reported: BKPMN 1.0b1 — Wed, 31 Jan 2024 23:54 GMT
  • Updated: Mon, 25 Mar 2024 15:50 GMT

ItemKind is in the Wrong Location