${taskforce.name} Avatar
  1. OMG Task Force

NIEM-UML 3.0 FTF — All Issues

Open Closed All
All Issues

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

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