UML Profile for NIEM Avatar
  1. OMG Specification

UML Profile for NIEM — Closed Issues

  • Acronym: NIEM-UML
  • Issues Count: 44
  • Description: Issues resolved by a task force and approved by Board
Open Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
UMLNIEM3-20 Annex A clarity about profiles and files NIEM-UML 3.0b1 NIEM-UML 3.0 Resolved closed
UMLNIEM3-19 Diagram readability NIEM-UML 3.0b1 NIEM-UML 3.0 Resolved closed
UMLNIEM3-16 Clause 9 confusion NIEM-UML 3.0b1 NIEM-UML 3.0 Closed; No Change closed
UMLNIEM3-6 NIEM-UML-Profile.xmi contains a superfluous package called MyPackage NIEM-UML 3.0b1 NIEM-UML 3.0 Closed; No Change closed
UMLNIEM3-59 Proprietary files cannot be "informative" NIEM-UML 3.0b1 NIEM-UML 3.0 Resolved closed
UMLNIEM3-37 Incomplete and inconsistent diagrams in MagicDraw implementation of reference libraries NIEM-UML 3.0b1 NIEM-UML 3.0 Deferred closed
UMLNIEM3-36 Inconsistent statements about aggregation NIEM-UML 3.0b1 NIEM-UML 3.0 Resolved closed
UMLNIEM3-1 NIEM-UML Issue - Association Element NIEM-UML 1.0b2 NIEM-UML 3.0 Closed; No Change closed
UMLNIEM3-2 NIEM-UML Issue - appinfo:Base for a base component in NIEM Prox NIEM-UML 1.0b2 NIEM-UML 3.0 Closed; No Change closed
UMLNIEM3-3 NIEM-UML Issue - Reference Element NIEM-UML 1.0b2 NIEM-UML 3.0 Closed; No Change closed
UMLNIEM3-4 MPD Specification v1.1 - UML Profile for NIEM Beta Specification Alignment NIEM-UML 1.0b2 NIEM-UML 3.0 Resolved closed
UMLNIEM3-5 NIEM-UML Issue - General Information Models NIEM-UML 1.0b2 NIEM-UML 3.0 Closed; Out Of Scope closed
UMLNIEM3-15 Clause 8 explanation needed NIEM-UML 3.0b1 NIEM-UML 3.0 Resolved closed
UMLNIEM3-14 Clause 8 figures NIEM-UML 3.0b1 NIEM-UML 3.0 Closed; No Change closed
UMLNIEM3-13 Clarify Schematron standards NIEM-UML 3.0b1 NIEM-UML 3.0 Resolved closed
UMLNIEM3-12 Clarify NIEMType NIEM-UML 3.0b1 NIEM-UML 3.0 Resolved closed
UMLNIEM3-11 Define abstract elements NIEM-UML 3.0b1 NIEM-UML 3.0 Resolved closed
UMLNIEM3-18 Spelling errors NIEM-UML 3.0b1 NIEM-UML 3.0 Resolved closed
UMLNIEM3-17 Conformance statement NIEM-UML 3.0b1 NIEM-UML 3.0 Resolved closed
UMLNIEM3-10 Trademark NIEM-UML 3.0b1 NIEM-UML 3.0 Resolved closed
UMLNIEM3-9 Clarify ability to apply other profiles NIEM-UML 3.0b1 NIEM-UML 3.0 Resolved closed
UMLNIEM3-8 Possibly incorrect statement about conversion transformations NIEM-UML 3.0b1 NIEM-UML 3.0 Resolved closed
UMLNIEM3-7 Describe the embedded links in the introduction NIEM-UML 3.0b1 NIEM-UML 3.0 Resolved closed
UMLNIEM_-12 Page 295 - NIEM-UML 1.0b2 NIEM-UML 1.0 Resolved closed
UMLNIEM_-9 Page 240 editorial NIEM-UML 1.0b2 NIEM-UML 1.0 Resolved closed
UMLNIEM_-8 Page 227 - typo NIEM-UML 1.0b2 NIEM-UML 1.0 Resolved closed
UMLNIEM_-7 P)age 226 NIEM-UML 1.0b2 NIEM-UML 1.0 Resolved closed
UMLNIEM_-11 Page 264 text update NIEM-UML 1.0b2 NIEM-UML 1.0 Resolved closed
UMLNIEM_-10 Page 243 - typo NIEM-UML 1.0b2 NIEM-UML 1.0 Resolved closed
UMLNIEM_-2 8-1, 8-3, 8-5 NIEM-UML 1.0b2 NIEM-UML 1.0 Resolved closed
UMLNIEM_-1 "Pet" example has errors NIEM-UML 1.0b2 NIEM-UML 1.0 Resolved closed
UMLNIEM_-4 Page 3 wording change NIEM-UML 1.0b2 NIEM-UML 1.0 Resolved closed
UMLNIEM_-3 XSDRestrictionComplexTypeSimpleContent OCL Issue NIEM-UML 1.0b2 NIEM-UML 1.0 Resolved closed
UMLNIEM_-6 Page 225 NIEM-UML 1.0b2 NIEM-UML 1.0 Resolved closed
UMLNIEM_-5 Page 4 typo NIEM-UML 1.0b2 NIEM-UML 1.0 Resolved closed
UMLNIEM-4 NIEM-UML PurposeCode changelog NIEM-UML 1.0b1 NIEM-UML 1.0b2 Resolved closed
UMLNIEM-3 NIEM-UML Issue - NIEM-UML Design rules NIEM-UML 1.0b1 NIEM-UML 1.0b2 Resolved closed
UMLNIEM-2 NIEM-UML FTF Issue: Namespace prefix NIEM-UML 1.0b1 NIEM-UML 1.0b2 Resolved closed
UMLNIEM-1 Inconsistency in NIEM-UML URIs NIEM-UML 1.0b1 NIEM-UML 1.0b2 Resolved closed
UMLNIEM-9 NIEM-UML Property <> Ambiguity NIEM-UML 1.0b1 NIEM-UML 1.0b2 Resolved closed
UMLNIEM-6 Problem with XmiPrimitiveTypes.xmi in the NIEM specification NIEM-UML 1.0b1 NIEM-UML 1.0b2 Resolved closed
UMLNIEM-5 NIEM-UML Issue - Changelog NIEM-UML 1.0b1 NIEM-UML 1.0b2 Resolved closed
UMLNIEM-8 PSM Representation for XSD Complex Type with Simple Content NIEM-UML 1.0b1 NIEM-UML 1.0b2 Resolved closed
UMLNIEM-7 NIEM-UML Issue: Constraint schema and other constraint/rule support NIEM-UML 1.0b1 NIEM-UML 1.0b2 Resolved closed

Issues Descriptions

