1. OMG Mailing List
  2. Situational Data Model and Notation (SDMN) Finalization Task Force

All Issues

  • All Issues
  • Name: sdmn-ftf
  • Issues Count: 72

Issues Summary

Key Issue Reported Fixed Disposition Status
SCE-88 The file filed as the SCE metamodel is in fact SDMN SDMN 1.0b1 SCE 1.0b2 Closed; Out Of Scope closed
SCE-87 Internal Relationships - various SDMN 1.0b1 SCE 1.0b2 Duplicate or Merged closed
SCE-15 Consider better Vocabulary extension / re-use model, plus specialised terms (IS-A) SDMN 1.0b1 SCE 1.0b2 Duplicate or Merged closed
SCE-14 Wrong Xrefs in text SDMN 1.0b1 SCE 1.0b2 Resolved closed
SCE-9 Category class - various SDMN 1.0b1 SCE 1.0b2 Resolved closed
SCE-12 SCERootElement.id definition mandatory but optional SDMN 1.0b1 SCE 1.0b2 Resolved closed
SCE-7 Semantic Reference mixes too many use cases SCE 1.0b1 SCE 1.0b2 Resolved closed
SCE-21 SCEModel.category needed? SDMN 1.0b1 SCE 1.0b2 Closed; No Change closed
SCE-16 Association - TYPO SDMN 1.0b1 SCE 1.0b2 Resolved closed
SCE-10 Blank cardinality safe to use? SDMN 1.0b1 SCE 1.0b2 Deferred closed
SCE-13 RootElement.name needs clarification SDMN 1.0b1 SCE 1.0b2 Resolved closed
SCE-11 Unresolved ref in text SDMN 1.0b1 SCE 1.0b2 Resolved closed
SCE-18 Reconsider dependency of SCE on other BPM+ specs SDMN 1.0b1 SCE 1.0b2 Deferred closed
SCE-19 Terms should not be defined in terms of CMMN, BPMN artefacts, but as self-standing concepts SDMN 1.0b1 SCE 1.0b2 Deferred closed
SCE-20 Consider removing references to BKPMN etc SDMN 1.0b1 SCE 1.0b2 Deferred closed
SDMN-74 Integration from SDMN to BPMN, CMMN, and DMN is not clear SDMN 1.0b1 SDMN 1.0b2 Deferred closed
SDMN-81 Create Capability of Data Associations across multiple Data Items - not just one to one SDMN 1.0b1 SDMN 1.0b2 Deferred closed
SDMN-41 Add BPMN Messages to SDMN SDMN 1.0b1 SDMN 1.0b2 Deferred closed
SDMN-5 DataItem class - semantics of various properties SDMN 1.0a1 SDMN 1.0b2 Deferred closed
SDMN-6 ItemDefinition class naming and semantics SDMN 1.0a1 SDMN 1.0b2 Deferred closed
SDMN-133 MultiplicityKind attribute is redundant in ItemDefinition SDMN 1.0b1 SDMN 1.0b2 Resolved closed
SDMN-115 Copyright section needs update SDMN 1.0b1 SDMN 1.0b2 Resolved closed
SDMN-38 SDMN Metamodel Relationships do not have labels SDMN 1.0a1 SDMN 1.0b2 Resolved closed
SDMN-129 Additional Editorial Issues SDMN 1.0b1 SDMN 1.0b2 Resolved closed
SDMN-116 Acknowledgements for SDMN 1.0 contributors needed SCE 1.0b1 SDMN 1.0b2 Resolved closed
SDMN-127 XSD Chapter Outdated with incorrect text BKPMN 1.0b1 SDMN 1.0b2 Resolved closed
SDMN-130 ItemKind is in the Wrong Location SDMN 1.0b1 SDMN 1.0b2 Resolved closed
SDMN-125 Labels are not needed for SDMN Connectors SDMN 1.0b1 SDMN 1.0b2 Resolved closed
SDMN-121 Notation Depiction Definitions for ItemComponents is not clear SDMN 1.0b1 SDMN 1.0b2 Resolved closed
SDMN-135 There are Connection Errors in the SDMN Diagram Example SDMN 1.0b1 SDMN 1.0b2 Resolved closed
SDMN-119 SDMN XSD has a redundant Import element SDMN 1.0b1 SDMN 1.0b2 Resolved closed
SDMN-123 Update Copyright section BKPMN 1.0b1 SDMN 1.0b2 Closed; No Change closed
SDMN-70 Refactor all SDMN Elements to inherit from SCEElement instead of ElementType SDMN 1.0a1 SDMN 1.0b2 Resolved closed
SDMN-8 MultiplicityKind - replace with enum SDMN 1.0a1 SDMN 1.0b2 Resolved closed
SDMN-109 There are no semantics defined for some of the DataItem markers SDMN 1.0b1 SDMN 1.0b2 Resolved closed
SDMN-27 Vocabularies should not be in SDMN SDMN 1.0a1 SDMN 1.0b2 Resolved closed
SDMN-39 SDMN metamodel is not valid MOF SDMN 1.0a1 SDMN 1.0b2 Duplicate or Merged closed
SDMN-69 There are editorial issues in the Specification SDMN 1.0b1 SDMN 1.0b2 Resolved closed
SDMN-93 There are SCE Structural changes that affect the structure SDMN SDMN 1.0b1 SDMN 1.0b2 Resolved closed
SDMN-113 SDMN has too many layers of abstraction for packaging models SDMN 1.0b1 SDMN 1.0b2 Resolved closed
SDMN-33 SDMN can be simplified to use SCEDI directly SDMN 1.0a1 SDMN 1.0b2 Resolved closed
SDMN-72 Unresolved ref in text SDMN 1.0a1 SDMN 1.0b2 Resolved closed
SDMN-56 Update DMN Dependencies? SDMN 1.0a1 SDMN 1.0b2 Resolved closed
SDMN-50 No Notation for Item Definitions SDMN 1.0b1 SDMN 1.0b2 Resolved closed
SDMN-9 ItemDefinition.semanticReferenceRef semantics requires updating SDMN 1.0a1 SDMN 1.0b2 Resolved closed
SDMN-75 The default expression and default type properties from SDMN are redundant when SCE adds them SDMN 1.0a1 SDMN 1.0b2 Resolved closed
SDMN-88 The Legend in the DataItem Diagram Example is not necessary SDMN 1.0b1 SDMN 1.0b2 Resolved closed
SDMN-83 Add arrowhead to Containment Connector SDMN 1.0b1 SDMN 1.0b2 Resolved closed
SDMN-62 Remove Item Format from SDMN SDMN 1.0b1 SDMN 1.0b2 Resolved closed
SDMN-44 Clarify constraints on SDMN Import inherited from SCE SDMN 1.0b1 SDMN 1.0b2 Closed; No Change closed
SDMN-49 Containment Connector SDMN 1.0b1 SDMN 1.0b2 Closed; No Change closed
SDMN-48 Composition Connector SDMN 1.0a1 SDMN 1.0b2 Closed; No Change closed
SDMN-7 SDMN itemKinds - too broad, too complex, too ad hoc? SDMN 1.0a1 SDMN 1.0b2 Resolved closed
SDMN-103 ReferenceConnector for DataItems does not match the semantics of ItemDefinition reference relationships SDMN 1.0b1 SDMN 1.0b2 Resolved closed
SDMN-43 Incorrect Mapping from Metamodel to XSD SCE 1.0b1 SDMN 1.0b2 Resolved closed
SDMN-3 Unclear semantics of DataState class SDMN 1.0a1 SDMN 1.0b2 Resolved closed
SDMN-12 DataAssociation class named misleadingly; is it really a Connector? SDMN 1.0a1 SDMN 1.0b2 Closed; No Change closed
SDMN-26 Copy/Paste Errors in SDMNShape Resolution Section SDMN 1.0a1 SDMN 1.0b2 Resolved closed
SDMN-4 Semantics of Location and descendants SDMN 1.0a1 SDMN 1.0b2 Resolved closed
SDMN-11 Are special Folder semantics really needed for CompositionConnector and ContainmentConnector? Or at all in SDMN. SDMN 1.0a1 SDMN 1.0b2 Duplicate or Merged closed
SDMN-10 Are CompositionConnector and ContainmentConnector really different? SDMN 1.0a1 SDMN 1.0b2 Resolved closed
SDMN-13 Connector types rationalisation possible? SDMN 1.0a1 SDMN 1.0b2 Closed; No Change closed
SDMN-29 Data item folder shape SDMN 1.0a1 SDMN 1.0b2 Resolved closed
SDMN-42 Update SDMN to Reflect SCE's Moving from Vocabularies to KindSets SDMN 1.0a1 SDMN 1.0b2 Closed; No Change closed
SDMN-47 Parent DataItem (folder) SDMN 1.0a1 SDMN 1.0b2 Duplicate or Merged closed
SDMN-28 Locations should not be part of SDMN SDMN 1.0a1 SDMN 1.0b2 Duplicate or Merged closed
SDMN-31 Pre-Assigning Values for DataItems is questionable SDMN 1.0a1 SDMN 1.0b2 Closed; No Change closed
SDMN-137 XML Namespace URI needs updating SDMN 1.0b1 SDMN 1.0b2 Resolved closed
SDMN-2 Semantics of Connector class SDMN 1.0a1 SDMN 1.0b2 Resolved closed
SDMN-1 Class DataItemRelationship no longer in UML SDMN 1.0a1 SDMN 1.0b2 Resolved closed
SDMN-25 Incorrect Reference in DI text SDMN 1.0a1 SDMN 1.0b2 Resolved closed
SDMN-45 Fig 1 does not render properly in PDF SDMN 1.0b1 SDMN 1.0b2 Resolved closed

