Issues for Mailing list of the UML Profile for NIEM (NIEM_UML) FInalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 17545: Inconsistency in NIEM-UML URIs
Issue 17572: NIEM-UML FTF Issue: Namespace prefix
Issue 18174: NIEM-UML Issue - General Information Models
Issue 18175: NIEM-UML Issue - NIEM-UML Design rules
Issue 18178: NIEM-UML PurposeCode changelog
Issue 18179: NIEM-UML Issue - Changelog
Issue 18180: Problem with XmiPrimitiveTypes.xmi in the NIEM specification
Issue 18238: "Pet" example has errors
Issue 18250: MPD Specification v1.1 - UML Profile for NIEM Beta Specification Alignment
Issue 18251: NIEM-UML Issue: Constraint schema and other constraint/rule support

Issue 17545: Inconsistency in NIEM-UML URIs (niem-uml-ftf)

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.

 

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.

 

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.

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.

 

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.

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

http://www.omg.org/spec/NIEM_UML/20120501/XmlPrimitiveTypes.xmi  has the following attribute: xmlns:xmi=http://schema.omg.org/spec/XMI/2.1

 

This should be xmlns:xmi=http://www.omg.org/spec/XMI/20110701

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.

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/
 

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