Annex A clarity about profiles and files

  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    There are 5 URLs listed in the normative section of the files in Annex A, but only two XMI files submitted. In gov-15-02-03 and 04 there are 3 namespaces defined. How do we account for NIEM UML_Profile and Model_Package_Description_Profile?

  • Reported: NIEM-UML 3.0b1 — Fri, 7 Aug 2015 08:46 GMT
  • Disposition: Resolved — NIEM-UML 3.0
  • Disposition Summary:

    Clarify relationship of profiles to the profile file.

    The current text is not entirely clear about the fact that the NIEM-UML-Profile.xmi file contains five profiles.

  • Updated: Tue, 11 Oct 2016 14:48 GMT

Diagram readability

  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Several diagrams are not really readable (e.g. figure 9.1) at 100% resolution. If everything was as readable as 8.6 as a minimum that would be great. This could be an opportunity to provide an ancillary file that was the model produced as an HTML representation that readers of the spec could refer to separately.

  • Reported: NIEM-UML 3.0b1 — Fri, 7 Aug 2015 08:45 GMT
  • Disposition: Resolved — NIEM-UML 3.0
  • Disposition Summary:

    Provide SVG versions

    Provide SVG versions of the figures so the published specification can include them. This can be done for most of the figures in the document with the exception of the following figures in clause 9, for which sources are no longer available: 9.3, 9.4, 9.5, 9.7, 9.13, 9.14, 9.16, 9.17, 9.18, 9.19, 9.23, 9.24, 9.26, 9.28, 9.29 and 9.30.

  • Updated: Tue, 11 Oct 2016 14:48 GMT

Clause 9 confusion

  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Figure 9.1: I am not sure what this is meant to show or if it is MOF or UML notation or just a picture of concepts? More explanation would be useful.
    Also, figures 9-1, 9-4, 9-5, 9-6, 9-7, 9-8, 9-9, etc. are of poor quality and confusing. These need to be replaced so that they are legible. They should also be rearranged so that they are more legible. The notation is also confusing. And the use of color does not help legibility but detracts.
    The names in Figure 9-9 of class, etc. do not help understanding.
    Figures 9-10 and 9-11 are too small to be read. They need to be rearranged so that they are longer and can be zoomed. Same for 9-13 and 9-14 and in fact all the diagrams in this section that have the yellow and green boxes as well as the complex inheritance diagrams.
    Also, I am not sure what some of them are meant to show. For example, 9-28 has a box called primitive simple types with several notes mapped to it between the various other classes. The notes mention operations but there are no operations listed.
    I find the whole section confusing and believe it should be reorganized. Possibly this could be explained during the review.

  • Reported: NIEM-UML 3.0b1 — Fri, 7 Aug 2015 08:39 GMT
  • Disposition: Closed; No Change — NIEM-UML 3.0
  • Disposition Summary:

    Finding a better way to provide an overview of QVT mappings is not worth the effort.

    Section 9 is essentially an overview of the QVT mappings - to provide a bit of guidance prior to jumping into the normative QVT code. While it is a bit hard to read and grasp, it is helpful and is the same as was done for NIEM-2.
    The substantial effort involved in coming up with a new way to express this overview, creating new models and text does not seem justified as there have been zero complaints from the 3 parties that have implemented NIEM mappings.
    For these reasons we propose closing the issue with no change.

  • Updated: Tue, 11 Oct 2016 14:48 GMT

NIEM-UML-Profile.xmi contains a superfluous package called MyPackage

  • Key: UMLNIEM3-6
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    NIEM-UML-Profile.xmi (published as gov/2015-02-03) contains a redundant empty package called MyPackage. This ought to be deleted.

  • Reported: NIEM-UML 3.0b1 — Thu, 6 Aug 2015 19:22 GMT
  • Disposition: Closed; No Change — NIEM-UML 3.0
  • Disposition Summary:

    Removing package would have excessive impact.

    While useless, the referenced package has no impact while removing it would cause a cascade change in multiple published documents. It is thought to be not worthwhile to change.

  • Updated: Tue, 11 Oct 2016 14:48 GMT

Proprietary files cannot be "informative"

  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Cory Casanave)
  • Summary:

    Clause A2 refers to "Informative" MagicDraw files published at OMG URLs. This contravenes OMG policy. These files should be "Ancillary" and not published as part of the spec.

  • Reported: NIEM-UML 3.0b1 — Thu, 9 Jun 2016 09:19 GMT
  • Disposition: Resolved — NIEM-UML 3.0
  • Disposition Summary:

    Delete offending clauses from specification

    Delete clauses A.2 and A.3, which incorrectly assign OMG URLs to proprietary files. Ask OMG staff not to publish these files on the specification page.

  • Updated: Tue, 11 Oct 2016 14:48 GMT

Incomplete and inconsistent diagrams in MagicDraw implementation of reference libraries

  • Legacy Issue Number: 19834
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The MagicDraw reference libraries only have diagrams for niem-core. The machine generated diagrams are unusable. The hand-created diagrams are potentially very useful but are incomplete and use inconsistent schemes for colour and other symbol properties. All of these libraries should have complete and consistent diagrams which should be published as informative documents.

  • Reported: NIEM-UML 3.0b1 — Wed, 16 Sep 2015 04:00 GMT
  • Disposition: Deferred — NIEM-UML 3.0
  • Disposition Summary:

    Once these diagrams are published, revisit this issue.

    The diagrams are not yet published although there are plans to do so through the NIEM PMO.

  • Updated: Tue, 11 Oct 2016 14:48 GMT

Inconsistent statements about aggregation

  • Legacy Issue Number: 19833
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Table 7.1 says “Aggregation may be used in NIEM-UML models but has no impact on the generated schema or conformance” while 7.3.3.2 says about RoleOf properties: “Such a property must have aggregation=none”, 7.5.1.2 says “If an «XSDProperty» property has kind=attribute, then its multiplicity must be 1..1, its aggregation must not be none and its type must be a data type representing a simple type”, 7.5.1.3 says “A property in a PIM shall map to a corresponding property in the PSM with the same multiplicity and aggregation as the PIM property and with an owner and type (if any) that are the corresponding classifiers mapped from the PIM”, and 8.3.5 says “A RoleOf Property must be a reference (i.e., have aggregation=none)” .

  • Reported: NIEM-UML 3.0b1 — Wed, 16 Sep 2015 04:00 GMT
  • Disposition: Resolved — NIEM-UML 3.0
  • Disposition Summary:

    Aggregation is no longer required, document text adjusted.

    As aggregation is no longer relevant to NIEM-UML the statements may be clarified as follows:
    The statement in Table 7.1 is correct.
    The statement in 7.3.3.2 is false.
    The statement in 7.5.1.2 is logically true with respect to aggregation, but does not impact generation, since it is assumed part of the definition of an «XSDProperty». Multiplicity can be defined to be 0..0, 0..1, 1..1 and will impact generation of attribute definition.
    The statement in 7.5.1.3 is true, even though the aggregation does not impact PIM to XSD transformation.
    The statement in 8.3.5 is false.

  • Updated: Tue, 11 Oct 2016 14:48 GMT