Issues Descriptions

The file filed as the SCE metamodel is in fact SDMN

  • Key: SCE-88
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    This file linked to from the SCE catalog page (https://www.omg.org/spec/SCE )
    https://www.omg.org/spec/SCE/20211101/SCE.xmi does not include the SCE package but seems to be the SDMN package which imports SCE (there are proprietary hrefs to SCE.mdzip) though the file has more than the official SDMN metamodel.

    Further the files on this catalog page https://www.omg.org/spec/SCE which have SCE in their name have descriptions which refer to SDMN not SCE e.g.
    "Shared Data Model and Notation (SDMN) XSD" is the description for SCE/20211101/SCE-Library.xsd

  • Reported: SDMN 1.0b1 — Mon, 22 Aug 2022 06:29 GMT
  • Disposition: Closed; Out Of Scope — SCE 1.0b2
  • Disposition Summary:

    Out of scope for the FTF

    The FTF is not is a position to correct this issue. The correct files have been submitted to the OMG for replacement on the web site. Furthermore, we will ensure that the proper updated files are submitted at the completion of this FTF.

  • Updated: Mon, 16 Sep 2024 14:12 GMT
  • Attachments:

Internal Relationships - various

  • Key: SCE-87
  • Status: closed  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    Error: para 2 refers to SDMNVocabulary, but it probably should be SCEVocabulary (or else the UML is wrong).

    8.4.3 RelationshipKind

    The description here & UML are repeated in 9.1 under SCE Library - is this intended - a cross-reference might be better, especially since the RelationshipKind Instances table is repeated.

  • Reported: SDMN 1.0b1 — Thu, 21 Apr 2022 22:08 GMT
  • Disposition: Duplicate or Merged — SCE 1.0b2
  • Disposition Summary:

    This issue has been fixed

    The resolution for issue SCE-37/SCE-39 fixed this typo.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

Consider better Vocabulary extension / re-use model, plus specialised terms (IS-A)

  • Key: SCE-15
  • Status: closed  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    Currently, extension of a Vocabulary has to be done by creating a new instance of SCEVocabulary or a descendent, e.g. BKPMNVocabulary, that individually recreates the membership of the 'term' property of the vocabulary, including all the terms of the original vocabulary (say SCE RelationshipKinds) along with the required extension terms.

    With small vocabularies, this works, but creates a static definition that will go out of date if the top-level standard (SCE) is re-issued with new terms in say SCE RelationshipKinds. Any extension of this done by exhaustive listing of the original terms will only capture those from the older version. Normally, the intention of extension is to obtain a resulting vocabulary consisting of your extension terms plus whatever is considered to be the 'core' (original) vocabulary today - which is usually different from its first publication.

    With larger vocabularies, e.g. in the 100+ terms range, the approach is likely to be unwieldy and error-prone, as well as having the above problem.

    I suggest that the requirements we have are:

    • how to easily re-use an entire vocabulary, and extend it - recursively
    • how to do so, such that if the re-used original is updated, the downstream extended versions automatically pick this up (via tooling updates etc)
    • potentially, enable vocabulary extension with exclusion, e.g. include a vocabulary (50 terms), exclude two that don't make sense, and add 18 more.
    • document not just Vocabulary but the method of extension, in the SCE spec.

    Further requirements that could be considered:

    • enable the IS-A relationship to be asserted in vocabularies. This allows specialised forms of existing terms to be defined within a vocabulary or an extension, not just now sibling terms. For example, one could imagine the term SCE RelationshipKinds::miscellaneous being specialised into various terms specific to some domain. Or Correlation being specialised into CausalCorrelation and SpuriousCorrelation.
    • specialisation would allow the SCE 'Category' concept to be solved using just Vocabulary as well. See https://issues.omg.org/issues/lists/sdmn-ftf#issue-49088
    • whether this Vocabulary modelling approach is intended to become an OMG pattern / guidance / standard...

    A change proposal for all this would include:

    • a way of defining a vocabulary that allows re-use of an entire Vocabulary without having to exhaustively identify all the original terms, plus add one or more? extensions, plus add exclusions.
    • a way of asserting the IS-A relationship, i.e. TermA1 IS-A TermA. This should be possible within a single Vocabulary, and also from terms in an extension to those in an included Vocabulary.

    Both of these are not too hard to do, but will create breaking changes in SCE, SDMN, BKPMN, and PPMN at least.

    Finally, there is an alternative modelling pattern that John Butler has used in PPMN that specialises Vocabulary classes before defining instances. The effect of this is that a given Vocabulary can only contain (at runtime) exactly those terms defined for it, whereas the more generic pattern defined in SCE doesn't prevent wrong terms being included in a Vocabulary at runtime, because there is no static typing that prevents it. Both ways work, so a decision should be made on which pattern is preferred (or even that both could be used, with criteria given for why / when).

  • Reported: SDMN 1.0b1 — Tue, 3 May 2022 11:46 GMT
  • Disposition: Duplicate or Merged — SCE 1.0b2
  • Disposition Summary:

    Vocabularies refactored to KindSet by SCE-7

    Vocabularies are going to be refactored as part of issue SCE-7 in proposal SCE-8.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

Wrong Xrefs in text

  • Key: SCE-14
  • Status: closed  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    Section text:
    Clause 10.4 describes in detail the meta-model used to keep the layout and the look of SCE-dependent Diagrams.
    Clause 10.5 presents in tables a library of the SCE element depictions and an unambiguous resolution between a
    referenced SCE model element and its depiction.

    There is no section 10.4 or 10.5; probably the intent was to refer to 11.3 and 11.4. Proper Word Xrefs are needed...

  • Reported: SDMN 1.0b1 — Tue, 26 Apr 2022 14:48 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    Fix Xrefs in text

    In section 11.3.1
    The text "Clause 10.4" should be changed to "Clause 11.3.4"
    The text "Clause 10.5" should be changed to "Clause 11.4"

  • Updated: Mon, 16 Sep 2024 14:12 GMT

Category class - various

  • Key: SCE-9
  • Status: closed  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    Section 8.2.3 first para,
    TYPO: "A Category, which have user-defined semantics" have -> has

    Figure 12 caption
    TYPO: ".. a Groups referencing Categories ..."

    General comment: Categories, as described and illustrated in the examples seems like a terminological device, very similar to vocabularies. If vocabularies were not flat, i.e. items could relate to other items via the IS-A (subsumption) relation, then the effect of Categories could be achieved just by allowing SCEElements to have SemanticReferences as their categories / classifiers. Any vocabulary that is extensible, e.g. RelationshipKind is in reality likely to be extended with both new top-level terms and specialised forms of some of the existing terms.

    John Butler (09-04-2022): Good point. Could just use SemanticReference as the type of the property “category” on SCEElement and then it could be as rich as one would want.

    Property RelationshipDirection:
    ERROR: the backward and none enumeration literals have the same definition.

  • Reported: SDMN 1.0b1 — Thu, 21 Apr 2022 22:06 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    Fix typos related to Category

    Fix typos as identified in the issue.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

SCERootElement.id definition mandatory but optional

  • Key: SCE-12
  • Status: closed  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    The definition of id: String [1] is:
    This attribute is used to uniquely identify a SCERootElement. The id is REQUIRED if this element is referenced or intended to be referenced by something else. If the element is not currently referenced and is never intended to be referenced, the id MAY be omitted.

    This seems a problematic definition for a mandatory attribute...

  • Reported: SDMN 1.0b1 — Thu, 21 Apr 2022 21:58 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    Make SCERootElement.id optional

    The id is currently mandatory but the definition describes it as optional.
    To fix this conflict, the id will be set to optional ([0..1]) but with explanation that is must be used if the element is referenced by another element.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

Semantic Reference mixes too many use cases

  • Key: SCE-7
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

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

  • Reported: SCE 1.0b1 — Wed, 25 May 2022 23:33 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    Split SemanticReference into conceptReference and Kind + rename Vocabulary into KindSet

    The SCEVocabulary class will be renamed to SCEKindSet and SemanticReference will be renamed to Kind (which are the terms of the KindSet). This separates the terms of a KindSet with Semantic References. Other changes will be reflected in the details of the metamodel (see Convenience Document).

    Further, a property named "conceptReference" of type URI [0..1] will be added to SCEElement to provide the reference capability.

    This will affect other aspects of Vocabularies and creating extendable lists. Going forward, SCEKindSets and Kinds will be used for extendable lists.

    • SCEKindSet will include a kind relationship to the new class Kind [0..*]
    • Add a new class Kind that specializes SCERootElement (not SCEElement as SemanticReference did)
      • Include a conceptReference (URI) property since it does not get the property from SCEElement. We still need to connect Kinds to external definitions.

    Use of KindSets for example in SDMN

    • Languages using SCE, e.g., SDMN will have a specialization of the SCEKindSet to provide the specific context for the list of terms (e.g., ItemKindSet)
      • Redefine the “kind” association to be to the new Specialized Kind (see next)
    • Specialize Kind to provide the specific Kinds that are needed (e.g., ItemKind)
    • The class that needs the KindSet will include a relationship to the Specialized Kind and the relationship will be named “[KindName]Ref”
    • An instance library will be created for the new KindSet
    • An Informative section of the spec can show an instance diagram of the Kinds that will be a part of the new KindSet
  • Updated: Mon, 16 Sep 2024 14:12 GMT
  • Attachments:

SCEModel.category needed?

  • Key: SCE-21
  • Status: closed  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    SCEModel has an attribute category, and also inherits categoryRef from SCEElement; both of type Category. Is this intended?

    John Butler response (09-04-2022): I suspect not. Probably an oversight.

  • Reported: SDMN 1.0b1 — Thu, 21 Apr 2022 22:01 GMT
  • Disposition: Closed; No Change — SCE 1.0b2
  • Disposition Summary:

    Remove the category relationship from SCEModel

    For the purposes of backwards compatibility (with BPMN) we will leave the Category element to remain as-is. This issue can be brought up again in a later version if necessary.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

Association - TYPO

  • Key: SCE-16
  • Status: closed  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    Typo (para 1, sentence 3): 'A modeler can set the direct of the'

  • Reported: SDMN 1.0b1 — Thu, 21 Apr 2022 22:09 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    Fix the typo

    the word "direct" should be "direction"

  • Updated: Mon, 16 Sep 2024 14:12 GMT

Blank cardinality safe to use?

  • Key: SCE-10
  • Status: closed  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    Under Conventions (and therefore likely apply to many OMG docs), it says:

    The cardinality of any content part is specified using the following operators:
    o <none> — exactly once
    o etc

    This is probably an OMG standard practice, but a blank cardinality standing for [1] is problematic, because you can't tell on a model which relationships have been fully analysed to be cardinality = [1], and which ones have not been analysed, or are in contention in a draft - and due to this, some unanalysed relationships may end up in final standards. (This probably applies to every BPM+ standard).

    John Butler comment (09-04-2022): I thought there was a UML standard for that and I used to think it was “” (0..). But I was told differently recently so I decided to go look it up and in version 2.5.1 it states “If no multiplicity is shown on the diagram, no conclusion may be drawn about the multiplicity in the model.” So I guess I’ll have to agree with you on that.

  • Reported: SDMN 1.0b1 — Thu, 21 Apr 2022 21:17 GMT
  • Disposition: Deferred — SCE 1.0b2
  • Disposition Summary:

    Defer to the RTF

    Since blank cardinality is defaulted to 1..1, the current metamodels are not inaccurate.
    However, we agree that explicitly marking them would add clarity. This can be done in an RTF.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

RootElement.name needs clarification

  • Key: SCE-13
  • Status: closed  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    Description of SCERootElement.name : String [0..1] is:

    The name attribute is a text description or label of the element. In general, the name is optional, but many elements will require a name. The definition of each specialization of SCERootElement may identify this requirement.

    The second sentence seems subjective. The final sentence one is not clear.

  • Reported: SDMN 1.0b1 — Thu, 21 Apr 2022 21:59 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    Improve description of RootElement.name

    Clarify that specializations of RootElement may require name to be mandatory.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

Unresolved ref in text

  • Key: SCE-11
  • Status: closed  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    This section contains an unresolved xref.

  • Reported: SDMN 1.0b1 — Thu, 21 Apr 2022 21:20 GMT
  • Disposition: Resolved — SCE 1.0b2
  • Disposition Summary:

    Fix unresolved reference in Section 6.6

    The text now reads: see the section entitled “Error! Reference source not found.” Section 7 "Overview" should be referenced.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

Reconsider dependency of SCE on other BPM+ specs

  • Key: SCE-18
  • Status: closed  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    The scope of SCE is documented as follows:

    The primary goal of SCE is to provide a set of structural elements that are common to other OMG specifications. The proposed specifications, BKPMN, PPMN, and SDMN, are structured to be dependent on the elements defined in SCE.

    It's unusual that a more foundational spec mentions the dependencies other specs have on it, even if it was originally derived / extracted from such specs. These are likely to be fragile references in the long term, and don't (as far as I can see) add anything useful to the spec. The BKPMN etc specs of course have to mention SCE in their dependencies.

    Whether BPM+ even needs to be mentioned as a dependency is a question in my mind - if SCE provides general capabilities, it is surely useable for all kinds of things, e.g. MDMI.

    Additionally, I might have expected that the SCE model wasn't just defined as 'common things to BKPMN, SDMN and PPMN', but in terms of some coherent capabilities, e.g. 'a simple meta-modelling language' or so. IN section 8.1.5 it is stated that SCE is likely to be used as a basis for building models in languages utilising SCE.

    John Butler response (09-04-2022): Agree with all that. Though I will say that others might ask why we didn’t just use one of the other OMG languages already out there. The fact that the BPM+ languages including BPMN, CMMN and DMN have similar elements is what kind of drove us to this.

    Proposed change:
    consider a more definitional description of what SCE is about, rather than just a collection of elements common to BKPMN etc. Reduce / remove direct conceptual dependency of SCE on those specs such that SCE may serve a more generic purpose within OMG specfications.

  • Reported: SDMN 1.0b1 — Thu, 21 Apr 2022 21:13 GMT
  • Disposition: Deferred — SCE 1.0b2
  • Disposition Summary:

    This type of narrative issue should be deferred to the RTF

    Given the number of technical issues that need to be addressed, this type of narrative issue, which won't fundamentally change the content of the specification, should be deferred

  • Updated: Mon, 16 Sep 2024 14:12 GMT

Terms should not be defined in terms of CMMN, BPMN artefacts, but as self-standing concepts

  • Key: SCE-19
  • Status: closed  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    Terms like Case, DataItem, DataState etc are all defined as elements of CMMN, SDMN etc. E.g. 'Case' = 'A CMMN element....'.

    Proposed change:
    Terms like 'Case' etc should have standard definitions that do not need to refer to some model like CMMN. I think every term in the glossary could be improved by removing these model / standard references.

    Even better, a common glossary could be created for all of BPM+, and either published as a separate doc, or included by reference in each BPM+ doc.

    John Butler response: Agreed. Yes, I’m thinking that perhaps a companion, non-normative document could be created to discuss the genesis of the language. A reference to that document wouldn’t be fragile and the contents could be updated without requiring update to this spec.

  • Reported: SDMN 1.0b1 — Thu, 21 Apr 2022 21:15 GMT
  • Disposition: Deferred — SCE 1.0b2
  • Disposition Summary:

    Defer to the RTF

    We agreed that we will defer for now.
    Also a full BPM+ glossary or companion guide would be useful and should be provided at some point.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

Consider removing references to BKPMN etc

  • Key: SCE-20
  • Status: closed  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    It is not clear why there are references specifically to e.g. BKPMN, SDMN, or even BPM+.

    Proposed change:
    Why not just say 'classes outside this model' in places where BKPMN etc classes are mentioned.

    John Butler response (09-04-2022): Same reason as above generally but I agree that this should be removed.

  • Reported: SDMN 1.0b1 — Thu, 21 Apr 2022 21:19 GMT
  • Disposition: Deferred — SCE 1.0b2
  • Disposition Summary:

    Defer to the RTF

    We have accepted that this should be done, but it can wait until the RTF.

  • Updated: Mon, 16 Sep 2024 14:12 GMT

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

  • Key: SDMN-74
  • Status: closed  
  • 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
  • Disposition: Deferred — SDMN 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 21 Jun 2024 17:53 GMT

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

  • Key: SDMN-81
  • Status: closed  
  • 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
  • Disposition: Deferred — SDMN 1.0b2
  • Disposition Summary:

    Defer to the RTF

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

  • Updated: Fri, 21 Jun 2024 17:53 GMT

Add BPMN Messages to SDMN

  • Key: SDMN-41
  • Status: closed  
  • 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
  • Disposition: Deferred — SDMN 1.0b2
  • Disposition Summary:

    Defer to the RTF

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

  • Updated: Fri, 21 Jun 2024 17:53 GMT

DataItem class - semantics of various properties

  • Key: SDMN-5
  • Status: closed  
  • 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
  • Disposition: Deferred — SDMN 1.0b2
  • Disposition Summary:

    Defer to the RTF

    Defer to the RTF

  • Updated: Fri, 21 Jun 2024 17:53 GMT

ItemDefinition class naming and semantics

  • Key: SDMN-6
  • Status: closed  
  • 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
  • Disposition: Deferred — SDMN 1.0b2
  • Disposition Summary:

    Defer to the RTF

    Defer to the RTF

  • Updated: Fri, 21 Jun 2024 17:53 GMT

MultiplicityKind attribute is redundant in ItemDefinition


Copyright section needs update

  • Key: SDMN-115
  • Status: closed  
  • 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
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    Update Copyright section

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

  • Updated: Mon, 17 Jun 2024 13:39 GMT

SDMN Metamodel Relationships do not have labels

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

    to be MOF compliant.

  • Reported: SDMN 1.0a1 — Tue, 19 Jul 2022 22:15 GMT
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    Added Labels for all SCE Metamodel Relationships

    The labels have been added. This will be resolved when the xmi is exported. But that will be done when all the other metamodel changes have been made at the end of the FTF.
    These labels will not affect any diagram in the spec.

  • Updated: Mon, 17 Jun 2024 13:39 GMT
  • Attachments:

Additional Editorial Issues

  • Key: SDMN-129
  • Status: closed  
  • 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
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    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
  • Updated: Mon, 17 Jun 2024 13:39 GMT
  • Attachments:

Acknowledgements for SDMN 1.0 contributors needed

  • Key: SDMN-116
  • Status: closed  
  • 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
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    Update Acknowledgements

    Add acknowledgements for SDMN 1.0 contributors from FTF Participation

  • Updated: Mon, 17 Jun 2024 13:39 GMT

XSD Chapter Outdated with incorrect text

  • Key: SDMN-127
  • Status: closed  
  • 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
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    Fix text in XSD Chapter

    Update class names and element names and refer to QNames instead of href (as how BPMN and CMNN handles this).

  • Updated: Mon, 17 Jun 2024 13:39 GMT

ItemKind is in the Wrong Location

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

    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

  • Reported: SDMN 1.0b1 — Tue, 6 Feb 2024 16:51 GMT
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    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
  • Updated: Mon, 17 Jun 2024 13:39 GMT
  • Attachments:

Labels are not needed for SDMN Connectors

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

    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.

  • Reported: SDMN 1.0b1 — Tue, 30 Jan 2024 17:36 GMT
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    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.

  • Updated: Mon, 17 Jun 2024 13:39 GMT
  • Attachments:

Notation Depiction Definitions for ItemComponents is not clear

  • Key: SDMN-121
  • Status: closed  
  • 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
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    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"

  • Updated: Mon, 17 Jun 2024 13:39 GMT

There are Connection Errors in the SDMN Diagram Example

  • Key: SDMN-135
  • Status: closed  
  • 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
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    Fix Connection Errors in the SDMN Diagram Example

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

  • Updated: Mon, 17 Jun 2024 13:39 GMT

SDMN XSD has a redundant Import element

  • Key: SDMN-119
  • Status: closed  
  • 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
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    Remove redundant Import element from the SDMN Schema

    SDMN's copy of Import should be removed.

  • Updated: Mon, 17 Jun 2024 13:39 GMT

Update Copyright section

  • Key: SDMN-123
  • Status: closed  
  • 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
  • Disposition: Closed; No Change — SDMN 1.0b2
  • Disposition Summary:

    Close no change

    This issue was accidentally added to SDMN. So close no change.

  • Updated: Mon, 17 Jun 2024 13:39 GMT

Refactor all SDMN Elements to inherit from SCEElement instead of ElementType

  • Key: SDMN-70
  • Status: closed  
  • 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
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    Refactor all SDMN Elements to inherit from SCEElement

    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.

    Elements that need to be changed (not including the Connector element that was changed for SDMN-2/SDMN-51 or the removal of DataState, ItemFormat, and Location):
    DataItem
    Assignment

  • Updated: Mon, 17 Jun 2024 13:39 GMT
  • Attachments:

MultiplicityKind - replace with enum

  • Key: SDMN-8
  • Status: closed  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    Proposed change

    The possible values of MultiplicityKind can be (and are) exhaustively definable. It would be more easily expressed as an enum type, and its use elsewhere in the model should be replaced by that enum type.

  • Reported: SDMN 1.0a1 — Thu, 21 Apr 2022 15:40 GMT
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    Change MultiplicityKinds into an Enumerated Set and Review the types of that set

    Change MulitplicityKinds into an Enumerated Set, instead of a vocabulary list, and Review the types of that set.

    Also, remove Section 12.2 - MultiplicityKind - from the Vocabularies section. Since ItemKind is also being removed by SDMN-99, delete Section 12 - SDMN Library - completely
    Replace Section 10.2.3 - MultiplicityKind - with the definition of the enumerated list instead of the vocabulary

  • Updated: Mon, 17 Jun 2024 13:39 GMT
  • Attachments:

There are no semantics defined for some of the DataItem markers

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

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

  • Reported: SDMN 1.0b1 — Wed, 3 Jan 2024 19:48 GMT
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    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

  • Updated: Mon, 17 Jun 2024 13:39 GMT
  • Attachments:

Vocabularies should not be in SDMN

  • Key: SDMN-27
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    SDMN should remain a logical data model. Associating terms to ontologies is of the realm of conceptual models and is already better served by SBVR.

  • Reported: SDMN 1.0a1 — Tue, 26 Apr 2022 19:33 GMT
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    Remove Vocabularies from SDMN

    Based on changes to ItemKind and MultiplicityKind (reducing to string properties), the Vocabulary capability is no longer needed in SDMN. Thus, the sections and any references to Vocabulary will be removed.

  • Updated: Mon, 17 Jun 2024 13:39 GMT
  • Attachments:

SDMN metamodel is not valid MOF

  • Key: SDMN-39
  • Status: closed  
  • 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
  • Disposition: Duplicate or Merged — SDMN 1.0b2
  • Disposition Summary:

    This issue is resolved by Issue SDMN-38

    The addition of association names through SDMN-38 will resolve this issue

  • Updated: Mon, 17 Jun 2024 13:39 GMT

There are editorial issues in the Specification

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

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

  • Reported: SDMN 1.0b1 — Wed, 11 Oct 2023 17:42 GMT
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    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]"
  • Updated: Mon, 17 Jun 2024 13:39 GMT

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


