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?

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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)” .

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.

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

For more information, see attachment

Not applicable to NIEM-3

Resolved as part of NIEM-3

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.

No longer relevant for NIEM-3

Changes in NIEM make this issue irrelevant.

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.

Fixed as part of NIEM3 submission

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

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/

Not applicable to NIEM-3

Fixed as part of NIEM-3

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.

This is an enhancement request

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

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.

Clarify clause 8

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

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.

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.

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

Consistent referencing of Schematron

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

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

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.

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.

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.

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

Correct spelling errors

Correct spelling errors and other typos

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.

Delete redundant conformance statement

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

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

Correct the trademark omissions

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

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?

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.

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.

Delete incorrect sentence

The quoted sentence is untrue. Delete it.

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.

Mention hyperlinks in introductory material

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