NIEM-UML Issue - Association Element

  • Key: UMLNIEM3-1
  • Legacy Issue Number: 19148
  • Status: closed  
  • Source: Visumpoint ( Tom Digre)
  • Summary:

    Issue:
    The current transformation does not coerce an Association element to have the required name suffix.

    For more information, see attachment

  • Reported: NIEM-UML 1.0b2 — Sun, 22 Dec 2013 05:00 GMT
  • Disposition: Closed; No Change — NIEM-UML 3.0
  • Disposition Summary:

    Not applicable to NIEM-3

    Resolved as part of NIEM-3

  • Updated: Tue, 11 Oct 2016 14:48 GMT
  • Attachments:

NIEM-UML Issue - appinfo:Base for a base component in NIEM Prox

  • Key: UMLNIEM3-2
  • Legacy Issue Number: 19147
  • Status: closed  
  • Source: Visumpoint ( Tom Digre)
  • Summary:

    Issue:

    The current NIEMpsm2xsd.qvto transformation produces an appinfo:Base of structures:Object when the base type is in the NIEM proxy schema. It should be producing an appinfo:Base with a target namespace of "http://niem.gov/niem/proxy/xsd/2.0".

    See attachement for more information.

  • Reported: NIEM-UML 1.0b2 — Sun, 22 Dec 2013 05:00 GMT
  • Disposition: Closed; No Change — NIEM-UML 3.0
  • Disposition Summary:

    No longer relevant for NIEM-3

    Changes in NIEM make this issue irrelevant.

  • Updated: Tue, 11 Oct 2016 14:48 GMT

NIEM-UML Issue - Reference Element

  • Key: UMLNIEM3-3
  • Legacy Issue Number: 19149
  • Status: closed  
  • Source: Visumpoint ( Tom Digre)
  • Summary:

    There are cases in which the current transformation does not coerce the name of a reference element to have the required name suffix.

    For more information, see attachment.

  • Reported: NIEM-UML 1.0b2 — Sun, 22 Dec 2013 05:00 GMT
  • Disposition: Closed; No Change — NIEM-UML 3.0
  • Disposition Summary:

    Fixed as part of NIEM3 submission

    The issue is obsolete, referring to a previous version of NIEM and a previous NIEM-UML specification.

  • Updated: Tue, 11 Oct 2016 14:48 GMT
  • Attachments:

MPD Specification v1.1 - UML Profile for NIEM Beta Specification Alignment

  • Key: UMLNIEM3-4
  • Legacy Issue Number: 18250
  • Status: closed  
  • Source: U.S. Department of the Treasury ( Justin Stekervetz)
  • Summary:

    Modified
    MPD Specification v1.0 has been updated to MPD Specification v1.1.

    Modified
    URI locations for the MPD Specification and resource files have been updated. See Updated URIs section below.

    Removed
    IEM concept has been removed from v1.1 of the MPD Specificaiton. It has been replaced with an updated defintion for MPD.

    Added
    Base Schema Set concept has been added. See MPD v1.1 Section 3.5 (page 22) for more information.

    Modified
    Nature & Purpose Lexicon has been updated with a restructured lexicon. See MPD v1.1 Section 4.2.4 (page 33) and Appendix G (page G-1) for more information

    Modified
    wantlist cardinality for an MPD has been changed to 0, U.

    Modified
    Changed catalog to mpd-catalog.

    Modified
    Rule numbering has been modified in the MPD Specification v1.1. Needs to be reconciled with NIEM-UML. See required changes tab.

    UPDATED URIs

    Updated Specification URI
    http://reference.niem.gov/niem/specification/model-package-description/1.1/

    Updated Lexicon URI:
    http://reference.niem.gov/niem/resource/mpd/lexicon/1.1/

  • Reported: NIEM-UML 1.0b2 — Tue, 6 Nov 2012 05:00 GMT
  • Disposition: Resolved — NIEM-UML 3.0
  • Disposition Summary:

    Not applicable to NIEM-3

    Fixed as part of NIEM-3

  • Updated: Tue, 11 Oct 2016 14:48 GMT

NIEM-UML Issue - General Information Models

  • Key: UMLNIEM3-5
  • Legacy Issue Number: 18174
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Cory Casanave)
  • Summary:

    Issue: NIEM has very specific namespace types such as subset, reference and constraints. These correspond directly to NIEM-UML information model types. User experience has shown that segmenting a model in this way is complex for users and couples the PIM design with the PSM (XSD) representation. It would be preferable that, in the PIM, there was a higher level representation.

    Suggested resolution: Add an information model kind “General” that can subset any other model(s), add properties and include property redefinitions of cardinality and type. To support this king od model, augment the QVT such that a General information model produces, as required, subset schema, constraint schema and extension schema that capture the semantics of the general model using legal NIEM schema.

  • Reported: NIEM-UML 1.0b2 — Wed, 17 Oct 2012 04:00 GMT
  • Disposition: Closed; Out Of Scope — NIEM-UML 3.0
  • Disposition Summary:

    This is an enhancement request

    As an enhancement request, the correct disposition for this is "Closed: Out Of Scope".

  • Updated: Tue, 11 Oct 2016 14:48 GMT

Clause 8 explanation needed

  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The descriptions "Rule is definitional" and "Rule is not reliably computational" occur several times starting on page 153. What exactly do they mean? Also, I assume this is not a description of the element since they are all unique. Therefore is it an editorial comment on the rule itself? Or an explanation as to why there is no OCL? If either one, a general terms and definitions section at the beginning of the chapter would be useful. Also, Constraint is non-computable and The constraint is realized through provisioning. And “Constraint expression as OCL is deferred”: until when is it deferred?
    For this and other reasons, Chapter 8 really needs an introduction to explain what it is, how it works, conventions followed and so forth. As it stands, it is expert friendly: you understand what it means if you understand what it means.

  • Reported: NIEM-UML 3.0b1 — Fri, 7 Aug 2015 08:37 GMT
  • Disposition: Resolved — NIEM-UML 3.0
  • Disposition Summary:

    Clarify clause 8

    Introduce an introductory paragraph into clause 8.1 to assist the reader in understanding the remainder of clause 8.

  • Updated: Tue, 11 Oct 2016 14:48 GMT

Clause 8 figures

  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Figure 8-2: I understand it is easier to have a single diagram followed by an explanation of the contents of that diagram. However, that makes it extremely difficult to review. It would be easier in the future to break the diagram up into smaller parts to make that review simpler. As it stands, there are 40 pages of explanation following the diagram. Same for Figure 8-3.
    Section 8.5.1 has 5 diagrams followed by another 30 pages. This also needs to be broken up.

  • Reported: NIEM-UML 3.0b1 — Fri, 7 Aug 2015 08:36 GMT
  • Disposition: Closed; No Change — NIEM-UML 3.0
  • Disposition Summary:

    Clause 8 overview figures

    The issue asks that the figures in Clause 8 that show the inheritance/extension hierarchies of the stereotypes should be split up. In fact the information in the figures is already repeated in all of the separate stereotype specifications, under the heading Generalization or Extends. Since clause 8 is generated it would be onerous and error-prone to insert small figures into each stereotype specification, and if this were done it would simply duplicate the information already present under Generalization or Extends.

  • Updated: Tue, 11 Oct 2016 14:48 GMT