Unresolved ref in text

  • Key: SDMN-72
  • Status: closed  
  • 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
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    Fix unresolved reference in Section 6.6

    In section 6.6: replace
    see the section entitled “Error! Reference source not found.”
    with
    see the section entitled "Overview"
    This is a cross reference in the document.
    Also, see Ballot 4 convenience document: tbd...
    There are no schema changes for this issue

  • Updated: Mon, 17 Jun 2024 13:39 GMT

Update DMN Dependencies?


No Notation for Item Definitions


ItemDefinition.semanticReferenceRef semantics requires updating

  • Key: SDMN-9
  • Status: closed  
  • 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
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    Update ItemDefinition SemanticReference to conceptReference

    This issue is dependent on SCE changes.

  • Updated: Mon, 17 Jun 2024 13:39 GMT
  • Attachments:

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

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

    SCE-2 adds expressionLanguage and typeLanguage properties. Therefor, these properties can be removed from SDMN.

  • Reported: SDMN 1.0a1 — Wed, 8 Nov 2023 17:39 GMT
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    Remove redundant expressionLanguage and typeLanguage

    The expressionLanguage and typeLanguage attributes are removed since they are in SCE and thus inherited by SDMN. These properties are in the SDMNModelPackage.

  • Updated: Mon, 17 Jun 2024 13:39 GMT
  • Attachments:

The Legend in the DataItem Diagram Example is not necessary

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

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

  • Reported: SDMN 1.0b1 — Tue, 19 Dec 2023 18:39 GMT
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    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.

  • Updated: Mon, 17 Jun 2024 13:39 GMT
  • Attachments:

Add arrowhead to Containment Connector

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

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

  • Reported: SDMN 1.0b1 — Tue, 5 Dec 2023 18:27 GMT
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    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.

  • Updated: Mon, 17 Jun 2024 13:39 GMT
  • Attachments:

Remove Item Format from SDMN

  • Key: SDMN-62
  • Status: closed  
  • 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
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    Remove ItemFormat from SDMN

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

  • Updated: Mon, 17 Jun 2024 13:39 GMT

Clarify constraints on SDMN Import inherited from SCE

  • Key: SDMN-44
  • Status: closed  
  • 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
  • Disposition: Closed; No Change — SDMN 1.0b2
  • Disposition Summary:

    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.

  • Updated: Mon, 17 Jun 2024 13:39 GMT

Containment Connector

  • Key: SDMN-49
  • Status: closed  
  • 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
  • Disposition: Closed; No Change — SDMN 1.0b2
  • Disposition Summary:

    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.

  • Updated: Mon, 17 Jun 2024 13:39 GMT

