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

NIEM-UML FTF — Closed Issues

Open Closed All
Issues resolved by a task force and approved by Board

Issues Descriptions

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