Clarify Schematron standards

  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Is there a different between "ISO-Schematron" and the "Schematron standard"? 7.7.4.1 Background calls it "ISO-Schematron" in bold and on page 24 it is called the "Schematron standard".

  • Reported: NIEM-UML 3.0b1 — Fri, 7 Aug 2015 08:32 GMT
  • Disposition: Resolved — NIEM-UML 3.0
  • Disposition Summary:

    Consistent referencing of Schematron

    Refer to ISO Schematron in clause 4.1 (definitions) and Schematron elsewhere.

  • Updated: Tue, 11 Oct 2016 14:48 GMT

Clarify NIEMType

  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    "Table 7-5 NIEM Components included in a NIEM Namespace" lists components. On page 53 it states "A class in a PSM with a «NIEMType» stereotype (i.e., one of the stereotypes listed in Table 7-5) applied shall". No reference is made to NIEMType regarding the table and its definitions.

  • Reported: NIEM-UML 3.0b1 — Fri, 7 Aug 2015 08:31 GMT
  • Disposition: Resolved — NIEM-UML 3.0
  • Disposition Summary:

    Correct references to and in Table 7.5

    Firstly, the quoted text in clause 7.3.1.3 PSM to XML Schema Mapping is incorrect: it should refer to Table 7.7, not 7.5. Secondly, in table 7.5, the reference to Class should refer to clause 7.3, not 7.2.3.

  • Updated: Tue, 11 Oct 2016 14:48 GMT

Define abstract elements

  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Table 7-3 lists several elements whose definition is simply Abstract. I would have thought a definition would be required even if it were abstract.

  • Reported: NIEM-UML 3.0b1 — Fri, 7 Aug 2015 08:29 GMT
  • Disposition: Resolved — NIEM-UML 3.0
  • Disposition Summary:

    Document abstract elements in table 7-3

    For each element in table 7-3 whose Note is currently Abstract, replace Abstract by the specification text that appears in the Description section for the corresponding element in clause 8.5. Keep the name of the element in italics but write the Note in normal text. Clarify that italics denotes abstract.

  • Updated: Tue, 11 Oct 2016 14:48 GMT

Spelling errors

  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Table 7.1 title - Summar
    7.2.3.2 - dictionary-stype???
    7.5.2.2 - PSM section - ". In the later case" should be latter
    7.6.2.2 - "the MPD calog"
    7.7.4.2 - "NIEM-UMLas Constraints" space between UML and as
    9.1.1 - Primtive

  • Reported: NIEM-UML 3.0b1 — Fri, 7 Aug 2015 08:44 GMT
  • Disposition: Resolved — NIEM-UML 3.0
  • Disposition Summary:

    Correct spelling errors

    Correct spelling errors and other typos

  • Updated: Tue, 11 Oct 2016 14:48 GMT

Conformance statement

  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The conformance statements are understandable and appear to be reasonable. I do not understand the intention of the final statement in section 2:
    "At some time in the future tools may be developed that can verify these assertions with some degree of confidence."
    It doesn't seem to add any value to the specification.

  • Reported: NIEM-UML 3.0b1 — Fri, 7 Aug 2015 08:41 GMT
  • Disposition: Resolved — NIEM-UML 3.0
  • Disposition Summary:

    Delete redundant conformance statement

    The statement quoted in the issue adds nothing to the specification and should be deleted.

  • Updated: Tue, 11 Oct 2016 14:48 GMT

Trademark

  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Page 23: Model Driven Architecture (MDA) should have a ® by it. Not sure if just once or throughout.

  • Reported: NIEM-UML 3.0b1 — Fri, 7 Aug 2015 08:27 GMT
  • Disposition: Resolved — NIEM-UML 3.0
  • Disposition Summary:

    Correct the trademark omissions

    Include the ® trademark symbol for every occurrence of Model Driven Architecture and MDA

  • Updated: Tue, 11 Oct 2016 14:48 GMT

Clarify ability to apply other profiles

  • Key: UMLNIEM3-9
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Section 2.4 states "The imported UML Packages with only the NIEM PSM Profile applied is a conforming NIEM PSM as defined in Subclause 2.3.". Will this conflict with integration to UPDM as additional profiles may be required?

  • Reported: NIEM-UML 3.0b1 — Fri, 7 Aug 2015 08:22 GMT
  • Disposition: Resolved — NIEM-UML 3.0
  • Disposition Summary:

    Clarification of PSM profile application

    In 2.4, explain that the scope of the statement "only the PSM profile applied" does not apply to unrelated profiles; it only excludes the application of the PIM profile.

  • Updated: Tue, 11 Oct 2016 14:48 GMT

Possibly incorrect statement about conversion transformations

  • Key: UMLNIEM3-8
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In Section 0.3.2 Non-mandatory features you state "Transforming a model from NIEM 2.1 to 3.0 is not included in this specification". However in section 1.4 you state "In addition to the above, NIEM-UML-3 includes transformations to assist in the process of converting from NIEM-2 to NIEM-3." Please explain the contradiction.

  • Reported: NIEM-UML 3.0b1 — Fri, 7 Aug 2015 08:19 GMT
  • Disposition: Resolved — NIEM-UML 3.0
  • Disposition Summary:

    Delete incorrect sentence

    The quoted sentence is untrue. Delete it.

  • Updated: Tue, 11 Oct 2016 14:48 GMT

Describe the embedded links in the introduction

  • Key: UMLNIEM3-7
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The specification has embedded links to internal spec sections as well as to the wider NIEM specification on the government website. I don’t think this was mentioned in the introduction at all. They are useful and should be highlighted as such. My only concern is whether they will be lost when the spec is transferred to the somewhat archaic editing tool used by the OMG.

  • Reported: NIEM-UML 3.0b1 — Fri, 7 Aug 2015 08:17 GMT
  • Disposition: Resolved — NIEM-UML 3.0
  • Disposition Summary:

    Mention hyperlinks in introductory material

    Insert some words in clause 6.3.3.1 describing the hyperlinks to NIEM-NDR and NIEM-MPD.

  • Updated: Tue, 11 Oct 2016 14:48 GMT

Page 295 -

  • Legacy Issue Number: 18900
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Vijay Mehra)
  • Summary:

    Page 295 -

    B.2.9.8 Mapping a

    {schema:element declaration}

    Change line item in paragraph [Rule: Mapping for an Unstereotyped Content Element Declaration

    {uml:Property}

    ]

    From:

    5. (substitution group affiliation property) A mapping must exist between the substitution group affiliation of the

    {schema:element declaration}

    and the subsettedProperty of the

    {uml:Property}

    .

    To:

    5. (substitution group affiliation property) The mapping for the substitution group affiliation property is as follows:

    a. If there is exactly one subsettedProperty, a mapping must exist between the substitution group affiliation of the

    {schema:element declaration}

    and the subsettedProperty of the

    {uml:Property}

    .

    b. If there is not any subsettedProperty and if the type is a categorized

    {stereotype:AugmentationType}

    , the substitution group affiliation must be s:Augmentation.

  • Reported: NIEM-UML 1.0b2 — Wed, 11 Sep 2013 04:00 GMT
  • Disposition: Resolved — NIEM-UML 1.0
  • Disposition Summary:

    Agree with the issue

  • Updated: Fri, 6 Mar 2015 21:49 GMT