Composition Connector

  • Key: SDMN-48
  • Status: closed  
  • 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
  • Disposition: Closed; No Change — SDMN 1.0b2
  • Disposition Summary:

    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.

  • Updated: Mon, 17 Jun 2024 13:39 GMT

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

  • Key: SDMN-7
  • Status: closed  
  • 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
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    Change ItemKinds into an Enumerated Set and Review the types of that set

    The ItemKind property, not a class, and should be a string.
    We will list in the spec a table of the default items.
    There would be a mapping to the other specs (e.g., BPMN).
    Vendors can then extend the list if they want to.

    Also, remove Section 12.1 - ItemKind - from the Vocabularies section.
    Replace Section 10.2.2 - ItemKind - with the definition of the enumerated list instead of the vocabulary

  • Updated: Mon, 17 Jun 2024 13:39 GMT
  • Attachments:

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

  • Key: SDMN-103
  • Status: closed  
  • 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
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    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)

  • Updated: Mon, 17 Jun 2024 13:39 GMT
  • Attachments:

Incorrect Mapping from Metamodel to XSD

  • Key: SDMN-43
  • Status: closed  
  • 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
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    Use same MM-XSD Mapping as in BPMN, CMMN & DMN

    Use the MM-XSD mapping approach that BPMN pioneered has since been used for all other languages of the BPM+ ecosystem, e.g. DMN & CMMN, to remain backwards compatible and allow vendors to reuse their existing language tooling based on that mapping.
    This also follows the decision of SCE-81.

  • Updated: Mon, 17 Jun 2024 13:39 GMT

