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 18361: PSM Representation for XSD Complex Type with Simple Content
Issue 18538: NIEM-UML Property <<References>> Ambiguity
Issue 17545: Inconsistency in NIEM-UML URIs (niem-uml-ftf)
Click here for this issue's archive.
Source: Ivar Jacobson International AB (Mr. Ed Seidewitz, eseidewitz(at)ivarjacobson.com)
Nature: Uncategorized Issue
Severity:
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.
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).
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
(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.