Page 240 editorial

  • Key: UMLNIEM_-9
  • Legacy Issue Number: 18897
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Vijay Mehra)
  • Summary:

    Page 240 -

    Clause A.18:

    • Change “Person” to “AdoptingPerson”, subclassing NIEM-Core subset “Person”
  • Reported: NIEM-UML 1.0b2 — Wed, 11 Sep 2013 04:00 GMT
  • Disposition: Resolved — NIEM-UML 1.0
  • Disposition Summary:

    Agree with the issue

  • Updated: Fri, 6 Mar 2015 21:49 GMT

Page 227 - typo

  • Key: UMLNIEM_-8
  • Legacy Issue Number: 18896
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Vijay Mehra)
  • Summary:

    Page 227 - Replace

    Also, the roles a person play may change over time.

    with

    Also, the roles a person plays may change over time.

  • Reported: NIEM-UML 1.0b2 — Wed, 11 Sep 2013 04:00 GMT
  • Disposition: Resolved — NIEM-UML 1.0
  • Disposition Summary:

    Agree with the issue.

  • Updated: Fri, 6 Mar 2015 21:49 GMT

P)age 226

  • Key: UMLNIEM_-7
  • Legacy Issue Number: 18895
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Vijay Mehra)
  • Summary:

    Page 226 - Replace

    What we did is just pick 2 properties that we want out NIEM-Core person

    with

    What we did is just pick 2 properties that we want out of NIEM-Core person

  • Reported: NIEM-UML 1.0b2 — Wed, 11 Sep 2013 04:00 GMT
  • Disposition: Resolved — NIEM-UML 1.0
  • Disposition Summary:

    Agree with the issue

  • Updated: Fri, 6 Mar 2015 21:49 GMT

Page 264 text update

  • Legacy Issue Number: 18899
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Vijay Mehra)
  • Summary:

    Page 264 -

    B.2.6.6 Categorized

    {uml:Class}

    [Definition: Category 3

    {uml:Class}

    ]

    Replace text:

    3. that is the specific

    {uml:Classifier}

    of exactly one

    {uml:Generalization}

    with:

    3. that is the specific

    {uml:Classifier}

    of exactly one

    {uml:Generalization}

    , the general

    {uml:Classifier}

    of which corresponds to a

    {schema:complex type definition with complex content}

    ..

  • Reported: NIEM-UML 1.0b2 — Wed, 11 Sep 2013 04:00 GMT
  • Disposition: Resolved — NIEM-UML 1.0
  • Disposition Summary:

    Agree with the issue

  • Updated: Fri, 6 Mar 2015 21:49 GMT

Page 243 - typo

  • Legacy Issue Number: 18898
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Vijay Mehra)
  • Summary:

    Page 243 - Replace

    For each such exchange type we need to add a property to the “Exchange Schema”, this is done my just making one property for each exchange type in a property holder.

    with

    For each such exchange type we need to add a property to the “Exchange Schema”, this is done by just making one property for each exchange type in a property holder.

  • Reported: NIEM-UML 1.0b2 — Wed, 11 Sep 2013 04:00 GMT
  • Disposition: Resolved — NIEM-UML 1.0
  • Disposition Summary:

    Agree with the issue

  • Updated: Fri, 6 Mar 2015 21:49 GMT

8-1, 8-3, 8-5

  • Key: UMLNIEM_-2
  • Legacy Issue Number: 18878
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Cory Casanave)
  • Summary:

    Some prior resolutions for NIEM-UML issues did not specify that the diagrams should be updated to reflect the model and text changes as well as the changes in the specification URIs. The following diagrams should replace diagrams: 8-1, 8-3, 8-5, respectively.

    Replace 8-1 with:

    Replace 8-3 with:

    Replace 8-5 with:

  • Reported: NIEM-UML 1.0b2 — Fri, 23 Aug 2013 04:00 GMT
  • Disposition: Resolved — NIEM-UML 1.0
  • Disposition Summary:

    Agree with the issue, and diagrams 8-1, 8-3, and 8-5 will be updated

  • Updated: Fri, 6 Mar 2015 21:49 GMT

"Pet" example has errors

  • Key: UMLNIEM_-1
  • Legacy Issue Number: 18238
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Cory Casanave)
  • Summary:

    The "pet" example has errors that should be fixed as the example provides guidence on the proper use of NIEM-UML.

    Issues include:

    • New types should not be defined in the exchange model
    • Properties (as association ends) should not be added to subset types.
  • Reported: NIEM-UML 1.0b2 — Tue, 30 Oct 2012 04:00 GMT
  • Disposition: Resolved — NIEM-UML 1.0
  • Disposition Summary:

    The mode and text have been revised as indicated below. This includes:

    • Proper use of Subsets Vs References (Issue 18538 impacts Issue 18238 being correct thus changes to the “Pet” example for issue 18538 are included here)
    • Person from NIEM Core should not have new properties, AdoptingPerson is added as a substype.
    • “Identification” is consistently named “IdentificationType”
    • Clarification are added
  • Updated: Fri, 6 Mar 2015 21:49 GMT

Page 3 wording change

  • Key: UMLNIEM_-4
  • Legacy Issue Number: 18892
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Vijay Mehra)
  • Summary:

    Page 3 – Replace:

    The FTF Recommendation and Report for this specification will be published on November 12, 2012. If you are reading this after that date, please download the available specification from the OMG Specifications Catalog.

    With

    The FTF Recommendation and Report for this specification will be published in November, 2013. If you are reading this after that date, please download the available specification from the OMG Specifications Catalog.

  • Reported: NIEM-UML 1.0b2 — Wed, 11 Sep 2013 04:00 GMT
  • Disposition: Resolved — NIEM-UML 1.0
  • Disposition Summary:

    Agree with the issue

  • Updated: Fri, 6 Mar 2015 21:49 GMT

XSDRestrictionComplexTypeSimpleContent OCL Issue

  • Key: UMLNIEM_-3
  • Legacy Issue Number: 18879
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Cory Casanave)
  • Summary:

    The OCL for the constraint titled “XSDRestrictionComplexTypeSimpleContent” is incorrect, the following changes should be made:

    Change “NIEMSimpleContent” to “XSDSimpleContent” on lines 3 and 6

    Change “specificl” to “specific” on line 5

  • Reported: NIEM-UML 1.0b2 — Fri, 23 Aug 2013 04:00 GMT
  • Disposition: Resolved — NIEM-UML 1.0
  • Disposition Summary:

    Agree with the proposed changes

  • Updated: Fri, 6 Mar 2015 21:49 GMT

Page 225

  • Key: UMLNIEM_-6
  • Legacy Issue Number: 18894
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Vijay Mehra)
  • Summary:

    Page 225 - Replace

    A subset information model has a <<Subsets>> to the model it subsets. Everything in that subset namespace will be automatically (by name) subsets the corresponding element in the reference namespace.

    with

    A subset information model has a <<Subsets>> relationship to the model it subsets. Everything in that subset namespace automatically (by name) subsets the corresponding element in the reference namespace

  • Reported: NIEM-UML 1.0b2 — Wed, 11 Sep 2013 04:00 GMT
  • Disposition: Resolved — NIEM-UML 1.0
  • Disposition Summary:

    Agree with the issue

  • Updated: Fri, 6 Mar 2015 21:49 GMT

Page 4 typo

  • Key: UMLNIEM_-5
  • Legacy Issue Number: 18893
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Vijay Mehra)
  • Summary:

    Page 4 - Replace

    All instances of ‘© 2012’

    With

    ‘© 2012-2013’

  • Reported: NIEM-UML 1.0b2 — Wed, 11 Sep 2013 04:00 GMT
  • Disposition: Resolved — NIEM-UML 1.0
  • Disposition Summary:

    Agree with the issue.

  • Updated: Fri, 6 Mar 2015 21:49 GMT

NIEM-UML PurposeCode changelog

  • Key: UMLNIEM-4
  • Legacy Issue Number: 18178
  • Status: closed  
  • Source: Visumpoint ( Tom Digre)
  • Summary:

    Issue: The MPD Specification enumerates NIEM purposes. Those purposes are reflected in the NIEM-UML Enumeration at NIEM_UML::Model_Package_Description_Profile::PurposeCode. The MPD Specified NIEM purpose of "changelog" is not reflected in the NIEM-UML Enumeration.

    Suggested resolution: Add an EnumerationLiteral "changelog" to the NIEM-UML Enumeration at NIEM_UML::Model_Package_Description_Profile::PurposeCode. Description: Serves the purpose of recording all changes (additions, deletions, modifications) to a model package description relative to a previous version.

  • Reported: NIEM-UML 1.0b1 — Thu, 18 Oct 2012 04:00 GMT
  • Disposition: Resolved — NIEM-UML 1.0b2
  • Disposition Summary:

    Suggested Resolution:
    Add the missing EnumerationLiterals to the Enumerations <Enumeration> PurposeCode and <Enumeration> NatureCode.
    Resolution:
    The suggested resolution is accepted.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

NIEM-UML Issue - NIEM-UML Design rules

  • Key: UMLNIEM-3
  • Legacy Issue Number: 18175
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Cory Casanave)
  • Summary:

    Issue: The correspondence between the UML representation of NIEM and the NDR is not always clear. This results in users creating invalid UML models that then create invalid NIEM XSD.

    Suggested resolution: Create “Model Design Rules” (MDR) for NIEM that specifies the construction rules for a valid NIEM-UML model.

  • Reported: NIEM-UML 1.0b1 — Wed, 17 Oct 2012 04:00 GMT
  • Disposition: Resolved — NIEM-UML 1.0b2
  • Disposition Summary:

    Agree with the suggested resolution. Sub-Clause 7.7 has been added to the specification to address the issue, and provide additional clarification and guidance related ‘modelling design rules’ for NIEM.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

NIEM-UML FTF Issue: Namespace prefix

  • Key: UMLNIEM-2
  • Legacy Issue Number: 17572
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Cory Casanave)
  • Summary:

    The NIEM community as well as IEPD developers have accepted prefixes for namespaces. There is no way to represent these prefixes in the profile resulting in meaningless machine generated prefixes in generated XSDs and XML documents. While this does not impact the formal interpretation of the namespaces, it does impact the human usability of those namespaces. However, due to possible redundancy only a default can be guaranteed.

    Recommended resolution:

    The “Namespace” stereotype should include a “DefaultPrefix” tag of type string to represent these common prefixes. This prefix should be used on all XML/XSD serializations using that namespace unless it conflicts with another. If there is a conflict the mapping should append a number to the default prefix to make it unique.

  • Reported: NIEM-UML 1.0b1 — Wed, 29 Aug 2012 04:00 GMT
  • Disposition: Resolved — NIEM-UML 1.0b2
  • Disposition Summary:

    The “Namespace” stereotype should include a “DefaultPrefix” tag of type string to represent these common prefixes. This prefix should be used on all XML/XSD serializations using that namespace unless it conflicts with another. If there is a conflict the mapping should append a number to the default prefix to make it unique.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistency in NIEM-UML URIs

  • Key: UMLNIEM-1
  • Legacy Issue Number: 17545
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: UML Profile for NIEM (NIEM-UML), FTF Beta 1 (dtc/2012-07-09)

    The URIs listed on the cover page and in Annex C of the NIEM-UML Beta 1 document all begin with “http://www.omg.org/spec/NIEM_UML”. However, all the normative XMI files, as submitted, use “http://www.omg.org/spec/NIEM-UML” (hyphen instead of underscore in “NIEM-UML”). Further, the normative URIs for the profiles in the NIEM-UML profile model all use the “NIEM-UML” form (as is visible on the diagram in Figure 8-1 in the spec document).

    On or the other form of URI should be used consistently. Using “NIEM-UML” is recommended, since it is more consistent with how other elements of some of the URIs are written, such as “NIEM-Reference”, and because underscores don’t show up well when URIs are displayed with underlines.

  • Reported: NIEM-UML 1.0b1 — Wed, 8 Aug 2012 04:00 GMT
  • Disposition: Resolved — NIEM-UML 1.0b2
  • Disposition Summary:

    Agreed that “NIEM-UML” should be used consistently in all listed URIs.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

NIEM-UML Property <> Ambiguity

  • Key: UMLNIEM-9
  • Legacy Issue Number: 18538
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Cory Casanave)
  • Summary:

    (Background)

    The NIEM-UML specification states for <<References>>, from Clause 8.2:
    ...If a Property is the client of a References Realization, then it represents a NIEM property defined by reference to the NIEM property declaration represented by the supplier of the Realization. It is implemented in XSD schema as an attribute use or element particle that references the attribute or element declaration that implements the supplier of the Realization. ...

    From Clause 7.5.2 Property Holders and Property References/Representation

    Common

    …The client UML property of a «References» realization represents the use, in the context of the complex type represented by the owning class of the property, of the NIEM property declared by the supplier UML property of the realization….

    PSM

    A property reference is implemented as an attribute use or element particle referencing the corresponding declaration. If the UML property representing the property declaration is contained in a different «Namespace» package than the UML property representing the property reference, then the implementation of the property reference will refer to a declaration in a different schema.

    From Clause 7.5.2.3 Mapping Summary (part of Clause 7.5.2 referenced above)

    PIM to PSM Mapping

    …A realization between two properties in a PIM with the stereotype «References» applied shall map to a corresponding realization in the PSM with the «References» stereotype applied, between corresponding properties mapped from the PIM. …

    PSM to XML Schema Mapping

    …A property in a PSM that is owned by a class with the «PropertyHolder» shall be mapped as an attribute or element declaration…

    …A property in a PSM that is the client of a «References» or «XSDDeclaration» realization whose supplier has a different target namespace shall be mapped as an attribute use or element particle… The attribute use or element particle shall have its ref attribute set to the attribute or element declaration mapped from the supplier of the realization.

    A summary of the above excerpts for a <<References>> is:

    · The client is mapped to an attribute use or element particle, within a type, within a schema having some targetNamespace, and the schema is located at a file location within the MPD as specified by the MPD catalog.

    · The supplier is mapped to a top level attribute or element declaration, within a schema having some targetNamespace, and the schema is located at a file location within the MPD as specified by the MPD catalog.

    Conflict:

    From the "Guide" portion of the NIEM-UML spec, for a PIM:

    Any use in the subset package of an element (e.g., classifier or property) from the reference package is considered to instead refer to a similarly named element included in the subset package. In particular, the use of a property declaration from the reference package as the supplier of a «References» realization from an element of the subset package results in the reference actually being to a corresponding property declaration in the subset package.

    This overloading of the <<References>> was originally deemed feasible based on the following assumptions:

    Distinction between the two meanings of <<References>> could be determined by distinguishing whether or not the supplier was in a reference model and the client was not in a subset model.
    The primary use of the PIM meaning of <<References>> would be with respect to transforming to a subset model which was wired up according to this description. Other uses of the model, such as defining business constraints as OCL, or instantiating instances of an exchange, were not part of the consideration for this meaning of <<References>>.
    There was only one reference model and only one corresponding subset model visible within the scope of an IEPD.
    These assumptions are now known to be too simplistic:

    · Some form of controlled modification (e.g., subsetting) of namespace content occurs between different types of models at many levels:

    o Domain and Core Updates. Change and/or extend reference models, derived product is a reference model.

    o EIEM. “Subset” reference models, derived product is typically a subset model but may sometimes be tagged as a reference model. EIEM will also introduce extension models and control visibility of NIEM reference models.

    o IEPD. May “subset” reference models with derived product being a subset model. May “subset” EIEM provided subset models, with derived product a subset model. May “subset” EIEM provided extension models, with derived product an extension model.

    o Constraints. May be based on reference, subset, extension, exchange; derived product is termed a constraint model.

    · Multiple models with same target namespace will be visible to the modeler. Many times an IEPD model will contain multiple exchange models, each based on different derivations of the same NIEM reference model. For example, there may be a “request” exchange model and a “response” exchange model. Each exchange model may be based on a different subset of an EIEM subset of a NIEM reference model. Thus, in this scenario, the modeler will have visibility to his request nc subset, his response nc subset, an EIEM nc subset, the original NIEM reference model, and some nc constraint models. Additionally, the modeler may use the EIEM subset models directly rather than going through his own subsetting process.

    When a modeler references a Property, he is not just referencing a target namespace, but a specific model, which has its unique location. Since subsetting may be across almost any kind of model, it becomes unclear how to interpret a <<References>> to a subset model: is it intended to be in the role of a “base” model for derivation purposes, is it intended to be in the role of a “base” model for a “base” model of a derivation, is it intended to be a reusable component of an EIEM defined model (which may have a derived model elsewhere in the IEPD), is it intended to be the derived model? When it is intended to be the “base” model, which “derived” model amongst several, with the same namespace, in an MPD would it be? Failure to unambiguously resolve these derivations may lead to lack of coherence in provisioned MPDs, with multiple conflicting schema locations for the same namespace within a given exchange schema set, which in turn will result in schema validation failures.

    Additionally, in cases of business constraints represented as OCL:

    The use of references to reference model types/properties as implicit references to subset types/properties would prevent proper validation of OCL. The reference model is bigger than the subset model, and it would not be possible to determine if references to types/properties within the OCL were valid in the context of a particular exchange, with its constrained view of subset models.
    And for instance models:

    The instantiation of references to a reference model would necessarily require instantiation of reference model components to maintain a well-formed UML model. It would not be possible to access or represent extensions such as subtypes or substitution groups from the reference model instantiation.
    Execution of the OCL validation for instance models would be subject to the composite set of issues with OCL and instantiation representations.
    The implicit version of Property <<References>> was originally intended to provide some level of abstraction over the concrete form of Property <<References>>. Concrete <<References>> are required to unambiguously define coherent exchange schema sets, business constraints, instance models, and constraint validation of instance models. Nevertheless, a distinguishable markup for the more abstract representation of property derivation (and type references) could serve a complementary role. In the context of an Enterprise developing IEPDs, the set of shareable components known as an EIEM is often volatile. The names and other characteristics of the components change, which impact the derived IEPDs. A mechanism to establish a relationship between an IEPD and its corresponding EIEM components would enable a smoother transition across EIEM versions. For example, the use of markup establishing refs from property uses to declarations could partially automate changes in the concrete representation of names, types, and other characteristics of base components at the IEPD level. However, the suggested resolution for this issue does not include new markup.

    Suggested resolution

    The suggested resolution is to add a <<Subsets>> stereotype as a specialization of <<References>>. This stereotype should always be used between a subset and a reference model. <<References>> between packages interpreted as a <<subsets>> should be retained for backwards compatibility.

  • Reported: NIEM-UML 1.0b1 — Fri, 8 Mar 2013 05:00 GMT
  • Disposition: Resolved — NIEM-UML 1.0b2
  • Disposition Summary:

    Suggested Resolution:
    Add stereotype and supporting transformations as per issue.
    Resolution:
    The suggested resolution is accepted. The Stereotype <<Subsets>> will be used for all relations between a subset model and a reference model. For backwards compatibility, <<References>> will be supported between information models (but not between classes) for subset purposes – but this representation is depreciated. <<References>> will then be used between a property and an external definition of that property.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Problem with XmiPrimitiveTypes.xmi in the NIEM specification


NIEM-UML Issue - Changelog

  • Key: UMLNIEM-5
  • Legacy Issue Number: 18179
  • Status: closed  
  • Source: Visumpoint ( Tom Digre)
  • Summary:

    Issue: The MPD Specification includes several rules related to the requirement that MPDs must have changelogs. These rules are:

    [Rule 4-11] Every MPD that is a reference schema set (i.e., NIEM releases, core updates, and domain updates) MUST contain an XML change log artifact that:
    • Validates with the NIEM change log schemas (mpd-changelog.xsd andd niem-model.xsd).
    Note: These are the base filenames; the actual filenames also contain a version number. For example: mpd-changelog-1.0.xsd is the current version.
    • Records changes to previous reference schemas that thiss MPD represents.
    • Bears the file name "changelog.xml".
    â• Resides in the root directory of the MPD.

    [Rule 4-12] Every MPD that is an IEPD or EIEM MUST contain a change log artifact that:
    • Recordss changes to previous IEPD or EIEM schemas that this MPD represents.
    • Begins with the substring ""changelog".
    • Resides in the root directory of the MPD.

    [Rule 4-13] The initial version of an IEPD or EIEM MUST contain a change log artifact with at least one entry for its creation date.

    [Rule 4-13.1] If an IEPD or EIEM contains more than one change log artifact, then each change log artifact MUST:
    • Have a file name that begins with the substrinng "changelog".
    • Reside in the MPD root directory .
    >

    While the majority of an MPD-conformant changelog can be constructed from model version change analysis, there are some description fields that probably require editing by the modeler. These include:
    ChangeLogType
    ChangeLogSummaryText (String)

    ChangeLogSubmitterName (String)

    ChangeLogApplicationInstructionsText (String)
    ChangeInformationType
    ChangeSummaryText(String)
    ChangeReasonText (String)

    ChangeFullDescriptionText (String)

    ChangeNCCTIssueNumber (Integer)

    ChangeCode (Enumeration)

    Suggested resolution: Add the following to Profile NIEM_UML::Model_Package_Description_Profile
    Stereotype ChangeLogType (no specific recommendation on extension at this time)

    Tag ChangeLogSummaryText (String 0..1)
    Tag ChangeLogSubmitterName (String 0..1)
    Tag ChangeLogApplicationInstructionsText (String 0..1)
    Stereotype ChangeInformationType (no specific recommendation on extension at this time)
    Tag ChangeSummaryText (String 0..1)
    Tag ChangeReasonText (String 0..1)
    Tag ChangeFullDescriptionText (String 0..1)
    Tag ChangeNCCTIssueNumber (Integer 0..*)
    Tag ChangeCode (ChangeCodeSimpleType 0..*)
    Enumeration ChangeCodeSimpleType
    EnumerationLiteral new_requirement
    EnumerationLiteral bug_fix
    EnumerationLiteral refactoring
    EnumerationLiteral harmonization
    EnumerationLiteral general_improvement

  • Reported: NIEM-UML 1.0b1 — Thu, 18 Oct 2012 04:00 GMT
  • Disposition: Resolved — NIEM-UML 1.0b2
  • Disposition Summary:

    Suggested Resolution:
    Add the following to Profile NIEM_UML::Model_Package_Description_Profile
    Stereotype ChangeLogType (no specific recommendation on extension at this time)
    • Tag ChangeLogSummaryText (String 0..1)
    • Tag ChangeLogSubmitterName (String 0..1)
    • Tag ChangeLogApplicationInstructionsText (String 0..1)

    Stereotype ChangeInformationType (no specific recommendation on extension at this time)
    • Tag ChangeSummaryText (String 0..1)
    • Tag ChangeReasonText (String 0..1)
    • Tag ChangeFullDescriptionText (String 0..1)
    • Tag ChangeNCCTIssueNumber (Integer 0..*)
    • Tag ChangeCode (ChangeCodeSimpleType 0..*)

    Enumeration ChangeCodeSimpleType
    EnumerationLiteral new_requirement
    EnumerationLiteral bug_fix
    EnumerationLiteral refactoring
    EnumerationLiteral harmonization
    EnumerationLiteral general_improvement

    Resolution:
    The suggested resolution is accepted.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

PSM Representation for XSD Complex Type with Simple Content

  • Key: UMLNIEM-8
  • Legacy Issue Number: 18361
  • Status: closed  
  • Source: Visumpoint ( Tom Digre)
  • Summary:

    The PSM perspective of the current NIEM-UML Profile does not support constraint restrictions for XSD Complex Types with Simple Content.
    This capability is needed in extension schemas to help support enterprise/domain/exchange/context specific type constraints.
    The attached document provides some explanation of the requirement, the issue, and a proposed profile change

  • Reported: NIEM-UML 1.0b1 — Fri, 28 Dec 2012 05:00 GMT
  • Disposition: Resolved — NIEM-UML 1.0b2
  • Disposition Summary:

    Suggested Resolution:
    To enable representation of constraints on Complex Types with simple content (for models other than reference models), the following model construct changes/clarifications are proposed:
    • In the PSM perspective, a Class representing Complex Type with Simple Content (CSC) restricting (via <<Restriction>> Realization) another CSC, may define constraining facets via a DataType. In this case, there must be an <<XSDSimpleContent>> Realization whose supplier is the DataType and whose client is the CSC. The <<Restriction>> Realization is implemented in XML Schema through the base attribute on the xsd:restriction element of the CSC (as previously). The constraining facets defined by the DataType are used to populate the content of the xsd:restriction.
    • The mapping from PIM to PSM includes a fabricated DataType and <<XSDSimpleContent>> Realization to represent the constraints modeled within the PIM perspective.
    Resolution:
    The suggested resolution is accepted. Within the PSM perspective, constraining facets on a UML Class representing Complex Type with Simple Content (CSC), which is a restriction of another CSC, shall be represented using the <<XSDSimpleContent>> Realization and a DataType defining the facets.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

NIEM-UML Issue: Constraint schema and other constraint/rule support

  • Key: UMLNIEM-7
  • Legacy Issue Number: 18251
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Cory Casanave)
  • Summary:

    NIEM-UML does not currently support constraint schema, a NIEM feature needed by many practitioners. Constraint schema and other mechanisms for constraints and rules should be provided for in NIEM-UML.

    As constraints and schema are essentially “unbounded”, specific features and their UML representation needed should be identified. This should include:

    · Multiple subsets of the same class that may have different properties for different needs

    · Subsets that constrain property types to subtypes that are not in the reference schema

    · Changes in cardinality or aggregation

    · Arbitrary OCL expressions

    The profile should allow an information model to be marked as also generating one or more constraint mechanisms including constraint schema, OCL engines and schematron. However, only the mapping to constraint schema need be defined at this time. In providing for this capability the complexity for the modeler should be minimized – the constraints should be able to be expressed in the same package and elements as the NIEM schema types (e.g. subset and extension schema).

  • Reported: NIEM-UML 1.0b1 — Tue, 6 Nov 2012 05:00 GMT
  • Disposition: Resolved — NIEM-UML 1.0b2
  • Disposition Summary:

    Suggested Resolution:
    In the PIM Perspective, a subset <<InformationModel>> may override the type of a reference <<InformationModel>> Property. The overridden type must be a subtype of the reference <<InformationModel>> Property type. The transformation to the PSM Perspective results in a schema set which enforces the original reference <<InformationModel>> Property types, plus a constraint schema set which reflects the Property type overrides.
    Resolution:
    The suggested resolution is accepted. Clauses 7.6.1.2 and 7.6.1.3 are extended with descriptions of modeling subset type constraints in the PIM Perspective, and the mapping of those constraints to the PSM Perspective.

  • Updated: Fri, 6 Mar 2015 20:58 GMT