Unclear semantics of DataState class

  • Key: SDMN-3
  • Status: closed  
  • 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
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    Remove DataState from SDMN

    Remove DataState from SDMN

  • Updated: Mon, 17 Jun 2024 13:39 GMT

DataAssociation class named misleadingly; is it really a Connector?

  • Key: SDMN-12
  • Status: closed  
  • 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
  • Disposition: Closed; No Change — SDMN 1.0b2
  • Disposition Summary:

    DataAssociation has been determined to be a Connector and will remain in SDMN.

    DataAssociation has been determined to be a Connector and will remain in SDMN.

  • Updated: Mon, 17 Jun 2024 13:39 GMT

Copy/Paste Errors in SDMNShape Resolution Section

  • Key: SDMN-26
  • Status: closed  
  • 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
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    Fix first section in section

    In Section 16.3.5.2, first sentence of section, replace "Text Annotation or a Group" with "Data Item"

  • Updated: Mon, 17 Jun 2024 13:39 GMT

Semantics of Location and descendants

  • Key: SDMN-4
  • Status: closed  
  • 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
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    Remove Location from SDMN

    Remove Location from SDMN

  • Updated: Mon, 17 Jun 2024 13:39 GMT

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

  • Key: SDMN-11
  • Status: closed  
  • 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
  • Disposition: Duplicate or Merged — SDMN 1.0b2
  • Disposition Summary:

    This issue is being resolved by Issue 10/68

    Issue 10/68 resolves the confusion between containers and composition.
    We also determined that the Folder should remain in SDMN.

  • Updated: Mon, 17 Jun 2024 13:39 GMT

Are CompositionConnector and ContainmentConnector really different?

  • Key: SDMN-10
  • Status: closed  
  • 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
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    Clarify the difference between containment and composition in the spec

    The descriptive text in the spec did not clarify the differences between containment and composition.
    This proposal made changes to the text as clarifications.
    The two connectors are different and will both remain as part of SDMN.

  • Updated: Mon, 17 Jun 2024 13:39 GMT

Connector types rationalisation possible?

  • Key: SDMN-13
  • Status: closed  
  • 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
  • Disposition: Closed; No Change — SDMN 1.0b2
  • Disposition Summary:

    No changes to the Connectors for SDMN

    Based on discussion from other issues, we will be retaining the composition and container connectors (with better documentation) and will retain the DataAssociation. Thus, this issue can be closed.

  • Updated: Mon, 17 Jun 2024 13:39 GMT

Data item folder shape

  • Key: SDMN-29
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    The Data item folder shape collides with CMMN notation. It should be used.

  • Reported: SDMN 1.0a1 — Tue, 26 Apr 2022 19:49 GMT
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    Replace the Data Item (Folder) shape so that it does not collide with CMMN shape

    This affects :
    Figure 14: DataItem Object
    Figure 21; Example of the "Hello Patient" DataItem Model
    Table 20: row 2: Parent DataItem (folder)
    Figure 35: An Example of How a SDMN DataItem Diagram
    Table 37: Row 1: DataItem (Folder)

  • Updated: Mon, 17 Jun 2024 13:39 GMT
  • Attachments:

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

  • Key: SDMN-42
  • Status: closed  
  • 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
  • Disposition: Closed; No Change — SDMN 1.0b2
  • Disposition Summary:

    This issue is resolved by Issue SDMN-27

    The resolution for Issue SDMN-27 removed Vocabularies from SDMN. Thus, this issue can be closed with no change.

  • Updated: Mon, 17 Jun 2024 13:39 GMT

Parent DataItem (folder)

  • Key: SDMN-47
  • Status: closed  
  • 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
  • Disposition: Duplicate or Merged — SDMN 1.0b2
  • Disposition Summary:

    This will be handled with Issue 29

    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

  • Updated: Mon, 17 Jun 2024 13:39 GMT

Locations should not be part of SDMN

  • Key: SDMN-28
  • Status: closed  
  • 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
  • Disposition: Duplicate or Merged — SDMN 1.0b2
  • Disposition Summary:

    This issue is now handled by Issue 4

    Location should be removed from SDMN

  • Updated: Mon, 17 Jun 2024 13:39 GMT

Pre-Assigning Values for DataItems is questionable

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

    The approach taken is not ideal

  • Reported: SDMN 1.0a1 — Tue, 26 Apr 2022 19:54 GMT
  • Disposition: Closed; No Change — SDMN 1.0b2
  • Disposition Summary:

    Leave the capability in the spec

    We decided that this should remain.

  • Updated: Mon, 17 Jun 2024 13:39 GMT

XML Namespace URI needs updating

  • Key: SDMN-137
  • Status: closed  
  • 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
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    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.

  • Updated: Mon, 17 Jun 2024 13:39 GMT

Semantics of Connector class

  • Key: SDMN-2
  • Status: closed  
  • 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
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    Update Connector model and specification section

    The Connector class should be updated so that it is a subclass of SCEElement instead of ElementRelationshipType.
    Remove the constraints (for ElementRelationshipKind) from the four concrete types of Connectors.
    Update the Text as needed.

  • Updated: Mon, 17 Jun 2024 13:39 GMT
  • Attachments:

Class DataItemRelationship no longer in UML

  • Key: SDMN-1
  • Status: closed  
  • 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
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    Remove Section 10.1.2

    This section is obsolete and should not have been included in the draft spec. Thus, remove this section and sub-sections, including Figure 15 and Table 11.
    There are no other references to the DataItemRelationship in the spec, except for in the Tables of Contents, Figures, and Tables.

  • Updated: Mon, 17 Jun 2024 13:39 GMT

Incorrect Reference in DI text

  • Key: SDMN-25
  • Status: closed  
  • 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
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    Fix incorrect Reference in DI Text

    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]".

  • Updated: Mon, 17 Jun 2024 13:39 GMT

Fig 1 does not render properly in PDF

  • Key: SDMN-45
  • Status: closed  
  • 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
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    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.

  • Updated: Mon, 17 Jun 2024 13:39 GMT
  • Attachments: