NIEM-UML leverages three profiles. The NIEM PIM Profile is used for NIEM PIMs. The NIEM
PSM Profile is used for NIEM PSMs and may also be used to mark up a NIEM PIM for direct
provisioning of MPD artifacts. Both of these profiles import the NIEM Common Profile, which
contains the core stereotypes used to represent NIEM structures in UML. Finally, the Model
Package Description Profile is used for creating models of MPDs, which may be used in
association with either NIEM PIMs or NIEM PSMs. For convenience, an overall NIEM UML Profile
is also included, which imports the NIEM PIM, NIEM PSM and Model Package Description
Profiles. Applying the single NIEM UML Profile is therefore equivalent to individually
applying all three of the imported profiles.
The NIEM Common Profile comprises stereotypes that are used in both the NIEM PIM
Profile and the NIEM PSM Profile. In addition, the UML metamodel subset covered by the
NIEM Common Profile also includes the metaclasses PrimitiveType, Enumeration,
EnumerationLiteral, Property and Generalization, even though they are not specifically
extended by any stereotypes in the profile.
NIEM_Common_Profile
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> A Documentation Comment is the data definition of the Element that
owns it. For an Element owning only one Comment, that Comment will be inferred to be a
Documentation Comment. </p> <p> A Documentation Comment
owned by an Element representing a NIEM type or property is implemented as a
documentation element of the annotation for the corresponding type definition or
property declaration. </p> </body> </html> ng
type definition or property declaration. </p> </body>
</html> </html>
Documentation
The owner of a Documentation Comment must have no other Documentation Comments.
Max One <<Documentation>> per Element
OCL2.0
self.base_Comment.annotatedElement->notEmpty() and
self.base_Comment.annotatedElement->forAll(e|e=self.base_Comment.owner) and
(self.base_Comment.owner.ownedComment->select(c|c.stereotypedBy('Documentation'))->size()=1)
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-14] (REF, EXT)</b> A
component definition SHALL begin with a standard opening phrase that depends on the
class of the component per Table 7-1 in NDR: Standard Opening Phrases:
</p> <p> <b>Rationale</b> A
standard opening phrase based on component class helps to ensure consistent
definitions that appropriate for the type of component item being defined. These
opening phrases also provide a cue that facilitates recognition of the particular kind
of component. </p> </body> </html> s
recognition of the particular kind of component. </p>
</body> </html> </html>
NDR [Rule 7-14]
OCL2.0
self.base_Comment.profiledBy('NIEM_PSM_Profile') implies ( (
self.base_Comment.owner.stereotypedBy('AssociationType') implies
self.base_Comment.body.startsWith('A relationship ') ) and (
self.base_Comment.owner.stereotypedBy('AugmentationType') implies
self.base_Comment.body.startsWith('Supplements ') ) and (
self.base_Comment.owner.oclAsType(NamedElement).name.match('.*Indicator.*') implies
self.base_Comment.body.startsWith('True if ') ) and (
self.base_Comment.owner.oclIsKindOf(DataType) implies
self.base_Comment.body.startsWith('A data type for ') ) ) ) if(
(self.oclIsKindOf(ndr::ndrComplexTypeDefinition)and self.abstract) or
(self.stereotypedBy('niem::ndr::ndrElementDeclaration')and self.abstract)
)then(self.componentDefinition.startsWith('A data concept for a ') )else(
if(self.stereotypedBy('niem::ndr::ndrRoleType'))
then(self.componentDefinition.startsWith('Acts as ') )else( )else(
if(self.stereotypedBy('niem::ndr::ndrSimpleTypeDefinition'))
then(self.componentDefinition.startsWith('A data type for ') )else(
self.componentDefinition.startsWith('A ') or self.componentDefinition.startsWith('An
') )endif )endif )endif )endif )endif )endif
public
base_Comment
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> A MetadataType is a NIEMType Class that represents a NIEM metadata
type. A NIEM metadata type describes data about data, that is, information that is not
descriptive of objects and their relationships, but is descriptive of the data itself.
Metadata is specified as an instance of a metadata type and may include information such
as the security of a piece of data or the source of the data. The applicability of such
metadata may be modeled using MetadataApplication dependencies to one or more classes
representing the applicable types. </p> <p> MetadataType is
implemented in XML Schema as a complex type definition with complex content. Section 3.4
of <a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/">XML
Schema Structures</a> addresses complex type definitions in XML Schema;
Section 7.4.4 of <a
href="http://reference.niem.gov/niem/specification/naming-and-design-rules/1.3/">NIEM
NDR v1.3</a> addresses metadata types in NIEM-conformant XML Schema.
</p> </body> </html> rules/1.3/">NIEM
NDR v1.3</a> addresses metadata types in NIEM-conformant XML Schema.
</p> </body> </html> body>
</html>
MetadataType
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-44] (REF, SUB, EXT)</b>
Within the schema, a metadata type and only a metadata type SHALL be derived directly
from structures:MetadataType. </p> <p>
<b>Rationale</b> A metadata type establishes a specific,
named aggregation of data about data. Any type derived from structures:MetadataType is
a metadata type. Metadata types should not be derived from other metadata types. Such
metadata types should be used as is and additional metadata types defined for
additional content. </p> </body> </html>
additional metadata types defined for additional content. </p>
</body> </html> </html>
NDR [Rule 7-44]
OCL2.0
self.base_Class.general->select(g|g.stereotypedBy('MetadataType'))->isEmpty()
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-14] (REF, EXT)</b> A
component definition SHALL begin with a standard opening phrase that depends on the
class of the component per Table 7-1 in NDR: Standard Opening Phrases:
</p> <p> <b>Rationale</b> A
standard opening phrase based on component class helps to ensure consistent
definitions that appropriate for the type of component item being defined. These
opening phrases also provide a cue that facilitates recognition of the particular kind
of component. </p> </body> </html> s
recognition of the particular kind of component. </p>
</body> </html> </html>
NDR [Rule 7-14]
OCL2.0
self.base_Class.profiledBy('NIEM_PSM_Profile') implies
self.base_Class.ownedComment ->exists(documentation|
documentation.stereotypedBy('Documentation') and ( documentation.body.startsWith('A
data type for metadata about ') or documentation.body.startsWith('A data type for
information that further qualifies ') ) )
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 9-29] (REF, SUB, EXT)</b>
Within the schema, any metadata type SHALL have a name that uses the representation
term qualifier Metadata. Types other than metadata types SHALL NOT use the
representation term qualifier Metadata. </p> <p>
<b>Rationale</b> Using the qualifier Metadata immediately
identifies a type as representing metadata. </p> </body>
</html> ies a type as representing metadata. </p>
</body> </html> body> </html>
NDR [Rule 9-29]
OCL2.0
self.base_Class.profiledBy('NIEM_PSM_Profile') implies
self.base_Class.name.match('.*MetadataType')) --For PIM Profile, the naming constraint
is enforced by PIM/PSM transformations.
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 7-43] (REF, SUB, EXT)</b> Within the schema, a
metadata type SHALL contain elements appropriate for a specific class of data about
data. </body> </html> ata. </body>
</html> l>
NDR [Rule 7-43]
English
Containing Elements appropriate for a specific class of data about data is a
Non-computational constraint.
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> ObjectType is a NIEMType Class that represents a NIEM object type. A
NIEM object type represents some kind of object: a thing with its own lifespan that has
some existence. The object may or may not be a physical object. It may be a conceptual
object. </p> <p> ObjectType is implemented in XML Schema as
a complex type definition. Section 3.4 of <a
href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/">XML Schema
Structures</a> addresses complex type definitions in XML Schema; Section
7.4.1 of <a
href="http://reference.niem.gov/niem/specification/naming-and-design-rules/1.3/">NIEM
NDR v1.3</a> addresses object types in NIEM-conformant XML Schema.
</p> </body> </html> R v1.3</a>
addresses object types in NIEM-conformant XML Schema. </p>
</body> </html> </html>
ObjectType
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> Within the schema, an object type SHALL be a complex type definition
that either constitutes a NIEM-conformant component or for which there exists a
NIEM-conformant component of one of the following forms: </p>
<ol> <li> Has simple content, is based on a simple type,
and contains the attribute group structures:SimpleObjectAttributeGroup, and has
application information appinfo:Base of structures:Object. </li>
<li> Has complex content, and is based on complex type
structures:ComplexObjectType, and has application information appinfo:Base of
structures:Object. </li> <li> Is a complex type that is
derived from an object type, which is defined according to this rule.
</li> </ol> </body> </html>
<li> Is a complex type that is derived from an object type, which is
defined according to this rule. </li> </ol>
</body> </html> </ol> </body>
</html>
NDR [Rule 7-39] (REF, EXT)
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-14] (REF, EXT)</b> A
component definition SHALL begin with a standard opening phrase that depends on the
class of the component per Table 7-1 in NDR: Standard Opening Phrases:
</p> <p> <b>Rationale</b> A
standard opening phrase based on component class helps to ensure consistent
definitions that appropriate for the type of component item being defined. These
opening phrases also provide a cue that facilitates recognition of the particular kind
of component. </p> </body> </html> s
recognition of the particular kind of component. </p>
</body> </html> </html>
NDR [Rule 7-14]
OCL2.0
self.base_Class.profiledBy('NIEM_PSM_Profile') implies
self.base_Class.ownedComment ->exists(documentation|
documentation.stereotypedBy('Documentation') and ( documentation.body.startsWith('A
data type for a ') or documentation.body.startsWith('A data type for an ') ) )
extension_ComplexType
private
composite
public
extension_NIEMNamespace
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> The MetadataApplication stereotype is a specialization of Application
that is always between a MetadataType Class and another Class. It represents a
constraint on a NIEM metadata type that limits the application of the NIEM metadata type
to specific types. If a MetadataType Class is the client of a MetadataApplication Usage,
then any Property with the MetadataType Class as its type must be for a Class that is a
(direct or indirect) subclass of the supplier Class of the MetadataApplication. A
MetadataType Class may be the client of multiple MetadataApplication Usages, in which
case a Property for it may be in a Class that is a subclass of a supplier Class of any
of the MetadataApplications. If a MetadataType is not a client of any
MetadataApplication, then it applies to any type. </p> <p> A
MetadataApplication Usage is implemented in XML schema as a NIEM AppliesTo element in
the annotation element of the complex type definition represented by the client of the
Usage, referencing the complex type represented by the supplier class of the Usage.
</p> </body> </html> d by the client of the
Usage, referencing the complex type represented by the supplier class of the Usage.
</p> </body> </html> body>
</html>
MetadataApplication
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> A Restriction Realization represents a relationship between two type
definitions: the first is derived by restriction from the second. The two types must
either both be NIEMType Classes or both be DataTypes. If the two types are Classes, then
the attributes of the client class must be a subset of the attributes of the supplier
class and omitted attributes must have a multiplicity lower bound of zero. if the two
classes are DataTypes, then the client type is considered to have a value space that is
a subset of that of the supplier, as may be further specified using a ValueRestriction
stereotype on the client. </p> <p> This relationship is
implemented in XML Schema through the base attribute on the xsd:restriction element of
the first type definition, the actual value of which resolves to the second type
definition. If a type is a ValueRestriction the generalization owned by that type is
implicitly an XSDRestriction. Sections 3.4 and 3.14 of <a
href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/">XML Schema
Structures</a> address the use of restriction in XML Schema; Sections
6.5.2 and 6.5.3 of <a
href="http://reference.niem.gov/niem/specification/naming-and-design-rules/1.3/">NIEM
NDR v1.3</a> address the use of restriction in NIEM-conformant XML Schema.
</p> </body> </html>
ion/naming-and-design-rules/1.3/">NIEM NDR v1.3</a> address the use
of restriction in NIEM-conformant XML Schema. </p> </body>
</html> > </body> </html>
Restriction
If the general Classifier is a NIEMType that is not the client of a
NIEMSimpleContent Realization, the specific Classifier must be a NIEMType that is not
the client of a NIEMSimpleContent Realization.
XSDRestrictionComplexTypeComplexContent
OCL2.0
self.base_Generalization.general.stereotypedBy('NIEMType') and
self.base_Generalization.general.clientDependency->select(d|d.stereotypedBy('NIEMSimpleContent'))->isEmpty()
implies
self.base_Generalization.specificl.clientDependency->select(d|d.stereotypedBy('NIEMSimpleContent'))->isEmpty()
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-53] (REF) </b>Within the
schema, the element xsd:simpleContent MUST have as an immediate child the element
xsd:extension. </p> <p>
<b>Rationale</b> This rule ensures that the definition of
a CSC will use the XML Schema extension facility. This allows for the above cases
while disallowing much more complicated syntactic options available in XML Schema.
</p> <p> Note that the applicability of the above rule
allows for use of xsd:restriction within xsd:simpleContent in subset schemas,
extension schemas, and exchange schemas. </p> </body>
</html> impleContent in subset schemas, extension schemas, and exchange
schemas. </p> </body> </html> body>
</html>
NDR [Rule 6-53]
OCL2.0
self.base_Generalization.specific.owner.getStereotypeApplication('Namespace').purposeURI<>'http://reference.niem.gov/niem/resource/mpd/lexicon/1.0/purpose#reference-schema'
If the general Classifier is a DataType, the specific Classifier must be a
DataType.
XSDRestrictionSimpleType
OCL2.0
self.base_Generalization.general.oclIsKindOf(DataType) implies
self.base_Generalization.specific.oclIsKindOf(DataType)
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-55] (REF)</b> Within the
schema, the element xsd:complexContent MUST have as an immediate child the element
xsd:extension. </p> <p>
<b>Rationale</b> NIEM does not support, as conformant, the
use of complex type restriction. NIEM defines a language, in which specific content is
allowed. It does not specify messages that forbid content. Such restrictions may be
performed in nonconformant schemas or within constraint schemas or other artifacts of
constraint. </p> <p> Note that XML Schema requires use of
the attribute base on xsd:extension. </p> <p> Note also
that the applicability allows for the use of restriction in subset schemas, extension
schemas, exchange schemas, and constraint schemas. </p>
</body> </html> riction in subset schemas, extension
schemas, exchange schemas, and constraint schemas. </p>
</body> </html> > </body>
</html>
NDR [Rule 6-55]
OCL2.0
self.base_Generalization.specific.owner.getStereotypeApplication('Namespace').purposeURI<>'http://reference.niem.gov/niem/resource/mpd/lexicon/1.0/purpose#reference-schema'
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-57] (EXT) </b>Within the
schema, given an element xsd:complexContent with a child xsd:restriction owning an
attribute base, the attribute base MUST have a value that resolves to the name of a
complex type that is a NIEM-conformant component. </p> <p>
<b>[Rationale] </b>This ensures that a CCC defined through
restriction has well-defined semantics. </p> </body>
</html> triction has well-defined semantics. </p>
</body> </html> body> </html>
NDR [Rule 6-57]
OCL2.0
self.base_Generalization.general.stereotypedBy('NIEMType')
If the general Classifier is a NIEMType that is the client of a NIEMSimpleContent
Realization, the specific Classifier must be NIEMType that is the client of a
NIEMSimpleContent Realization.
XSDRestrictionComplexTypeSimpleContent
OCL2.0
self.base_Generalization.general.stereotypedBy('NIEMType') and
self.base_Generalization.general.clientDependency->select(d|d.stereotypedBy('NIEMSimpleContent'))->notEmpty()
implies self.base_Generalization.specific.stereotypedBy('NIEMType') and
self.base_Generalization.specificl.clientDependency->select(d|d.stereotypedBy('NIEMSimpleContent'))->notEmpty()
private
base_Realization
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> The References Stereotype applies to a Realization between Properties,
Classes or Packages. It allows for Properties in one Class to be defined by reference to
Properties in another class. A References Realization between two classes is defined to
be equivalent to having References Realizations between matching Properties of the
Classes where matching is determined by identical NIEM names. A References Realization
between two packages is defined to be equivalent to having References Realizations
between matching Classes contained in the Packages where matching is determined by
having identical NIEM names. Matching is based on the NIEMName of the elements, either
as derived implicitly or as set explicitly using the ReferenceName stereotype.
</p> <p> 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. Note that the
supplier Property may be in a different Namespace than the client property, in which
case the attribute or element declaration represented by the supplier will be in a
different target namespace than the use represented by the client. </p>
</body> </html> ute or element declaration represented by
the supplier will be in a different target namespace than the use represented by the
client. </p> </body> </html> body>
</html>
References
References may only be between packages, classifiers or properties and the
metatype of the client must be the same as the metatype of the supplier.
References must be between like metaclasses
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 3-2]</b> NIEM subsets may omit elements with zero
cardinality and adjust the cardinality of elements in reference schemas from which
they are derived, as long as the subset property is maintained. </body>
</html> intained. </body> </html> l>
MDR [Rule 3-02]
OCL2.0
( self.base_Realization.client->size()=1) and (
self.base_Realization.supplier->size()=1) and
self.base_Realization.client->forAll(client|client.oclIsKindOf(Classifier)) and
self.base_Realization.supplier->forAll(supplier|supplier.oclIsKindOf(Classifier)
and not(supplier.stereotypedBy('PropertyHolder')) ) ) implies ( (
self.base_Realization.client.oclAsType(Classifier).attribute
->forAll(clientAttribute|
self.base_Realization.supplier.oclAsType(Classifier).attribute
->forAll(supplierAttribute| (clientAttribute.name=supplierAttribute.name)
implies ( (clientAttribute.lower>=supplierAttribute.lower) and (
(supplierAttribute.upper=-1) or
(clientAttribute.upper<=supplierAttribute.upper) ) and (
(clientAttribute.upper=-1) or (clientAttribute.lower<=clientAttribute.upper) )
) ) ) ) and( self.base_Realization.supplier.oclAsType(Classifier).attribute
->select(a|a.lower>0) ->forAll(supplierAttribute|
self.base_Realization.client.oclAsType(Classifier).attribute->exists(clientAttribute|clientAttribute.name=supplierName)
) ) )
private
base_Realization
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> The ValueRestriction stereotype applies to a DataType (Enumeration or
Primitive type) that is a specialization of a general DataType. It defines restrictions
on which values of the general DataType that are allowed as values of the specialized
DataType. A ValueRestriction DataType is implemented in XML Schema as a simple type
definition that is a restriction of the simple type that implements the general
DataType. The attributes of the ValueRestriction are implemented as restriction facets.
</p> <p> ValueRestriction represents a NIEM type which is
implemented in XML Schema as a simple type definition. Section 3.14 of <a
href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/">XML Schema
Structures</a> addresses simple type definitions in XML Schema; Sections
6.1.6.1, 7.2.1, 7.3, and 9.12.2 of <a
href="http://reference.niem.gov/niem/specification/naming-and-design-rules/1.3/">NIEM
NDR v1.3</a> address simple type definitions in NIEM-conformant XML
Schema. The variety of the simple type definition may be union, list, or atomic. As the
ValueRestriction stereotype is a specialization of DataType, it may be applied to
Enumeration. In this case, the ValueRestriction represents a NIEM code type, which is
implemented in XML Schema as a simple type definition that contains multiple
xsd:enumeration facets. </p> </body> </html>
code type, which is implemented in XML Schema as a simple type definition that contains
multiple xsd:enumeration facets. </p> </body>
</html> > </body> </html>
ValueRestriction
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-14] (REF, EXT)</b> A
component definition SHALL begin with a standard opening phrase that depends on the
class of the component per Table 7-1 in NDR: Standard Opening Phrases:
</p> <p> <b>Rationale</b> A
standard opening phrase based on component class helps to ensure consistent
definitions that appropriate for the type of component item being defined. These
opening phrases also provide a cue that facilitates recognition of the particular kind
of component. </p> </body> </html> s
recognition of the particular kind of component. </p>
</body> </html> </html>
NDR [Rule 7-14]
OCL2.0
self.base_Class.profiledBy('NIEM_PSM_Profile') implies
self.base_Class.ownedComment ->exists(documentation|
documentation.stereotypedBy('Documentation') and ( documentation.body.startsWith('A
data type for a ') or documentation.body.startsWith('A data type for an ') ) )
A valuerestriction that is not an enumeration or list may only generalize the same
metatype. A valuerestriction that is an enumeration may not generalize a list. A
valuerestriction that is a list may not generalize an enumeration..
ValueRestriction Generalization
A ValueRestriction DataType must be the special classifier in a single
Generalization whose general classifier is also a DataType.
ValueRestrictionGeneralization
OCL2.0
self.base_DataType.generalization.general->size()=1
A restriction on the value space of a numeric data type that places an upper limit
on the arithmetic precision of decimal values. The value space is restricted to those
values that can be represented lexically in decimal notation using at most
fractionDigits to the right of the decimal point. fractionDigits is implemented in XML
Schema as the value of the value attribute on the xsd:fractionDigits element, the
child of the xsd:restriction element which is the immediate child of the
xsd:simpleType element..
public
fractionDigits
A restriction on the value space of a data type to values with a specific length,
where the units of length depends on the base type being restricted. For String and
URI values, the units are characters. For Binary values, the units are octets. For
lists, the length is the number of items in the list. length is implemented in XML
Schema as the value of the value attribute on the xsd:length element, the child of the
xsd:restriction element which is the immediate child of the xsd:simpleType element..
public
length
The exclusive upper bound of the value space for a data type with ordered values.
The value of maxExclusive must be equal to some value in the value space of the base
data type or to the maxExclusive restriction of the base type (if it has one).
maxExclusive is implemented in XML Schema as the value of the value attribute on the
xsd:maxExclusive element, the child of the xsd:restriction element which is the
immediate child of the xsd:simpleType element..
public
maxExclusive
The inclusive upper bound of the value space for a data type with ordered values.
The value of maxInclusive must be equal to some value in the value space of the base
data type. maxInclusive is implemented in XML Schema as the value of the value
attribute on the xsd:maxInclusive element, the child of the xsd:restriction element
which is the immediate child of the xsd:simpleType element..
public
maxInclusive
A restriction on the value space of a data type to values with a specific maximum
length, where the units of length depends on the base type being restricted. For
String and URI values, the units are characters. For Binary values, the units are
octets. For lists, the length is the number of items in the list. maxLength is
implemented in XML Schema as the value of the value attribute on the xsd:maxLength
element, the child of the xsd:restriction element which is the immediate child of the
xsd:simpleType element.
public
maxLength
The exclusive lower bound of the value space for a data type with ordered values.
The value of minExclusive must be equal to some value in the value space of the base
data type or to the minExclusive restriction of the base type (if it has one).
minExclusive is implemented in XML Schema as the value of the value attribute on the
xsd:minExclusive element, the child of the xsd:restriction element which is the
immediate child of the xsd:simpleType element..
public
minExclusive
The inclusive lower bound of the value space for a data type with ordered values.
The value of minInclusive must be equal to some value in the value space of the base
data type. minInclusive is implemented in XML Schema as the value of the value
attribute on the xsd:minInclusive element, the child of the xsd:restriction element
which is the immediate child of the xsd:simpleType element..
public
minInclusive
A restriction on the value space of a data type to values with a specific minimum
length, where the units of length depends on the base type being restricted. For
String and URI values, the units are characters. For Binary values, the units are
octets. For lists, the length is the number of items in the list. minLength is
implemented in XML Schema as the value of the value attribute on the xsd:minLength
element, the child of the xsd:restriction element which is the immediate child of the
xsd:simpleType element.
public
minLength
A constraint on the value space of a data type achieved by constraining the value
space to those values represented by literals that match each member of a set of
regular expressions. Each pattern must be a valid regular expression. pattern is
implemented in XML Schema as the value of the value attribute on the xsd:pattern
element, the child of the xsd:restriction element which is the immediate child of the
xsd:simpleType element.
public
pattern
*
Restricts the magnitude and arithmetic precision of values in the value space of a
numeric data type. The value space is restricted to those values that can be
represented lexically using at most totalDigits digits in decimal notation or at most
totalDigits digits for the coefficient, in scientific notation. totalDigits is
implemented in XML Schema as the value of the value attribute on the xsd:totalDigits
element, the child of the xsd:restriction element which is the immediate child of the
xsd:simpleType element.
public
totalDigits
private
base_DataType
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> The AugmentationApplication stereotype is a specialization of
Application that is always between a Property whose type is an AugmentationType Class
and a Class. It represents a constraint on a NEIM augmentation property that limits the
application of the property to specific types. When an augmentation property is the
client of an AugmentationApplication Usage, this serves to constrain the NIEM types to
which the augmentation property may apply. If the client augmentation Property is not in
a PropertyHolder, then its Class must be a (direct or indirect) subclass of the supplier
Class of the AugmentationApplication. If the augmentation Property is in a
PropertyHolder, then any Property defined by reference to the augmentation Property must
be for a Class that is a subclass of the supplier Class. </p>
<p> An AugmentationApplication Usage is implemented in a NIEM XML schema
as an AppliesTo element in the annotation element of the property declaration
represented by the client of the Usage, referencing the complex type represented by the
supplier class of the Usage. </p> </body>
</html> d by the client of the Usage, referencing the complex type
represented by the supplier class of the Usage. </p> </body>
</html> body> </html>
AugmentationApplication
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-50] (REF, EXT) </b>Within the
schema, an element definition for an augmentation element that does not contain any
instances of the element structures:AppliesTo MAY be applied to any object or
association type. </p> <p>
<b>Rationale</b> These rules allow schema builders to
establish applicability for augmentations. An augmentation may be applicable to
specific types. Users who wish to apply an augmentation type to a given object type
may do so by creating a new augmentation element, applicable to the object type.
</p> </body> </html> new augmentation
element, applicable to the object type. </p> </body>
</html> /body> </html>
NDR [Rule 7-50]
English
Implemented as part of PIM/PSM transformations. This constraint is definitional,
the absence of an <<AugmentationApplication>> on an
augmentation element will result in applicability of the element to any
Object/Association at runtime.
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> A Choice Class groups a set of attributes whose values are mutually
exclusive. That is, in any instance of a Choice Class, at most one of its attributes may
be non-empty. </p> <p> Choice represents the use of a choice
model group in XML Schema. Section 3.8 of <a
href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/">XML Schema
Structures</a> addresses choice model groups in XML Schema. Sections
6.1.8.1 and 6.1.8.2 of <a
href="http://reference.niem.gov/niem/specification/naming-and-design-rules/1.3/">NIEM
NDR v1.3 </a>address choice model groups in NIEM-conformant XML Schema.
</p> </body> </html> ddress choice model
groups in NIEM-conformant XML Schema. </p> </body>
</html> </html>
Choice
The ownedAttributes of a Choice class shall have multiplicity 0..1.
ownedAttributes have multiplicity 0..1.
OCL2.0
self.base_Class.ownedAttributes->forAll(a|(a.lower=0) and
(a.upper=1))
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-18] (REF) </b>The schema
SHALL NOT contain the element xsd:choice. </p> <p>
<b>Rationale</b> The element xsd:choice provides an
exclusive set of particles, one of which may appear in an instance. This can greatly
complicate processing and may be difficult to comprehend, satisfy, and reuse. The
element xsd:choice may be used in extension and exchange schemas, as it presents a
simple way for a schema writer to represent a set of optional content. It may also be
used in subset schemas and constraint schemas to represent syntactic alternatives.
</p> </body> </html> d constraint schemas to
represent syntactic alternatives. </p> </body>
</html> body> </html>
NDR [Rule 6-18]
OCL2.0
self.base_Class.profiledBy('NIEM_PSM_Profile') implies
self.base_Class.owner.getTargetDirectedRelationships()
->select(r|r.stereotypedBy('ModelPackageDescriptionFile'))
->forAll(mpdf|mpdf.getStereotypeApplication('ModelPackageDescriptionFile').natureURI<>'http://reference.niem.gov/niem/resource/mpd/lexicon/1.0/purpose#reference-schema')
A Choice Class shall not participate in any Generalizations, either as the general
or the special Classifier.
No Generalizations or subtypes
OCL2.0
self.base_Class.generalization->isEmpty() and
self.base_Class.getTargetDirectedRelationships()->select(d|d.oclIsKindOf(Generalization))->isEmpty()
private
base_Class
extension_UnionType
private
composite
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> A Union is a DataType whose value space is the union of one or more
other DataTypes, which are the member types of the Union. The member types are specified
using UnionOf Usage dependencies. </p> <p> A Union DataType
is implemented in XML Schema as a union simple type definition. Each UnionOf dependency
of which the Union is the client represents a relationship between two type definitions:
the first is a union simple type definition whose member type definition is the second.
This relationship is implemented in XML Schema through the memberTypes attribute on the
xsd:union element of the union simple type definition, the actual value of which
resolves to the second type definition. Section 3.14 of <a
href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/">XML Schema
Structures</a> addresses union simple type definitions in XML Schema.
</p> </body> </html> implemented in XML Schema
through the memberTypes attribute on the xsd:union element of the union simple type
definition, the actual value of which resolves to the second type definition. Section
3.14 of <a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/">XML
Schema Structures</a> addresses union simple type definitions in XML
Schema. </p> </body> </html>
Union
A Union shall not have any ownedAttributes.
no owned attributes
OCL2.0
self.base_DataType.ownedAttribute->isEmpty()
A Union shall not have any generalizations.
no generalizations
OCL2.0
self.base_DataType.generalization->isEmpty()
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-14] (REF, EXT)</b> A
component definition SHALL begin with a standard opening phrase that depends on the
class of the component per Table 7-1 in NDR: Standard Opening Phrases:
</p> <p> <b>Rationale</b> A
standard opening phrase based on component class helps to ensure consistent
definitions that appropriate for the type of component item being defined. These
opening phrases also provide a cue that facilitates recognition of the particular kind
of component. </p> </body> </html> s
recognition of the particular kind of component. </p>
</body> </html> </html>
NDR [Rule 7-14]
OCL2.0
self.base_Class.profiledBy('NIEM_PSM_Profile') implies
self.base_Class.ownedComment ->exists(documentation|
documentation.stereotypedBy('Documentation') and ( documentation.body.startsWith('A
data type for a ') or documentation.body.startsWith('A data type for an ') ) )
private
base_DataType
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> A Namespace Package represents a NIEM namespace identified by a target
namespace URI. All UML model elements contained, directly or indirectly within the
Package, that represents NIEM types and properties, are considered to be in this target
namespace. </p> <p> A Namespace Package is implemented in
XML Schema as an XML schema document. </p> </body>
</html> ML Schema as an XML schema document. </p>
</body> </html> body> </html>
Namespace
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 6-37] (REF, SUB, EXT, CON) </b>Within the schema,
the document element xsd:schema MUST carry the attribute version.
</body> </html> ion. </body>
</html> l>
NDR [Rule 6-37]
OCL2.0
not(self.version.oclIsUndefined()) -- Constraint also resolved by the requirement
that tag "version" is required.
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-38] (REF, SUB, EXT, CON)
</b>Within the schema, the value of the required attribute version on
the document element xsd:schema MUST NOT be an empty string. </p>
<p> <b>Rationale</b> It is very useful to be
able to tell one version of a schema from another. Apart from the use of namespaces
for versioning, it is sometimes necessary to release multiple versions of schema
documents. Such use might include: </p> <p> � Subset
schemas and constraint schemas </p> <p> � Error
corrections or bug fixes </p> <p> � Documentation changes
</p> <p> � Contact information updates </p>
<p> In such cases, a different value for the version attribute implies a
different version of the schema. No specific meaning is assigned to specific version
identifiers. </p> <p> Note that some of the above uses for
the version attribute are not employed in management of NIEM Core and domain schemas.
An author of an application schema or exchange may use the version attribute for these
purposes within their schemas. </p> </body>
</html> management of NIEM Core and domain schemas. An author of an
application schema or exchange may use the version attribute for these purposes within
their schemas. </p> </body> </html> >
</body> </html>
NDR [Rule 6-38]
OCL2.0
self.version<>''
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-37] (REF, SUB, EXT)</b>
Within the schema, a complex type definition SHALL be one of the following classes of
types: </p> <p> 1. An object type. </p>
<p> 2. A role type. </p> <p> 3. An
association type. </p> <p> 4. A metadata type.
</p> <p> 5. An augmentation type. </p>
<p> 6. An adapter type. </p> <p>
<b>Rationale</b> This rule establishes the classes of NIEM
complex types. It is a limited set, each class with distinct semantics.
</p> </body> </html> his rule establishes
the classes of NIEM complex types. It is a limited set, each class with distinct
semantics. </p> </body> </html> body>
</html>
NDR [Rule 7-37]
OCL2.0
self.base_Package.profiledBy('NIEM_PSM_Profile') implies
self.base_Package.ownedType ->select(t|t.oclIsKindOf(Class) and
not(t.stereotypedBy('PropertyHolder')))
->forAll(type|type.stereotypedBy('NIEMType')) -- PIM Profile Classes default to
<<ObjectType>> if not otherwise specified
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 9-6] (REF, SUB, EXT) </b>Within the schema, any
XML Schema component other than an attribute declaration SHALL have a name that begins
with an upper-case letter ('A'-'Z'). </body> </html>
'A'-'Z'). </body> </html> l>
NDR [Rule 9-6]
OCL2.0
self.base_Package.profiledBy('NIEM_PSM_Profile') implies
self.base_Package.ownedType ->select(t|not(t.stereotypedBy('PropertyHolder'))
->forAll(schemaComponent|schemaComponent.name.firstToUpper()=schemaComponent.name)
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-35] (REF, SUB, EXT, CON)
</b>Within the schema, the document element xsd:schema MUST carry the
attribute targetNamespace. </p> </body>
</html> espace. </p> </body>
</html> </html>
NDR [Rule 6-35]
OCL2.0
not(self.targetNamespace.oclIsUndefined()) and
(self.targetNamespace<>'') -- also partially satisfied by multiplicity
constraint on targetNamespace
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 9-24] (REF, SUB, EXT)</b>
Within the schema, the name of any simple type definition SHALL use the representation
term qualifier Simple. This qualifier SHALL appear after any other representation term
qualifiers. </p> <p>
<b>Rationale</b> Specific uses of type definitions have
similar syntax but very different effects on data definitions. Schemas that clearly
identify complex and simple type definitions are easier to understand without tool
support. This rule ensures that names of simple types end in SimpleType.
</p> </body> </html> ule ensures that names
of simple types end in SimpleType. </p> </body>
</html> body> </html>
NDR [Rule 9-24]
OCL2.0
self.profiledBy('NIEM_PSM_Profile') implies self.base_Package.ownedType
->select(t|t.oclIsKindOf(DataType))
->forAll(simpleType|simpleType.name.matches('.*SimpleType'))
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-14] (REF, EXT)</b> A
component definition SHALL begin with a standard opening phrase that depends on the
class of the component per Table 7-1 in NDR: Standard Opening Phrases:
</p> <p> <b>Rationale</b> A
standard opening phrase based on component class helps to ensure consistent
definitions that appropriate for the type of component item being defined. These
opening phrases also provide a cue that facilitates recognition of the particular kind
of component. </p> </body> </html> s
recognition of the particular kind of component. </p>
</body> </html> </html>
NDR [Rule 7-14]
OCL2.0
self.base_Class.profiledBy('NIEM_PSM_Profile') implies
self.base_Package.ownedType->select(t|t.oclIsKindOf(Enumeration))
->forAll(otherType|otherType.ownedComment ->exists(documentation|
documentation.stereotypedBy('Documentation') and ( documentation.body.startsWith('A
data type for a ') or documentation.body.startsWith('A data type for an ') ) ) )
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 9-25] (REF, SUB, EXT)</b>
Within the schema, the name of any code type SHALL use the representation term
qualifier Code. </p> <p>
<b>Rationale</b> Using the qualifier Code (e.g. CodeType,
CodeSimpleType) immediately identifies a type as representing a fixed list of codes.
These types may be handled in specific ways, as lists of codes are expected to have
their own lifecycles, including versions and periodic updates. Codes may also have
responsible authorities behind them who provide concrete semantic bindings for the
code values. </p> </body> </html> o provide
concrete semantic bindings for the code values. </p>
</body> </html> </html>
NDR [Rule 9-25]
OCL2.0
self.base_Package.profiledBy('NIEM_PSM_Profile') implies
self.base_Package.ownedType ->select(t|t.oclIsKindOf(Enumeration))
->forAll(enumerationDerivedType|enumerationDerivedType.name.matches('.*Code.*'))
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-36] (REF, SUB, EXT, CON)
</b>Within the schema, the value of the required attribute
targetNamespace on the document element xsd:schema MUST match the production
<absolute-URI> as defined by
<b>[RFC3986]</b>. </p> <p>
<b>Rationale</b> Schemas without defined namespaces
provide definitions that are ambiguous, in that they are not universally identifiable.
Absolute URIs are the only universally meaningful URIs. URIs include both URLs and
URNs. Finding the target namespace using standard XML Base technology is complicated
and not specified by XML Schema. Relative URIs are not universally identifiable, as
they are context-specific. </p> </body>
</html> are not universally identifiable, as they are context-specific.
</p> </body> </html> </html>
NDR [Rule 6-36]
OCL2.0
self.targetNamespace.isAbsoluteURI()
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 9-26] (REF, SUB, EXT)</b>
Within the schema, any type definition which has a base type definition of a code type
or which is transitively based on a code type SHALL have a name that uses the
representation term qualifier Code. </p> <p>
<b>Rationale</b> This expands the use of the
representation term qualifier Code to any type based on a code list.
</p> </body> </html> fier Code to any type
based on a code list. </p> </body> </html>
</html>
NDR [Rule 9-26]
OCL2.0
self.base_Package.profiledBy('NIEM_PSM_Profile') implies
self.base_Package.ownedType ->select(t|
t.clientDependency->select(d|d.stereotypedBy('XSDSimpleContent')).supplier->exists(s|s.oclIsKindOf(Enumeration))
or ( t.oclIsKindOf(Classifier) and
t.oclAsType(Classifier).allParents().clientDependency->select(d|d.stereotypedBy('XSDSimpleContent')).supplier->exists(s|s.oclIsKindOf(Enumeration))
) )
->forAll(enumerationDerivedType|enumerationDerivedType.name.matches('.*Code.*'))
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 7-7] (REF, EXT)</b> Within the schema, any
element xsd:attribute that is an immediate child of an element xsd:schema MUST be a
documented component. </body> </html> omponent.
</body> </html> l>
NDR [Rule 7-07]
OCL2.0
self.base_Package.profiledBy('NIEM_PSM_Profile') implies
self.base_Package.ownedComment->exists(documentation|documentation.stereotypedBy('Documentation'))
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 9-3] (REF, SUB, EXT) </b>The
name of any XML Schema component defined by the schema SHALL contain only the
following characters: </p> <p> � Upper-case letters
('A'-'Z'). </p> <p> � Lower-case letters ('a'-'z').
</p> <p> � Digits ('0'-'9'). </p>
<p> � Hyphen ('-'). </p> <p> Other
characters, such as the underscore ('_') character and the period ('.') character
SHALL NOT appear in component names in NIEM-conformant schemas. </p>
</body> </html> od ('.') character SHALL NOT appear in
component names in NIEM-conformant schemas. </p> </body>
</html> > </body> </html> ml>
NDR [Rule 9-3]
OCL2.0
self.base_Package.profiledBy('NIEM_PSM_Profile') implies
self.base_Package.ownedType ->select(t|not(t.stereotypedBy('PropertyHolder'))
->forAll(schemaComponent|schemaComponent.name.match('[\\w|\\-]*'))
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 7-9] (REF, EXT) </b>Within the schema, the
document element xsd:schema MUST be a documented component. </body>
</html> ent. </body> </html> l>
NDR [Rule 7-09]
OCL2.0
self.base_Package.profiledBy('NIEM_PSM_Profile') implies
self.base_Package.ownedComment->exists(documentation|documentation.stereotypedBy('Documentation'))
public
base_Package
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> The target namespace URI for this NIEM namespace. </p>
<p> It is implemented in XML Schema as the value of the targetNamespace
attribute on the xsd:schema document element. Per Rules 6-35 and 6-36 of <a
href="http://reference.niem.gov/niem/specification/naming-and-design-rules/1.3/">NIEM
NDR v1.3</a>, the value of the targetNamespace attribute must be present
and must be an absolute URI. </p> </body>
</html> and must be an absolute URI. </p>
</body> </html> /body> </html>
public
targetNamespace
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> Indicates whether the namespace is NIEM-conformant.
</p> <p> If the namespace is NIEM-conformant, it is
implemented in XML Schema as the content of the i:ConformantIndicator application
information on the xsd:schema document element. Per Rule 7-1 of NIEM NDR v1.3, the
content must be "true". If the namespace is not NIEM-conformant, it is implemented in
XML Schema as the content of the i:ConformantIndicator application information on the
xsd:import element. Per Rule 7-61 of <a
href="http://reference.niem.gov/niem/specification/naming-and-design-rules/1.3/">NIEM
NDR v1.3</a>, the content must be "false". </p>
</body> </html> NDR v1.3</a>, the content
must be "false". </p> </body> </html>
dy> </html>
public
isConformant
true
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> The version of the NIEM namespace. </p>
<p> It is implemented in XML Schema as the value of the version
attribute on the xsd:schema document element. Per Rules 6-37 and 6-38 of <a
href="http://reference.niem.gov/niem/specification/naming-and-design-rules/1.3/">NIEM
NDR v1.3</a>, the value of the version attribute must be present and
must not be the empty string. Default is "1". </p> </body>
</html> ty string. Default is "1". </p>
</body> </html> </html>
public
version
"1"
private
extension_UnionOf
composite
public
extension_NIEMDocumentation
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> A NIEMType is a Class that represents one of the specific semantic
kinds of NIEM complex types (i.e., types that may have attributive structure). NIEMType
is abstract. </p> <p> A NIEMType Class is implemented in XML
Schema as a complex type definition with complex content. </p>
</body> </html> definition with complex content.
</p> </body> </html> y>
</html>
NIEMType
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 9-33] (REF, SUB, EXT)</b>
Within the schema, the name of an augmentation element SHALL use the representation
term Augmentation. </p> <p>
<b>Rationale</b> Using the qualifier Augmentation
immediately identifies an element as representing an augmentation. </p>
</body> </html> representing an augmentation.
</p> </body> </html> </html>
NDR [Rule 9-33]
OCL2.0
self.base_Class.profiledBy('NIEM_PSM_Profile') implies
self.base_Class.ownedAttribute
->forAll(a|a.type.stereotypedBy('AugmentationType') implies
a.name.match('.*Augmentation.*')) --For PIM Profile, the naming constraint is enforced
by PIM/PSM transformations. --An augmentation element corresponds to a UML
<Property> whose type is an
<<AugmentationType>>.
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 9-32] (REF, SUB, EXT)
</b>Within the schema, the name of an association element SHALL use the
representation term qualifier Association. </p> <p>
<b>Rationale</b> Using the qualifier Association
immediately identifies an element as representing an association. </p>
</body> </html> ment as representing an association.
</p> </body> </html> </html>
NDR [Rule 9-32]
OCL2.0
self.base_Class.profiledBy('NIEM_PSM_Profile') implies
self.base_Class.ownedAttribute
->forAll(a|a.type.stereotypedBy('AssociationType') implies
a.name.match('.*Association.*')) --For PIM Profile, the naming constraint is enforced
by PIM/PSM transformations. --An association element corresponds to a UML
<Property> whose type is an
<<AssociationType>>.
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-49] (REF, EXT)</b> Within the
schema, an element definition for an augmentation element MAY contain one or more
instances of the element structures:AppliesTo as application information to specify
types to which the augmentation element applies. </p> <p>
</p> <p> In UML, this represents a constraint on
augmentations, i.e., those UML <Property>s whose type is an
<<<a
href="mdel://_17_0_2_7b3022e_1312665991957_183350_2567y">Augmentation</a>>>.
</p> <p> A <Property> which is a client
of any <<AppliesTo>> must be owned by a
<Classifier> which is conformant with one of the
<<AppliesTo>> supplier <Classifier>s.
</p> </body> </html> ch is conformant with
one of the <<AppliesTo>> supplier
<Classifier>s. </p> </body>
</html> body> </html>
NDR [Rule 7-49]
OCL2.0
self.base_Class.ownedAttribute ->forAll(a|
a.type.stereotypedBy('AugmentationType') implies a.clientDependency
->union(a.clientDependency->select(d|d.stereotypedBy('References')).target.clientDependency)
->select(d|d.stereotypedBy('AugmentationApplication')).target.oclAsType(Class)
->exists(appliedTo|self.base_Class.isConsistentWith(appliedTo)) )
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-45] (REF, EXT)</b> Within the
schema, a metadata type MAY have application information appinfo:AppliesTo, indicating
the NIEM-conformant object, association, or external adapter types to which the
metadata applies. </p> <p> </p>
<p> In UML, this represents a constraint on metadata elements, i.e.,
those UML <Property>s whose type is a <<<a
href="mdel://_17_0_2_7b3022e_1312665991957_183350_2567z">MetadataType</a>>>.
</p> <p> If the <<<a
href="mdel://_17_0_2_7b3022e_1312665991957_183350_2567z">MetadataType</a>>>
has an <<AppliesTo>>, then the <Property>
must be owned by a <Classifier> which is conformant with one of the
<Classifier>s referenced by one of the
<<AppliesTo>>. </p> </body>
</html> formant with one of the <Classifier>s referenced
by one of the <<AppliesTo>>. </p>
</body> </html> body> </html>
NDR [Rule 7-45]
OCL2.0
self.base_Class.ownedAttribute ->forAll(a|
a.type.stereotypedBy('MetadataType') implies a.type.clientDependency
->select(d|d.stereotypedBy('MetadataApplication')).target.oclAsType(Class)
->exists(appliedTo|self.base_Class.isConsistentWith(appliedTo)) )
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 9-23] (REF, SUB, EXT)
</b>Within the schema, the name of any type definition MUST use the
representation term Type. </p> <p>
<b>Rationale</b> Using the representation term Type
immediately identifies XML types in a NIEM-conformant schema and prevents naming
collisions with corresponding XML elements and attributes. </p>
</body> </html> ponding XML elements and attributes.
</p> </body> </html> </html>
NDR [Rule 9-23]
OCL2.0
self.base_Class.profiledBy('NIEM_PSM_Profile') implies
self.base_Class.name.endsWith('Type')
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 9-34] (REF, SUB, EXT)</b>
Within the schema, the name of a metadata element SHALL use the representation term
Metadata. </p> <p>
<b>Rationale</b> Using the qualifier Metadata immediately
identifies an element as representing metadata. </p>
</body> </html> ent as representing metadata.
</p> </body> </html> </html>
NDR [Rule 9-34]
OCL2.0
self.base_Class.profiledBy('NIEM_PSM_Profile') implies
self.base_Class.ownedAttribute ->forAll(a|a.type.stereotypedBy('MetadataType')
implies a.name.match('.*Metadata.*')) --For PIM Profile, the naming constraint is
enforced by PIM/PSM transformations. --A metadata element corresponds to a UML
<Property> whose type is a
<<Metadata>>.
private
base_Class
true
private
extension_Choice
composite
The UnionOf stereotype is applied to a Usage dependency, the client of which must be
a Union DataType and the supplier of which must be a DataType that represents a legal
union member type. A UnionOf dependency specifies that the supplier DataType is a member
type of the client Union.
UnionOf
supplier must be data type
OCL2.0
self.base_Usage.supplier.oclKindOf(DataType)
client must be union
OCL2.0
self.base_Usage.client.stereotypedBy('Union')
private
base_Usage
private
extension_
composite
extension_Restriction
private
composite
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> AugmentationType is a NIEMType Class that represents a
NIEM augmentation type. A NIEM augmentation type is a complex type that provides a
reusable block of data that may be added to object types or association types. An
augmentation of an object type is a block of additional data that is an
instance of an augmentation type, added to an object type to carry additional data
beyond that of the original object definition. The applicability of an augmentation may
be restricted using an AugmentationApplication Dependency or an Augments Generalization.
A Class that is the specific Classifier of an Augments Generalization shall be inferred
to be an AugmentationType. </p> <p> AugmentationType is
implemented in XML Schema as a complex type definition with complex content. Section 3.4
of <a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/">XML
Schema Structures</a> addresses complex type definitions in XML Schema;
Section 7.4.5 of <a
href="http://reference.niem.gov/niem/specification/naming-and-design-rules/1.3/">NIEM
NDR v1.3</a> addresses augmentation types in NIEM-conformant XML Schema.
</p> </body> </html>
nd-design-rules/1.3/">NIEM NDR v1.3</a> addresses augmentation
types in NIEM-conformant XML Schema. </p> </body>
</html> body> </html>
AugmentationType
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-48] (REF, SUB, EXT)
</b>Within the schema, an augmentation element definition:
</p> <p> 1. SHALL have a type that is an augmentation
type. </p> <p> 2. SHALL use the substitutionGroup
attribute such that it is transitively substitutable for the element
structures:Augmentation. </p> <p> An element that is not
an augmentation element SHALL NOT meet either of the above criteria.
</p> <p> <b>Rationale</b> An
augmentation is trivially identifiable as such. The use of the common
structures:Augmentation element allows message builders to optionally delay specifying
augmentations to be applied to a type until runtime. </p>
</body> </html> builders to optionally delay specifying
augmentations to be applied to a type until runtime. </p>
</body> </html> </body>
</html>
NDR [Rule 7-48]
English
The constraint is enforced by the transformation from PSM to XSD Schema artifact.
A property whose type is an <<AugmentationType>> is an
augmentation element. The property may directly or indirectly use the UML
subsettedProperty mechanism to identify a substitutionGroup, which will be
transitively substitutable for the element structures:Augmentation.
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>NDR [Rule 7-47] (REF, EXT)</b>
Essentially states that the general of the
<<Augmentation>>, if it exists, must be an
<<Augmentation>>. </p> <p> Due
to schema and other NDR rules, this also requires </p>
<ul> <li> a maximum of one general for the given
<<Augmentation>> </li> <li>
any subtypes of the given <<Augmentation>> must also be
<<Augmentation>> </li> </ul>
</body> </html> mentation>> must also be
<<Augmentation>> </li> </ul>
</body> </html> ul> </body>
</html>
NDR [Rule 7-47]
OCL2.0
(self.base_Class.general()->size()<=1) and
self.base_Class.general()->forAll(g|g.stereotypedBy('AugmentationType')) and
self.base_Class.getTargetDirectedRelationships()
->forAll(r|r.oclIsKindOf(Gneralization) implies
r.oclAsType(Generalization).specific.stereotypedBy('AugmentationType'))
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-14] (REF, EXT)</b> A
component definition SHALL begin with a standard opening phrase that depends on the
class of the component per Table 7-1 in NDR: Standard Opening Phrases:
</p> <p> <b>Rationale</b> A
standard opening phrase based on component class helps to ensure consistent
definitions that appropriate for the type of component item being defined. These
opening phrases also provide a cue that facilitates recognition of the particular kind
of component. </p> </body> </html> s
recognition of the particular kind of component. </p>
</body> </html> </html>
NDR [Rule 7-14]
OCL2.0
self.base_Class.profiledBy('NIEM_PSM_Profile') implies
self.base_Class.ownedComment ->exists(documentation|
documentation.stereotypedBy('Documentation') and documentation.body.startsWith('A data
type that supplements ') )
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 9-28] (REF, SUB, EXT)</b>
Within the schema, any augmentation type SHALL have a name that uses the
representation term qualifier Augmentation. Types other than augmentation types SHALL
NOT use the representation term qualifier Augmentation. </p>
<p> <b>Rationale</b> Using the qualifier
Augmentation immediately identifies a type as representing an augmentation.
</p> </body> </html> a type as representing
an augmentation. </p> </body> </html>
y> </html>
NDR [Rule 9-28]
OCL2.0
self.base_Class.profiledBy('NIEM_PSM_Profile') implies
self.base_Class.name.match('.*AugmentationType')) --For PIM Profile, the naming
constraint is enforced by PIM/PSM transformations.
private
extension_ValueRestriction
composite
private
extension_ListType
composite
private
extension_
composite
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> AssociationType is a NIEMType class that represents a NIEM association
type. A NIEM association type establishes a relationship between objects, along with the
properties of that relationship. A NIEM association is an instance of an association
type. Associations are used when a simple NIEM property is insufficient to model the
relationship clearly and when properties of a UML Association or AssociationClass may
not necessarily be sufficient to reflect the variability of a NIEM association.
Consequently, the AssociationType Stereotype is applied to a UML Class. Since an
AssociationClass is also a Class, the AssociationType Stereotype may be applied to a UML
AssociationClass where appropriate. </p> <p> Note that a
UML AssociationClass specializing another AssociationClass must have the same number of
ends as the other AssociationClass and must have at least two ends. This UML constraint
prevents the usage of AssociationClass to model abstract NIEM association types that are
intended to be extended by subtypes with additional ends. A UML AssociationClass can
specialize an abstract UML Class. </p> <p> AssociationType
is implemented in XML Schema as a complex type definition with complex content. Section
3.4 of <a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/">XML
Schema Structures</a> addresses complex type definitions in XML Schema;
Section 7.4.3 of <a
href="http://reference.niem.gov/niem/specification/naming-and-design-rules/1.3/">NIEM
NDR v1.3</a> addresses association types in NIEM-conformant XML Schema.
</p> </body> </html>
ref="http://reference.niem.gov/niem/specification/naming-and-design-rules/1.3/">NIEM
NDR v1.3</a> addresses association types in NIEM-conformant XML Schema.
</p> </body> </html> body>
</html>
AssociationType
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-42] (REF, SUB, EXT) </b>
</p> <p> Given that an association type defines a
relationship between a set of participants, within an association type definition, any
element that represents a participant SHALL be a reference element. </p>
<p> <b>Rationale</b> </p>
<p> Associations are intended to relate objects defined elsewhere. They
are not intended to carry content of participant objects. </p>
<p> </p> <p> In UML, any property owned by
the <<AssociationType>> which represents a NIEM reference
must not be an aggregation. </p> </body>
</html> the <<AssociationType>> which
represents a NIEM reference must not be an aggregation. </p>
</body> </html> body> </html>
NDR [Rule 7-42]
OCL2.0
self.base_Class.profiledBy('NIEM_PSM_Profile') implies
self.base_Class.ownedAttribute ->forAll(a|a.name.endsWith('Reference') implies
(a.aggregation=AggregationKind::none))
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-14] (REF, EXT)</b> A
component definition SHALL begin with a standard opening phrase that depends on the
class of the component per Table 7-1 in NDR: Standard Opening Phrases:
</p> <p> <b>Rationale</b> A
standard opening phrase based on component class helps to ensure consistent
definitions that appropriate for the type of component item being defined. These
opening phrases also provide a cue that facilitates recognition of the particular kind
of component. </p> </body> </html> s
recognition of the particular kind of component. </p>
</body> </html> </html>
NDR [Rule 7-14]
OCL2.0
self.base_Class.profiledBy('NIEM_PSM_Profile') implies
self.base_Class.ownedComment ->exists(documentation|
documentation.stereotypedBy('Documentation') and documentation.body.startsWith('A data
type for a relationship ') )
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>NDR [Rule 7-41] (REF, EXT)</b>
Essentially states that the general of the
<<Association>>, if it exists, must be an
<<Association>>. </p> <p> Due
to schema and other NDR rules, this also requires </p>
<ul> <li> a maximum of one general for the given
<<Association>> </li> <li> any
subtypes of the given <<Association>> must also be
<<Association>> </li> </ul>
</body> </html> ssociation>> must also be
<<Association>> </li> </ul>
</body> </html> body> </html>
NDR [Rule 7-41]
OCL2.0
(self.base_Class.generalization->size()<=1) and
self.base_Class.generalization.general->forAll(g|g.stereotypedBy('Association'))
and self.base_Class.getTargetDirectedRelationships()
->select(r|r.oclIsKindOf(Generalization)).oclAsType(Generalization).specific
->forAll(s|s.stereotypedBy('Association'))
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 9-27] (REF, SUB, EXT)</b>
Within the schema, any association type SHALL have a name that uses the representation
term qualifier Association. Types other than association types SHALL NOT use the
representation term qualifier Association. </p> <p>
<b>Rationale</b> Using the qualifier Association
immediately identifies a type as representing an association. </p>
</body> </html> a type as representing an association.
</p> </body> </html> dy>
</html>
NDR [Rule 9-27]
OCL2.0
self.base_Class.profiledBy('NIEM_PSM_Profile') implies
self.base_Class.name.match('.*AssociationType')) --For PIM Profile, the naming
constraint is enforced by PIM/PSM transformations.
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> PropertyHolder is a Class holding global Properties that are not the
subject of any specific NIEM type. A Property of a NIEM type may then be defined by
reference to a Property of a PropertyHolder by using a References realization with the
Property in the PropertyHolder as the supplier. Note that the multiplicity of Properties
in a PropertyHolder is immaterial -- the multiplicities are established by Properties in
the corresponding References client. The target namespace of Properties in a
PropertyHolder is the target namespace of the Namespace Package that contains the
PropertyHolder (which may be different than the target namespace of NIEM types that use
the Properties in the PropertyHolder). </p> <p>
PropertyHolder does not represent any NIEM concept; it exists to permit the user to
define a NIEM property that is not the subject of any NIEM type. There are significant
differences between the UML representation and XML Schema implementation of a NIEM
property. Sections 6.1.6.2 and 6.1.6.3 of <a
href="http://reference.niem.gov/niem/specification/naming-and-design-rules/1.3/">NIEM
NDR v1.3</a>, Rule 6-14 and Rule 6-15, require that an attribute or
element declaration be a top-level declaration, but NIEM NDR v1.3 does not require a
corresponding attribute use or element particle; however, Section 7.3.44 of [UML]
requires that a Property be the ownedAttribute of a Classifier. Thus in the UML
representation, the declaration and use of a Property are not distinct, and the
declaration of a Property requires its use. In the XML Schema implementation, the
declaration and use are distinct, and the declaration does not require a corresponding
use. To resolve this difference, any Property within a PropertyHolder shall represent an
attribute or element declaration without a corresponding attribute use or element
particle. </p> <p> PropertyHolders may be used to hold the
properties of a substitution group. Where a PropertyHolder is used to define a
substitution group an extension of that substitution group shall be a subclass of the
substitution group PropertyHolder. </p> </body>
</html> ies of a substitution group. Where a PropertyHolder is used to
define a substitution group an extension of that substitution group shall be a subclass
of the substitution group PropertyHolder. </p> </body>
</html> </p> </body> </html>
PropertyHolder
private
base_Class
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> A List is a DataType whose values consist of a finite length (possibly
empty) sequence of values of another DataType, which is the item type of the List. A
List DataType must have a single Property with multiplicity 0..* whose type is the item
type. The name of this element is not material. </p> <p> A
List DataType is implemented in XML schema as a list simple type definition. List
represents a relationship between two simple type definitions: the first is a list
simple type definition whose item type definition is the second. This relationship is
implemented in XML Schema through the itemType attribute on the xsd:list element of the
list simple type definition, the actual value of which resolves to the second type
definition. Section 3.14 of <a
href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/">XML Schema
Structures</a> addresses list simple type definitions in XML Schema;
Section 7.3 of <a
href="http://reference.niem.gov/niem/specification/naming-and-design-rules/1.3/">NIEM
NDR v1.3</a> addresses list simple type definitions in NIEM-conformant XML
Schema. </p> </body> </html>
rules/1.3/">NIEM NDR v1.3</a> addresses list simple type
definitions in NIEM-conformant XML Schema. </p> </body>
</html> > </body> </html>
List
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-14] (REF, EXT)</b> A
component definition SHALL begin with a standard opening phrase that depends on the
class of the component per Table 7-1 in NDR: Standard Opening Phrases:
</p> <p> <b>Rationale</b> A
standard opening phrase based on component class helps to ensure consistent
definitions that appropriate for the type of component item being defined. These
opening phrases also provide a cue that facilitates recognition of the particular kind
of component. </p> </body> </html> s
recognition of the particular kind of component. </p>
</body> </html> </html>
NDR [Rule 7-14]
OCL2.0
self.base_Class.profiledBy('NIEM_PSM_Profile') implies
self.base_Class.ownedComment ->exists(documentation|
documentation.stereotypedBy('Documentation') and ( documentation.body.startsWith('A
data type for a ') or documentation.body.startsWith('A data type for an ') ) )
A List shall not have any generalizations.
no generalizations
OCL2.0
self.base_DataType.generalization->isEmpty()
A List DataType shall have a single ownedAttribute with multiplicity 0..* whose
type is also a DataType.
(self.base_DataType.ownedAttribute->size()=1) and
self.base_DataType.ownedAttribute ->forAll(a|(a.lower=0) and (a.upper=-1))
OCL2.0
single ownedAttribute with multiplicity 0..* typed
<DataType>>
private
base_DataType
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> An Application stereotype is applied to a Usage dependency between a
client Property or Class and a supplier Class. It corresponds to the NIEM concept of
"AppliesTo", which constrains the applicability of the client as being to the NIEM type
represented by the supplier class. The Application Stereotype is abstract, its two
concrete stereotypes being AugmentationApplication and MetadataApplication, representing
the use of "AppliesTo" in the context of augmentation and metadata, respectively.
</p> </body> </html> ion Stereotype is
abstract, its two concrete stereotypes being AugmentationApplication and
MetadataApplication, representing the use of "AppliesTo" in the context of augmentation
and metadata, respectively. </p> </body>
</html>
Application
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-24] (REF, EXT)</b> Within the
schema, the element appinfo:AppliesTo MAY be used in any of the following ways:
</p> <p> 1. To indicate a base type to which an
augmentation may be applied. </p> <p> 2. To indicate a
base type to which a metadata type may be applied. </p>
<p> The element appinfo:AppliesTo SHALL NOT be used for any other
purpose. </p> <p> </p> <p>
<b>Rationale</b> The appinfo:AppliesTo element is required
to express constraints beyond those available within XML Schema. Use of this element
allows advanced processing of instances and schemas for type safety.
</p> <p> </p> <p> In UML
terms, the <Usage> client must be either an augmentation element (i.e.,
a <Property> whose type is an <<<a
href="mdel://_17_0_2_7b3022e_1312665991957_183350_2567y">Augmentation</a>>>)
or a <<<a
href="mdel://_17_0_2_7b3022e_1312665991957_183350_2567z">Metadata</a>>>
<Classifier>. The <Usage> supplier must be a
<Classifier>. </p> </body>
</html>
0_2_7b3022e_1312665991957_183350_2567z">Metadata</a>>>
<Classifier>. The <Usage> supplier must be a
<Classifier>. </p> </body>
</html> body> </html>
NDR [Rule 7-24]
OCL2.0
self.base_Usage.supplier->forAll(s|s.oclIsKindOf(Classifier)) and
self.base_Usage.client ->forAll(client| client.stereotypedBy('MetadataType') or
( client.oclIsKindOf(Property) and
client.oclAsType(Property).type.stereotypedBy('AugmentationType') ) )
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-25] (REF, EXT)</b> Within the
schema, the element appinfo:AppliesTo SHALL indicate a schema component by namespace
and name. </p> <p> </p> <p> In
UML, the <<AppliesTo>> must have a supplier which is a
<Class> or <Datatype> whose nearestPackage is imported via
<<<a
href="mdel://_17_0_3_24a0131_1319232695341_898926_1534">NDRSchema</a>>>.
</p> </body> </html>
31_1319232695341_898926_1534">NDRSchema</a>>>.
</p> </body> </html> </html>
NDR [Rule 7-25]
OCL2.0
self.base_Usage.supplier ->forAll(supplier| (supplier.oclIsKindOf(Class) or
supplier.oclIsKindOf(DataType)) and
supplier.getNearestPackage().stereotypedBy('Namespace') )
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-27] (REF, EXT) </b>Given that
the element appinfo:AppliesTo refers to a type, the applicability described by the
element SHALL be understood to be the indicated type or a type transitively derived
from the indicated type. </p> </body>
</html> the indicated type. </p> </body>
</html> </html>
NDR [Rule 7-27]
English
This constraint is decomposed into two specific cases. NDR [Rule 7-49] defines
constraints related to applying Augmentation and NDR [Rule 7-45] defines constraints
related to applying Metadata.
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-26] (REF, EXT) </b>Within the
schema, an attribute appinfo:namespace owned by an element appinfo:AppliesTo SHALL
indicate the namespace of the type to which appinfo:AppliesTo refers. The indicated
namespace SHALL be defined by a NIEM-conformant schema. </p>
<p> </p> <p> In UML, the
<<AppliesTo>> must have a supplier which is a
<Class> or <Datatype> whose nearestPackage is imported via
<<<a
href="mdel://_17_0_3_24a0131_1319232695341_898926_1534">NDRSchema</a>>>.
</p> </body> </html>
3_24a0131_1319232695341_898926_1534">NDRSchema</a>>>.
</p> </body> </html> </html>
NDR [Rule 7-26]
English
This constraint, at the UML level, is identical to NDR [Rule 7-25].
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-46] (REF, EXT) </b>Within the
schema, a <<<a
href="mdel://_17_0_2_7b3022e_1312665991957_183350_2567z">Metadata</a>>>
type that does not have application information appinfo:AppliesTo MAY be applied to
any object type, association type, or external adapter type. </p>
<p> <b>Rationale</b> Metadata may be
constrained to be applicable to only specific types, or it may be defined to be
applicable to any type. The source of a piece of data and the security classification
of a piece of data are examples of metadata that may be considered globally
applicable. </p> </body> </html> tadata that
may be considered globally applicable. </p> </body>
</html> </html>
NDR [Rule 7-46]
English
Definitional constraint. Application of <<AppliesTo>>
is optional.
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 7-28] (REF, EXT)</b> Within the schema, an
element appinfo:AppliesTo that does not carry an attribute appinfo:namespace SHALL
refer to the target namespace of the schema in which it is used. </body>
</html> is used. </body> </html> ml>
NDR [Rule 7-28]
English
This constraint is resolved by the combination of other constraints and the
PSM-XSD transformations.
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-29] (REF, EXT)</b> Within the
schema, an element appinfo:AppliesTo SHALL carry an attribute appinfo:name. The value
of this attribute SHALL indicate the local name of a schema component within the
namespace specified by the element. </p> <p>
<b>Rationale</b> Together, this set of rules establishes
the element appinfo:AppliesTo as a reference to a NIEM-conformant schema component to
which a NIEM construct may be applied. </p> </body>
</html> t to which a NIEM construct may be applied. </p>
</body> </html> body> </html>
NDR [Rule 7-29]
English
This constraint is resolved by other constraints in combination with the PSM - XSD
transformations.
private
base_Usage
true
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> An AdapterType is a NIEMType Class that represents a NIEM adapter
type. A NIEM adapter type is a NIEM object type that adapts external components for use
within NIEM. External components are not NIEM-conforming (e.g., data components from
other standards, e.g. GML, ISO, etc.). An adapter type creates a new class of object
that embodies a single concept composed of external components. </p>
<p> AdapterType is implemented in XML Schema as a complex type definition
with complex content. Section 3.4 of <a
href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/">XML Schema
Structures</a> addresses complex type definitions in XML Schema; Section
7.7 of <a
href="http://reference.niem.gov/niem/specification/naming-and-design-rules/1.3/">NIEM
NDR v1.3</a> addresses adapter types in NIEM-conformant XML Schema.
</p> </body> </html> NIEM NDR
v1.3</a> addresses adapter types in NIEM-conformant XML Schema.
</p> </body> </html> body>
</html>
AdapterType
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-14] (REF, EXT)</b> A
component definition SHALL begin with a standard opening phrase that depends on the
class of the component per Table 7-1 in NDR: Standard Opening Phrases:
</p> <p> <b>Rationale</b> A
standard opening phrase based on component class helps to ensure consistent
definitions that appropriate for the type of component item being defined. These
opening phrases also provide a cue that facilitates recognition of the particular kind
of component. </p> </body> </html> s
recognition of the particular kind of component. </p>
</body> </html> </html>
NDR [Rule 7-14]
OCL2.0
self.base_Class.profiledBy('NIEM_PSM_Profile') implies
self.base_Class.ownedComment ->exists(documentation|
documentation.stereotypedBy('Documentation') and ( documentation.body.startsWith('A
data type for a ') or documentation.body.startsWith('A data type for an ') ) )
private
extension_Subsets
composite
http://www.omg.org/spec/NIEM-UML/20120501/NIEM_Common_Profile
The Model Package Description Profile comprises stereotypes that are used to mode NIEM
MPDs. The diagram shows all the stereotypes defined in this profile.
extension_
private
composite
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body> A set of
metadata used to contact the authoritative source for an MPD. </body>
</html> </body> </html> l>
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body> A
telephone number. </body> </html> </body>
</html> l>
*
POCTelephone
public
composite
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body> A name
for a person, position, or title. </body> </html>
</body> </html> l>
POCName
public
composite
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body> An
email address. </body> </html> </body>
</html> l>
*
POCEmail
public
composite
POCType
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> The ModelPackageDescriptionFile stereotype applies to a Usage
dependency that represents a relationship between an MPD or a file set and an artifact
(generally a namespace) to be included in the MPD. Reference Sections 4.2.3 and 4.2.4 of
NIEM MPD Specification v1.0
(http://reference.niem.gov/niem/specification/model-package-description/1.0/).
</p> </body> </html>
l-package-description/1.0/). </p> </body>
</html> </html>
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-15] (REF, SUB, EXT)</b>
Within the schema, any attribute declaration owning the attribute name MUST appear as
an immediate child of the document element xsd:schema. </p>
<p> <b>Rationale</b> All schema components
defined by NIEM-conformant schemas are named, accessible from outside the defining
schema, and reusable across schemas. Local attribute definitions provide named
attributes that are not reusable outside the context in which they are defined.
Requiring named NIEM attributes to be top level ensures that they are globally
reusable. </p> </body> </html> to be top
level ensures that they are globally reusable. </p>
</body> </html> /body> </html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-15]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 3-1] </b>Any XML instance that
validates against a correct NIEM schema subset will always validate against the entire
NIEM reference schema set from which that subset was created. </p>
<p> </p> <p align="LEFT"
style="margin-bottom:0in;margin-top:0.11in;"> <font face="Times, serif"
color="#000000" size="2">This rule should be satisfied as a result of
redefinition semantics and other constraints</font><font
face="Times" color="#000000" size="2"> associated with
<<</font><a
href="mdel://_17_0_2_7b3022e_1312665991957_183350_2567Q">References</a><font
face="Times" color="#000000"
size="2">>></font><font face="Times, serif"
color="#000000" size="2">. We require that all type definitions in the
</font><font face="Times" color="#000000" size="2">subset
</font><font face="Times, serif" color="#000000"
size="2">schema are </font><font face="Times"
color="#000000" size="2"><<</font><a
href="mdel://_17_0_2_7b3022e_1312665991957_183350_2567Q">References</a><font
face="Times" color="#000000"
size="2">>></font><font face="Times, serif"
color="#000000" size="2"> </font><font face="Times"
color="#000000" size="2">to</font><font face="Times,
serif" color="#000000" size="2"> </font><font face="Times"
color="#000000" size="2">corresponding type definitions in
the</font><font face="Times, serif" color="#000000"
size="2"> reference schema and that all elements in type definitions are
redefinitions. </font> </p> </body>
</html> ize="2"> reference schema and that all elements in type
definitions are redefinitions. </font> </p>
</body> </html> > </body>
</html>
( self.base_ElementImport.profiledBy('NIEM_PSM_Profile') and (
self.purposeURI='http://reference.niem.gov/niem/resource/mpd/lexicon/1.0/purpose#subset-schema')
) implies self.base_ElementImport.importedElement.oclAsType(Package).packagedElement
->forEach(subsetElement|
subsetElement.clientDependency->exists(d|d.stereotypedBy('References')) and
subsetElement.clientDependency->select(d|d.stereotypedBy('References')).supplier
->forEach(referenceElement| (subsetElement.name=referenceElement.name) and
(subsetElement.metaClass()=referenceElement.metaClass()) and(
subsetElement.oclIsKindOf(Namespace) implies
subsetElement.oclAstype(Namespace).ownedMember ->forEach(subsetMember|
referenceElement.oclAstype(Namespace).ownedMember ->exists(referenceMember|
(subsetMember.name=referenceMember.name) and
(subsetMember.metaClass()=referenceMember.metaClass()) ) ) ) ) )
OCL2.0
MPD [Rule 3-01]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-45] (REF, SUB, EXT)
</b>Within the schema, when a namespace other than the XML namespace or
the XML Schema namespace is used, its content MUST be valid with respect to the schema
imported for that namespace. </p> <p>
<b>Rationale</b> XML Schema does not address the
schema-validity of content used for annotations or attributes on schema components.
This rule ensures that content used in such a manner is schema-valid. This encourages
interoperable data definitions and schema documents. </p>
</body> </html> ages interoperable data definitions and
schema documents. </p> </body> </html>
</html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-45]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-7] (REF, SUB, EXT)</b> The
schema SHALL NOT reference the type xsd:anyType. </p> <p>
<b>Rationale</b> XML Schema has the concept of the
"ur-type," a type that is the root of all other types. This type is realized in
schemas as xsd:anyType. </p> <p> NIEM-conformant schemas
must not use xsd:anyType, because this feature permits the introduction of arbitrary
content (i.e., untyped and unconstrained data) into an XML instance. NIEM intends that
the schemas describing that instance describe all constructs within the instance.
</p> </body> </html> describing that
instance describe all constructs within the instance. </p>
</body> </html> > </html>
This constraint is realized by not defining an xsd:anyType as part of the type
system.
English
NDR [Rule 6-07]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-59] (REF, SUB, EXT)
</b>Within the schema, any two elements of the form </p>
<p style="margin-left:10.0px;"> <i>NCName
</i> </p> <p style="margin-left:0.0px;"> and
</p> <p style="margin-left:10.0px;">
<i>NCNameReference</i> </p> <p
style="margin-left:0.0px;"> where the string value of NCName is the same in
both forms, SHALL be defined to have identical semantics. NIEM recognizes no
difference in meaning between a reference element and an element that is not a
reference element. </p> <p style="margin-left:0.0px;">
<b>Rationale</b> NIEM-conformant data instances may use
concrete data elements and reference elements as needed, to represent the meaning of
the fundamental data. There is no difference in meaning between reference and concrete
data representations. The two different methods are available for ease of
representation. No difference in meaning should be implied by the use of one method or
the other. </p> <p style="margin-left:0.0px;"> Assertions
that indicate "included" data is intrinsic, while referenced data is extrinsic, are
not valid and are not applicable to NIEM-conformant data instances and data
definitions. </p> </body> </html> quot; data
is intrinsic, while referenced data is extrinsic, are not valid and are not applicable
to NIEM-conformant data instances and data definitions. </p>
</body> </html> > </body>
</html>
Definitional.
English
NDR [Rule 7-59]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-25] (REF, SUB, EXT)
</b>Within the schema, if the element xsd:sequence carries the attribute
maxOccurs, it MUST set the value of the attribute to 1. </p>
<p> <b>Rationale</b> XML Schema allows each
particle to specify cardinality (how many times the particle may appear in an
instance). NIEM restricts the cardinality of xsd:sequence particles to exactly one, to
ensure that content model definitions are defined in as straightforward a manner as
possible. </p> </body> </html> efined in as
straightforward a manner as possible. </p> </body>
</html> body> </html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-25]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-12] (REF, SUB, EXT) </b>The
schema SHALL NOT contain the element xsd:anyAttribute. </p>
<p> <b>Rationale</b> The xsd:anyAttribute
element provides a wildcard, where arbitrary attributes may appear. The element
xsd:anyAttribute may appear within constraint schemas or within other schemas that are
not NIEM-conformant, but it is prohibited in NIEM-conformant schemas.
</p> </body> </html> t is prohibited in
NIEM-conformant schemas. </p> </body>
</html> </html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-12]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-15] (REF, EXT) </b>The schema
SHALL import the appinfo namespace. </p> <p>
<b>Rationale</b> For uniformity, all NIEM-conformant
schemas must import the appinfo namespace. </p> </body>
</html> the appinfo namespace. </p> </body>
</html> body> </html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 7-15]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 7-69] (SUB)</b> The value of the targetNamespace
attribute owned by the xsd:schema document element of the subset schema must be the
same as the value of the targetNamespace attribute owned by the xsd:schema document
element of the reference schema. </body> </html> erence
schema. </body> </html> l>
Constraint resolved by resolution to MPD [Rule 3-4]
English
NDR [Rule 7-69]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 3-5.1]</b> If a schema in a reference schema set
has been omitted from a derived subset, then every xsd:import occurrence of that
schema MUST be removed from all schemas within the subset. </body>
</html> e subset. </body> </html> l>
Constraint on xsd:import is realized by the PSM-XSD transformations.
English
MPD [Rule 3-05.1]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-13] (REF, EXT)</b> A data
definition SHALL NOT contain explicit representational or data typing information such
as number characters, type of characters, etc., unless the very nature of the
component can be described only by such information. </p>
<p> <b>Rationale</b> A component definition
is intended to describe semantic meaning only, not representation or structure. How a
component with simple content is represented is indicated through the representation
term and further refined through constraints. </p> </body>
</html> tion term and further refined through constraints.
</p> </body> </html> body>
</html>
Non-computable constraint.
English
NDR [Rule 7-13]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 9-21] (REF, SUB, EXT) </b>Within the schema, the
name of an element declaration that is of complex content and that does not correspond
to a concept listed in NDR Table 9-2: Representation Terms MUST NOT use a
representation term. </body> </html> entation term.
</body> </html> l>
Non-computable constraint.
English
NDR [Rule 9-21]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-5] (REF, SUB, EXT)</b> The
schema SHALL NOT contain the element xsd:include. </p> <p>
<b>Rationale</b> Element xsd:include brings schemas
defined in separate files into the current namespace. It breaks a namespace up into
arbitrary partial schemas, which needlessly complicates the schema structure, making
it harder to reuse and process, and also increases the likelihood of conflicting
definitions. </p> <p> Inclusion of schemas that do not
have namespaces also complicates schema understanding. This inclusion makes it
difficult to find the realization of a specific schema artifact and create aliases for
schema components that should be reused. Inclusion of schemas also violates [Principle
8], as it uses multiple schemas to construct a namespace. </p>
</body> </html> mas also violates [Principle 8], as it
uses multiple schemas to construct a namespace. </p>
</body> </html> body> </html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-05]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 3-3]</b> NIEM subset schemas may omit all
xsd:annotation elements that are in the NIEM reference schema from which it is
derived. </body> </html> ved. </body>
</html> l>
Constraint satisfied by other documentedComponent rules which exclude subset
schemas.
English
MPD [Rule 3-03]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 7-34] (REF, EXT)</b> Within the schema, an
element appinfo:ReferenceTarget that does not carry an attribute appinfo:namespace
SHALL refer to the target namespace of the schema in which it is used.
</body> </html> is used. </body>
</html> ml>
Constraint resolved by PSM-XSD transformations.
English
NDR [Rule 7-34]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-16] (REF, EXT) </b>The schema
SHALL NOT contain any of the elements xsd:unique, xsd:key, xsd:keyref, xsd:selector,
or xsd:field. </p> <p>
<b>Rationale</b> XML Schema provides NIEM with the ability
to apply uniqueness constraints to schema-validated content. These mechanisms,
however, establish relationships in a way that is very difficult to understand,
extend, and keep consisent through schema reuse. These elements may be used in subset
schemas and constraint schemas. </p> </body>
</html> be used in subset schemas and constraint schemas.
</p> </body> </html> </html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-16]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 6-24] (REF, SUB, EXT)</b> Within the schema, if
the element xsd:sequence carries the attribute minOccurs, it MUST set the value for
the attribute to 1. </body> </html> ute to 1.
</body> </html> l>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-24]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-70] (SUB) </b>The schema must
be constructed such that any instance that is XML Schema valid against the schema must
also be XML Schema valid against the base schema. </p> <p>
<b>Rationale</b> A subset schema is a briefer, abridged
form of its base schema. The subset schema is intended to stand in the place of the
base schema for the purpose of XML Schema validation in many situations. As such, it
is imperative that the subset schema sustain the constraints expressed by the base
schema. The NDR does not specify what mechanisms a subset schema must use to support
the constraints of the base schema. </p> </body>
</html> t schema must use to support the constraints of the base schema.
</p> </body> </html> </html>
Constraint resolved by resolution to MPD [Rule 3-1]
English
NDR [Rule 7-70]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-30] (REF, EXT)</b> Within the
schema, the element appinfo:ReferenceTarget SHALL identify the XML Schema type
definition of an element information item to which an instance of a reference element
may validly refer. The element appinfo:ReferenceTarget SHALL NOT be used for any other
purpose. </p> <p>
<b>Rationale</b> This describes the meaning of a reference
target. The term type definition is as used in
<b>[XMLSchemaStructures]</b>, in the PSVI
(post-schema-validation infoset) definition for an element information item. The
element appinfo:ReferenceTarget is required to express the type of referenced content.
XML Schema does not provide this level of type safety. </p>
</body> </html> erenced content. XML Schema does not
provide this level of type safety. </p> </body>
</html> body> </html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 7-30]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-17] (REF, SUB, EXT)</b> The
schema SHALL NOT contain the element xsd:all. </p> <p>
<b>Rationale</b> The element xsd:all provides a set of
particles (e.g., elements) that may be included in an instance, in no particular
order. This can greatly complicate processing and may be difficult to comprehend and
satisfy. </p> </body> </html> difficult to
comprehend and satisfy. </p> </body> </html>
body> </html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-17]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-41] (REF, SUB, EXT)</b>
Within the schema, the element xsd:import MUST carry the attribute schemaLocation.
</p> <p> <b>Rationale</b> An
import that does not specify a schema location gives no clue to processing
applications as to where to find an implementation of the namespace. Even though such
a provided schema location may be overridden, it is important that an initial default
be provided for processing. </p> </body>
</html> initial default be provided for processing. </p>
</body> </html> body> </html>
Constraint realized by PSM-MPD transformations.
English
NDR [Rule 6-41]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 6-1] (REF, SUB, EXT) </b>Within the schema, an
element xsd:complexType SHALL NOT own the attribute mixed with the value true.
</body> </html> rue. </body>
</html> l>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-01]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 3-4] </b>Each schema in a schema subset derived
from a schema reference set bears the same (target) namespace as the schema in the
reference set on which it is based. </body> </html> is
based. </body> </html> l>
self.purposeURI='http://reference.niem.gov/niem/resource/mpd/lexicon/1.0/purpose#subset-schema'
implies self.base_ElementImport.importedElement.oclAsType(Package).packagedElement
->exists(element| element.clientDependency
->select(d|d.stereotypedBy('References')).supplier.getNearestPackage()
->select(r|r.stereotypedBy('Namespace')).getStereotypeApplication('Namespace').targetNamespace=
element.owner.getStereotypeApplication('Namespace').targetNamespace ) )
OCL2.0
MPD [Rule 3-04]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 7-5] (REF, EXT)</b> Within the schema, any
element xsd:simpleType MUST be a documented component. </body>
</html> ent. </body> </html> l>
( self.base_ElementImport.profiledBy('NIEM_PSM_Profile') and ( (
self.purposeURI='http://reference.niem.gov/niem/resource/mpd/lexicon/1.0/purpose#reference-schema')
or (
self.purposeURI='http://reference.niem.gov/niem/resource/mpd/lexicon/1.0/purpose#extension-schema')
) ) implies self.base_ElementImport.importedElement.oclAsType(Package).packagedElement
->select(c|c.oclIsKindOf(DataType)).oclAsType(DataType)
->forAll(simpleType |
simpleType.ownedComment->exists(documentation|documentation.stereotypedBy('Documentation')))
OCL2.0
NDR [Rule 7-05]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-42] (REF, SUB, EXT)</b>
Within the schema, the value of the required attribute schemaLocation carried by the
element xsd:import MUST match either the production <absolute-URI> or
the definition of "relative-path reference," as defined by
<b>[RFC3986]</b>. </p> <p>
<b>Rationale</b> The default value may be specified either
as absolute or relative URIs. Since URNs are not resolvable, they are inappropriate
for use in schemaLocation. The requirement for conformance to "relative-path
reference" is required to avoid the more obscure syntax of "network-path reference"
and the system-specific "absolute-path reference." </p>
</body> </html> ot; and the system-specific "absolute-path
reference." </p> </body> </html>
body> </html>
This constraint is superceded by MPD [Rule 6-4]. Implementation of MPD [Rule 6-4]
resolves this constraint.
English
NDR [Rule 6-42]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-4] (REF, EXT) </b>Within the
schema, any element xsd:complexType MUST be a documented component. </p>
<p> Note that MPD [Rule 3-3] relaxes this requirement for subset
schemas. </p> </body> </html> nt for subset
schemas. </p> </body> </html>
</html>
( self.base_ElementImport.profiledBy('NIEM_PSM_Profile') and ( (
self.purposeURI='http://reference.niem.gov/niem/resource/mpd/lexicon/1.0/purpose#reference-schema')
or (
self.purposeURI='http://reference.niem.gov/niem/resource/mpd/lexicon/1.0/purpose#extension-schema')
) ) implies self.base_ElementImport.importedElement.oclAsType(Package).packagedElement
->select(c|c.oclIsKindOf(Class) and
not(c.stereotypedBy('PropertyHolder'))).oclAsType(Class) ->forAll(complexType |
complexType.ownedComment->exists(documentation|documentation.stereotypedBy('Documentation')))
OCL2.0
NDR [Rule 7-04]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 9-4] (REF, SUB, EXT) </b>The
hyphen character ('-') MAY appear in component names only when used as a separator
between parts of a single word, phrase, or value, which would otherwise be
incomprehensible without the use of a separator. </p> <p>
<b>Rationale</b> Names of standards and specifications, in
particular, tend to consist of series of discrete numbers. Such names require some
explicit separator to keep the values from running together. The separator used within
NIEM is the hyphen. </p> </body> </html>
her. The separator used within NIEM is the hyphen. </p>
</body> </html> body> </html>
Non-computable constraint.
English
NDR [Rule 9-4]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-59] (REF, SUB, EXT)
</b>Within the schema, the attribute ref owned by any element
xsd:attributeGroup MUST have a value of a qualified name (possibly using the default
namespace) that SHALL resolve to the namespace for the NIEM structures namespace and
the local name SimpleObjectAttributeGroup. </p> <p>
<b>[Rationale] </b>The only attribute group used within
NIEM-conformant schemas is structures:SimpleObjectAttributeGroup. Therefore, within a
NIEM-conformant schema, only this attribute group can be referenced.
</p> </body> </html> mant schema, only this
attribute group can be referenced. </p> </body>
</html> </html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-59]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 5-1] (REF, SUB, EXT, CON)</b>
The schema MUST conform to XML as specified by<b>
[XML]</b>. </p> <p>
<b>Rationale</b> XML is a well-known, commonly used W3C
Recommendation. It is supported by a large number of commercial and open-source
software tools. It is a simple, well-defined, semi-structured data format that is
flexible enough to allow for easy extension. XML works with many other powerful
associated technologies such as XML Schema, XSLT, and XPath. Artifacts of NIEM conform
to the most recent recommendation for XML. </p> </body>
</html> f NIEM conform to the most recent recommendation for XML.
</p> </body> </html> </html>
This constraint is realized by PSM-XSD transformations.
English
NDR [Rule 5-1]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 3-8] </b>A constraint schema bears a target
namespace that has been previously assigned by a reference schema, extension schema,
or exchange schema, or is a schema that is intended to support a constraint schema
that has such a target namespace. </body> </html> get
namespace. </body> </html> l>
Constraint schemas are not modeled with the NIEM Profile. This constraint is not
applied.
English
MPD [Rule 3-08]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 6-39] (REF, SUB, EXT)</b> Within the schema, the
element xsd:import MUST carry the attribute namespace. </body>
</html> ace. </body> </html> l>
Constraint realized by PSM-MPD transformations.
English
NDR [Rule 6-39]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-2] (REF, SUB, EXT)</b> Within
the schema, an element declaration that is of complex content SHALL NOT own the
attribute mixed with the value true. </p> <p>
<b>Rationale</b> Mixed content allows the mixing of data
tags with text. Languages such as XHTML use this syntax for markup of text.
NIEM-conformant schemas define XML that is for data exchange, not text markup. Mixed
content creates complexity in processing, defining, and constraining content.
</p> <p> Well-defined markup languages exist outside NIEM
and may be used with NIEM data. External schemas may include mixed content and may be
used with NIEM. However, mixed content must not be defined by NIEM-conformant schemas
in keeping with [Principle 9]. </p> </body>
</html> content must not be defined by NIEM-conformant schemas in
keeping with [Principle 9]. </p> </body>
</html> /body> </html>
This constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-02]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-54] (REF, EXT) </b>The schema
MUST import the NIEM structures namespace. </p> <p>
<b>Rationale</b> For uniformity, all NIEM-conformant
schemas must import the structures namespace. </p> </body>
</html> the structures namespace. </p>
</body> </html> y> </html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 7-54]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 9-9] (REF, SUB, EXT)</b> A noun used as a term in
the name of an XML Schema component MUST be in singular form unless the concept itself
is plural. </body> </html> plural. </body>
</html> tml>
Non-computable constraint.
English
NDR [Rule 9-9]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-51] (REF, EXT)</b> Within the
schema, an element in the XML Schema namespace MUST NOT occur as a descendant of any
element xsd:appinfo. </p> <p>
<b>Rationale</b> NIEM-conformant schemas are designed to
be very easily processed. Although uses of XML Schema elements as content of
xsd:appinfo elements could be contrived, it is not current practice and could
seriously complicate the authoring of schema validators and processors, such as XSLT,
which may evaluate XML elements by their namespaces and names. Forbidding the use of
XML Schema elements outside valid uses of schema will simplify such processing.
</p> </body> </html> ents outside valid uses
of schema will simplify such processing. </p> </body>
</html> body> </html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-51]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 9-13] (REF, SUB, EXT) </b>The
object-class term of a NIEM component SHALL consist of a term identifying a category
of concrete concepts or entities. </p> <p>
<b>Rationale</b> The object-class term indicates the
object category that this data component describes or represents. This term provides
valuable context and narrows the scope of the component to an actual class of things
or concepts. </p> </body> </html> t to an
actual class of things or concepts. </p> </body>
</html> body> </html>
Non-computable constraint.
English
NDR [Rule 9-13]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 7-20] (REF, EXT) </b>Within the schema, an
element appinfo:Base that does not own an attribute appinfo:namespace SHALL refer to
the target namespace of the schema in which it is used. </body>
</html> is used. </body> </html> ml>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 7-20]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-4] (REF, SUB, EXT) </b>The
schema SHALL NOT contain the element xsd:notation. </p>
<p> <b>Rationale</b> XML Schema notations
allow the attachment of system and public identifiers on fields of data. The notation
mechanism does not play a part in validation of instances and is not supported by
NIEM. </p> </body> </html> tances and is not
supported by NIEM. </p> </body> </html>
</html>
Constrained realized by PSM-XSD transformations.
English
NDR [Rule 6-04]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 9-18] (REF, EXT)</b> If any
word in the representation term is redundant with any word in the property term, one
occurrence SHOULD be deleted. </p> <p>
<b>Rationale</b> This rule, carried over from 11179, is
designed to prevent repeating terms unnecessarily within component names. For example,
this rule allows designers to avoid naming an element "PersonFirstNameName."
</p> </body> </html> an element
"PersonFirstNameName." </p> </body> </html>
body> </html>
Non-computable constraint.
English
NDR [Rule 9-18]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 9-14] (REF, SUB, EXT)</b> A
property term SHALL describe or represent a characteristic or subpart of an entity or
concept. </p> <p>
<b>Rationale</b> The property term describes the central
meaning of the data component. </p> </body>
</html> of the data component. </p> </body>
</html> body> </html>
Non-computable constraint.
English
NDR [Rule 9-14]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 6-21] (EXT)</b> Within the schema, any immediate
child of a model group xsd:choice element MUST be one of xsd:annotation or
xsd:element. </body> </html> ent. </body>
</html> l>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-21]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 9-11] (REF, SUB, EXT)</b>
Articles, conjunctions, and prepositions SHALL NOT be used in NIEM component names
except where they are required for clarity or by standard convention.
</p> <p> <b>Rationale</b>
Articles (e.g., a, an, the), conjunctions (e.g., and, or, but), and prepositions
(e.g., at, by, for, from, in, of, to) are all disallowed in NIEM component names,
unless they are required. For example, PowerOfAttorneyCode requires the preposition.
These rules constrain slight variations in word forms and types to improve consistency
and reduce potentially ambiguous or confusing component names. </p>
</body> </html> y and reduce potentially ambiguous or
confusing component names. </p> </body>
</html> body> </html>
Non-computable constraint.
English
NDR [Rule 9-11]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-18] (REF, EXT) </b>Within the
schema, the element appinfo:Base SHALL indicate, by namespace and name, one of the
following: </p> <p> 1. A NIEM-conformant schema component.
</p> <p> 2. structures:Object. </p>
<p> 3. structures:Association. </p> </body>
</html> . </p> <p> 3.
structures:Association. </p> </body> </html>
p> </body> </html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 7-18]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-12] (REF, EXT)</b> An object
class SHALL NOT be redefined within the definitions of the components that represent
properties or subparts of that entity or class. </p> <p>
<b>Rationale</b> Data definitions should be concise,
precise, and unambiguous without embedding additional definitions of data elements
that have already been defined once elsewhere (such as object classes).
<b>[ISO 11179 Part 4] </b>says that definitions should not
be nested inside other definitions. Furthermore, a data dictionary is not a language
dictionary. It is acceptable to reuse terms (object class, property term, and
qualifier terms) from a component name within its corresponding definition to enhance
clarity, as long as the requirements and recommendations of <b>[ISO
11179 Part 4]</b> are not violated. This further enhances brevity and
precision. </p> </body> </html> [ISO 11179
Part 4]</b> are not violated. This further enhances brevity and
precision. </p> </body> </html> body>
</html>
Constraint realized by PSM-XSD transformation.
English
NDR [Rule 7-12]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 6-20] (EXT)</b> Within the schema, any immediate
child of a model group xsd:sequence element MUST be one of xsd:annotation,
xsd:element, xsd:choice, or xsd:any. </body> </html>
xsd:any. </body> </html> ml>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-20]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-62] (REF, EXT)</b> Within the
schema, an element xsd:import that imports a namespace defined by an external schema
MUST be a documented component. </p> <p>
<b>Rationale</b> A NIEM-conformant schema has well-known
documentation points. Therefore, a schema that imports a NIEM-conformant namespace
need not provide additional documentation. However, when an external schema is
imported, appropriate documentation must be provided at the point of import because
documentation associated with external schemas is undefined and variable. In this
particular case, documentation of external schemas is required at their point of use
in NIEM. </p> </body> </html> n of external
schemas is required at their point of use in NIEM. </p>
</body> </html> body> </html>
Constraint realized by PSM-MPD transformations, based on required documentation
for modeled external schema.
English
NDR [Rule 7-62]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 7-11] (REF, EXT)</b> An object class SHALL have
one and only one associated semantic meaning (i.e., a single word sense) as described
in the definition of the component that represents that object class.
</body> </html> ct class. </body>
</html> l>
Non-computable constraint.
English
NDR [Rule 7-11]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-6] (REF, SUB, EXT)</b> The
schema SHALL NOT contain the element xsd:redefine. </p>
<p> <b>Rationale</b> The xsd:redefine
element allows an XML Schema document to restrict and extend components from a
namespace, in that very namespace. Such redefinition introduces duplication of
definitions, allowing multiple definitions to exist for components from a single
namespace. This violates [Principle 8] that a single reference schema defines a
NIEM-conformant namespace. </p> </body>
</html> erence schema defines a NIEM-conformant namespace.
</p> </body> </html> body>
</html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-06]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-16] (REF, EXT)</b> A
component that is deprecated SHALL be indicated as such by the component having
application information appinfo:Deprecated, with an attribute value with a value of
true. </p> <p>
<b>Rationale</b> Deprecation can allow version management
to be more consistent; versions of schema may be incrementally improved without
introducing validation problems and incompatibility. As XML Schema lacks a deprecation
mechanism, NIEM defines such a mechanism. </p> </body>
</html> recation mechanism, NIEM defines such a mechanism.
</p> </body> </html> </html>
Deprecated indicator not currently in NIEM Profiles, no constraint specified.
English
NDR [Rule 7-16]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-56] (REF, SUB, EXT)</b>
Within the schema, given an element xsd:complexContent with a child xsd:extension
owning an attribute base, the attribute base MUST have a value that resolves to the
name of one of the following: </p> <p> 1. The type
structures:ComplexObjectType. </p> <p> 2. The type
structures:MetadataType. </p> <p> 3. The type
structures:AugmentationType. </p> <p> 4. A complex type
that is a NIEM-conformant component. </p> <p>
<b>[Rationale]</b> This rule ensures that a CCC has
well-defined ancestry. In turn, this ensures that every CCC has well-defined
semantics. </p> </body> </html> CCC has
well-defined ancestry. In turn, this ensures that every CCC has well-defined
semantics. </p> </body> </html> p>
</body> </html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-56]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-47] (REF, EXT)</b> Within the
schema, the content of the xsd:documentation element that constitutes the data
definition of a component MUST be character information items as specified by
<b>[XMLInfoSet]</b>. </p> <p>
<b>Rationale</b> According to the XML Schema
specification, the content of xsd:documentation elements is intended for human
consumption, whereas other structured XML content is intended for machine consumption.
Therefore, the xsd:documentation element MUST NOT contain structured XML data. As
such, any XML content appearing within a documentation element is in the context of
human-targeted examples and should be escaped using < and >. This rule
also prohibits comments within documentation elements. </p>
<p> See <b>[SchemaForXMLSchema]</b>, the
schema for XML Schema, as an example of documentation elements containing properly
escaped XML elements. </p> </body> </html>
XML Schema, as an example of documentation elements containing properly escaped XML
elements. </p> </body> </html> >
</body> </html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-47]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 5-3] (REF, SUB, EXT, CON)
</b>The schema MUST conform to the W3C XML Schema Recommendations: XML
Schema Part 1: Structures and XML Schema Part 2: Datatypes, as specified by
<b>[XMLSchemaStructures]</b> and
<b>[XMLSchemaDatatypes]</b>. </p>
<p> <b>Rationale</b> XML Schema has become
the generally accepted schema language and is experiencing the most widespread
adoption. Although other schema languages exist that offer their own advantages and
disadvantages, the current approach is to base NIEM on XML Schema. </p>
</body> </html> ages, the current approach is to base NIEM
on XML Schema. </p> </body> </html>
</html>
This constraint is realized by PSM-XSD transformations.
English
NDR [Rule 5-3]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 6-31] (REF, SUB) </b>Within the schema, if an
element declaration carries the attribute final, it MUST set the value for the
attribute to the empty string. </body> </html> y string.
</body> </html> l>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-31]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-53] (REF, SUB, EXT)</b> Any
attribute declaration referenced by a component within the schema MUST be from one of
the following: </p> <p> 1. The schema being defined.
</p> <p> 2. A namespace imported as NIEM-conformant.
</p> <p> 3. The structures namespace. </p>
<p> 4. The XML namespace. </p> <p> 5. An
external namespace, in accordance with the rules for external schemas as specified by
this specification. </p> <p>
<b>Rationale</b> NIEM-conformant schemas are based on
other NIEM-conformant schemas. All attributes and elements must be from
NIEM-conformant schemas, the structures namespace, the XML namespace, or an external
namespace. This applies to elements referenced for substitution groups as well. It
does not apply to content of the schema (e.g., within annotations) or to the XML
Schema declarations themselves. It applies only to attributes and elements referenced
by the XML Schema components. </p> </body>
</html> otations) or to the XML Schema declarations themselves. It
applies only to attributes and elements referenced by the XML Schema components.
</p> </body> </html> >
</body> </html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 7-53]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-55] (REF, SUB, EXT, INS)</b>
The schema or instance MUST use content within the NIEM structures namespace as
specified in the NDR document and ONLY as specified by the NDR document.
</p> <p> <b>Rationale</b> This
rule further enforces uniformity and consistency by mandating use of the NIEM
structures namespace as is, without modification. Users are not allowed to insert
types, attributes, etc. that are not specified by this document (the NDR).
</p> </body> </html> that are not specified
by this document (the NDR). </p> </body>
</html> </html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 7-55]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-1] (REF, EXT)</b> Within the
schema, the document element xsd:schema MUST have application information
appinfo:ConformantIndicator, with text content "true". </p>
<p> <b>Rationale</b> The
appinfo:ConformantIndicator element is how NIEM-conformant schemas indicate that they
are, in fact, NIEM-conformant. Without such an indicator, conformance would have to be
"guessed" by readers and processors. </p> </body>
</html> "guessed" by readers and processors. </p>
</body> </html> y> </html>
self.base_ElementImport.profiledBy('NIEM_PSM_Profile') implies ( (
(self.natureURI='http://reference.niem.gov/niem/resource/mpd/lexicon/1.0/purpose#reference-schema')
or
(self.natureURI='http://reference.niem.gov/niem/resource/mpd/lexicon/1.0/purpose#extension-schema')
) implies self.importedElement.getStereotypeApplication('Namespace').isConformant )
OCL2.0
NDR [Rule 7-01]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 9-20] (REF, SUB, EXT) </b>Within the schema, the
name of an element declaration that is of complex content, and that corresponds to a
concept listed in NDR Table 9-2: Representation Terms, MUST use a representation term
from that table. </body> </html> om that table.
</body> </html> l>
Non-computable constraint.
English
NDR [Rule 9-20]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 9-30] (REF, SUB, EXT)</b>
Within the schema, the name of any attribute group definition schema component SHALL
use the representation term AttributeGroup. </p> <p>
<b>Rationale</b> This clearly identifies attribute groups
and partitions their names from the names of other types of schema components.
</p> </body> </html> of other types of
schema components. </p> </body> </html>
</html>
The only Attribute Group allowed in NIEM is the
structures:SimpleObjectAttributeGroup. The constraint is realized by PSM-XSD
transformations.
English
NDR [Rule 9-30]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 9-17] (REF, SUB, EXT) </b>The
order of qualifiers SHALL NOT be used to differentiate names. </p>
<p> <b>Rationale</b> Very large vocabularies
may have many similar and closely related properties and concepts. The use of object,
property, and representation terms alone is often not sufficient to construct
meaningful names that can uniquely distinguish such components. Qualifier terms
provide additional context to resolve these subtleties. However, swapping the order of
qualifiers rarely (if ever) changes meaning; qualifier ordering is no substitute for
meaningful terms. </p> </body> </html>
aning; qualifier ordering is no substitute for meaningful terms. </p>
</body> </html> </html>
Non-computable constraint.
English
NDR [Rule 9-17]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-31] (REF, EXT) </b>Within the
schema, a reference element MUST have at most one instance of the element
appinfo:ReferenceTarget. </p> <p>
<b>Rationale</b> Content elements in XML Schema may have
at most one type. This rule ensures that reference elements follow the same pattern.
</p> </body> </html> ents follow the same
pattern. </p> </body> </html>
</html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 7-31]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 9-16] (REF, SUB, EXT)</b> The number of qualifier
terms SHOULD be limited to the absolute minimum required to make the component name
unique and understandable. </body> </html> tandable.
</body> </html> l>
Non-computable constraint.
English
NDR [Rule 9-16]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-51] (REF, SUB, EXT) </b>Any
type definition referenced by a component within the schema MUST be from one of the
following: </p> <p> 1. The schema being defined.
</p> <p> 2. A namespace imported as NIEM-conformant.
</p> <p> 3. The XML Schema namespace. </p>
<p> 4. The structures namespace. </p> <p>
<b>Rationale</b> NIEM-conformant schemas are based on
other NIEM-conformant schemas and the supporting namespaces. This simplifies
processing and understanding of data. </p> </body>
</html> emas and the supporting namespaces. This simplifies processing
and understanding of data. </p> </body>
</html> body> </html>
Constraint resolved by PSM-XSD transformations.
English
NDR [Rule 7-51]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 6-19] (REF, SUB) </b>Within the schema, any
immediate child of a model group xsd:sequence element MUST be one of xsd:annotation or
xsd:element </body> </html> d:element
</body> </html> l>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-19]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 9-12] (REF, SUB, EXT)</b>
Except as specified elsewhere in this document, any element or attribute defined
within the schema SHALL have a name that takes the form: </p>
<p> � Object-class qualifier terms (0 or more). </p>
<p> � An object class term (1). </p> <p> �
Property qualifier terms (0 or more). </p> <p> � A
property term (1). </p> <p> � Representation qualifier
terms (0 or more). </p> <p> � A representation term (1).
</p> <p> <b>Rationale</b>
Consistent naming rules are helpful for users who wish to understand components with
which they are unfamiliar, as well as for users to find components with known
semantics. This rule establishes the basic structure for an element or attribute name,
in line with the rules for names under <b>[ISO 11179 Part
5]</b>. Note that many elements with complex type should not have a
representation term. </p> </body> </html> e
with the rules for names under <b>[ISO 11179 Part 5]</b>.
Note that many elements with complex type should not have a representation term.
</p> </body> </html> >
</body> </html>
Non-computable constraint.
English
NDR [Rule 9-12]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-13] (REF, SUB, EXT)
</b>Within the schema, any occurrence of the element xsd:complexType or
xsd:simpleType MUST appear as an immediate child of the element xsd:schema.
</p> <p> <b>Rationale</b> NIEM
does not support anonymous types in NIEM-conformant schemas. All XML Schema
"top-level" types (children of the document element) are required by XML Schema to be
named. By requiring NIEM type definitions to be top level, they are forced to be named
and are therefore globally reusable. </p> </body>
</html> d to be named and are therefore globally reusable.
</p> </body> </html> body>
</html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-13]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-17] (REF, EXT) </b>Within the
schema, the element appinfo:Base MAY be used in one of the following ways:
</p> <p> 1. By a type definition, to indicate the base
type, or structures:Object or structures:Association. </p>
<p> 2. By an element declaration, to indicate the base element.
</p> <p> The element appinfo:Base SHALL NOT be used for
any other purpose. </p> <p>
<b>Rationale</b> The appinfo:Base element is required to
clarify semantics of types as object or association types, when such derivation is not
otherwise derivable from the component definitions. </p>
</body> </html> , when such derivation is not otherwise
derivable from the component definitions. </p> </body>
</html> body> </html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 7-17]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-14] (REF, SUB, EXT)</b>
Within the schema, any element declaration carrying the attribute name MUST appear as
an immediate child of the document element xsd:schema. </p>
<p> <b>Rationale</b> All schema components
defined by NIEM-conformant schemas must be named, accessible from outside the defining
schema, and reusable across schemas. Local element definitions provide named elements
that are not reusable outside the context in which they are defined. Requiring named
NIEM elements to be top level ensures that they are globally reusable.
</p> </body> </html> to be top level ensures
that they are globally reusable. </p> </body>
</html> /body> </html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-14]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-35] (REF, EXT)</b> Within the
schema, an element appinfo:ReferenceTarget SHALL carry an attribute appinfo:name. The
value of this attribute SHALL indicate the local name of a type definition schema
component within the namespace specified by the element. </p>
<p> <b>Rationale</b> Together, this set of
rules establishes the element appinfo:ReferenceTarget as a reference to a
NIEM-conformant type definition schema component that a reference element instance may
reference. </p> </body> </html> t that a
reference element instance may reference. </p> </body>
</html> body> </html>
Constraint resolved by PSM-XSD transformations.
English
NDR [Rule 7-35]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-54] (REF, SUB, EXT)</b>
Within the schema, given an element xsd:simpleContent with a child xsd:extension
owning an attribute base, if the attribute base has a value that resolves to the name
of a simple type, then the element xsd:extension MUST have an immediate child element
xsd:attributeGroup. </p> <p>
<b>[Rationale]</b> This rule ensures that a CSC that is
created as an immediate extension of a simple type adds the attributes required for
specific NIEM linking mechanisms. The attribute group is required to be
structures:SimpleObjectAttributeGroup by NDR [Rule 6-59]. </p>
</body> </html> structures:SimpleObjectAttributeGroup by
NDR [Rule 6-59]. </p> </body> </html>
body> </html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-54]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 6-27] (REF, EXT)</b> Within the schema, if a
complex type definition carries the attribute block, it MUST set the value for the
attribute to the empty string. </body> </html> y string.
</body> </html> l>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-27]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 9-15] (REF, SUB, EXT) </b>Multiple qualifier
terms MAY be used within a component name as necessary to ensure clarity and
uniqueness within its namespace and usage context. </body>
</html> context. </body> </html> ml>
Non-computable constraint.
English
NDR [Rule 9-15]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-52] (REF, SUB, EXT)</b> Any
element declaration referenced by a component within the schema MUST be from one of
the following: </p> <p> 1. The schema being defined.
</p> <p> 2. A namespace imported as NIEM-conformant.
</p> <p> 3. The structures namespace. </p>
<p> 4. An external namespace, in accordance with the rules for external
schemas as specified by this specification. </p> </body>
</html> the rules for external schemas as specified by this
specification. </p> </body> </html>
/body> </html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 7-52]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 9-8] (REF, SUB, EXT) </b>The
schema MUST consistently use approved acronyms, abbreviations, and word truncations
within defined names. The approved shortened forms are defined in Table 9-1 of the
NDR: Abbreviations Used in NIEM Core Names . </p> <p>
<b>Rationale</b> Consistent, controlled, and documented
abridged terms that are used frequently and/or tend to be lengthy can support
readability, clarity, and reduction of name length. </p>
</body> </html> eadability, clarity, and reduction of name
length. </p> </body> </html>
</html>
Non-computable constraint.
English
NDR [Rule 9-8]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 5-2] (REF, SUB, EXT, CON)
</b>The schema MUST conform to the specification for namespaces in XML,
as defined by <b>[XMLNamespaces]</b> and
<b>[XMLNamespacesErrata]</b>. </p>
<p> <b>Rationale</b> NIEM is designed to
facilitate cross-domain data exchanges and interoperability. The ultimate scope of
NIEM is anticipated to be quite large. The primary purpose of namespaces is to avoid
naming conflicts, which for NIEM could become quite common, since NIEM stakeholders
and IEPD developers define and name many of their own data components independently.
Therefore, in NIEM, XML namespaces are employed both to avoid name clashes and to
provide a level of independence to participating domains. </p>
</body> </html> lashes and to provide a level of
independence to participating domains. </p> </body>
</html> body> </html>
This constraint is realized by PSM-XSD transformations.
English
NDR [Rule 5-2]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-32] (REF, SUB, EXT)</b>
Within the schema, if the document element xsd:schema carries the attribute
finalDefault, it MUST set the value for that attribute to the empty string.
</p> <p> <b>Rationale</b>
Restriction of derivation options reduces capacity for reuse and so is forbidden
within reference and subset schemas. As well, the use of finalDefault complicates
understanding of schemas, so it is only allowed in constraint schemas.
</p> </body> </html> o it is only allowed in
constraint schemas. </p> </body> </html>
body> </html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-32]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 3-5]</b> A schema contained in
a reference schema set may be omitted from a derived subset, if and only if ALL of the
following conditions are true within that schema: </p> <p>
� No elements/attributes declared or types defined in the schema are required for
business exchange purposes. AND </p> <p> � No
elements/attributes declared or types defined in the schema are required to support
other elements or types within the subset for exchange purposes; in other words, no
references to elements or types in the schema exist in any other schema of the subset.
</p> </body> </html> s or types in the
schema exist in any other schema of the subset. </p>
</body> </html> body> </html>
UML well-formedness rules and semantics realize the constraint for referential
integrity.
English
MPD [Rule 3-05]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-38] (REF, SUB, EXT)
</b>Within the schema, an element MUST NOT be introduced more than once
into the direct content of a type definition. This applies to content acquired through
extension of base types. This does not apply to a base element or derived element to
one previously existing in the type definition. </p> <p>
<b>Rationale</b> This rule ensures that sequences of
elements are simple sequences. A type should not define, for example, a sequence of
elements A, B, then A again. Definitions should define, instead, what elements may be
included, and their cardinality. Specific orders should be expressed in instances,
when necessary, by the use of the attribute structures:sequenceID. </p>
</body> </html> ces, when necessary, by the use of the
attribute structures:sequenceID. </p> </body>
</html> body> </html>
Constraint is resolved by PSM-XSD transformations. Constraint also addressed by
UML Property order and naming constraints.
English
NDR [Rule 7-38]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 6-3] (REF, SUB, EXT) </b>The schema SHALL NOT
contain a reference to the type definition xsd:NOTATION or to a type derived from that
type. </body> </html> ype. </body>
</html> l>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-03]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 7-6] (REF, EXT) </b>Within the schema, any
element xsd:element that is an immediate child of an element xsd:schema MUST be a
documented component. </body> </html> omponent.
</body> </html> l>
( self.base_ElementImport.profiledBy('NIEM_PSM_Profile') and ( (
self.purposeURI='http://reference.niem.gov/niem/resource/mpd/lexicon/1.0/purpose#reference-schema')
or (
self.purposeURI='http://reference.niem.gov/niem/resource/mpd/lexicon/1.0/purpose#extension-schema')
) ) implies self.base_ElementImport.importedElement.oclAsType(Package).packagedElement
->select(c|c.oclIsKindOf(Classifier)).oclAsType(Classifier).attribute
->select(p|p.stereotypeApplication('XSDProperty').kind=XSDPropertyKindCode::element)
->forAll(attribute |
attribute.ownedComment->exists(documentation|documentation.stereotypedBy('Documentation')))
OCL2.0
NDR [Rule 7-06]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-39] (REF, EXT)</b> Within the
schema, an object type SHALL be a complex type definition that either constitutes a
NIEM-conformant component or for which there exists a NIEM-conformant component of one
of the following forms: </p> <p> 1. Has simple content, is
based on a simple type, and contains the attribute group
structures:SimpleObjectAttributeGroup, and has application information appinfo:Base of
structures:Object. </p> <p> 2. Has complex content, and is
based on complex type structures:ComplexObjectType, and has application information
appinfo:Base of structures:Object. </p> <p> 3. Is a
complex type that is derived from an object type, which is defined according to this
rule. </p> <p>
<b>Rationale</b> Object types are at the core of NIEM.
They are built in a uniform way, from a simple design pattern: they take one of the
two "root" forms outlined above, or they are built from other object types, depending
on whether they are of simple or complex content. </p>
</body> </html> quot; forms outlined above, or they are
built from other object types, depending on whether they are of simple or complex
content. </p> </body> </html> body>
</html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 7-39]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-23] (REF, EXT)</b> Within the
schema, if an element appinfo:Base indicates the structures namespace, then the value
of the attribute appinfo:name owned by the element appinfo:Base SHALL have a value of
one of the following: </p> <p> 1. structures:Object.
</p> <p> 2. structures:Association. </p>
<p> 3. A schema component defined by the structures schema.
</p> <p> <b>Rationale</b>
Together, this set of rules establishes the element appinfo:Base as a reference to
either a NIEM-conformant schema component or to a special NIEM component, which acts
as the base for the containing schema component. </p>
</body> </html> or to a special NIEM component, which acts
as the base for the containing schema component. </p>
</body> </html> </body>
</html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 7-23]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-48] (REF, SUB, EXT)</b> XML
comments SHALL not be used for persistent information about constructs within the
schema. </p> <p>
<b>Rationale</b> Since XML comments are not associated
with any specific XML Schema construct, there is no standard way to interpret
comments. As such, comments should be reserved for internal use, and XML Schema
annotations should be preferred for meaningful information about components. NIEM
specifically defines how information should be encapsulated in NIEM-conformant schemas
via xsd:annotation elements. </p> </body>
</html> d in NIEM-conformant schemas via xsd:annotation elements.
</p> </body> </html> </html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-48]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-40] (REF, SUB, EXT)
</b>Within the schema, the value of the required attribute namespace
owned by the element xsd:import MUST match the production <absolute-URI>
as defined by <b>[RFC3986]</b>. </p>
<p> <b>Rationale</b> An import that does not
specify a namespace is enabling reference to non-namespaced components. NIEM requires
that all components have a defined namespace. It is important that the namespace
declared by a schema be universally defined and unambiguous. Use of the standard XML
Base for processing is not specified by XML Schema; thus it is not supported here.
</p> </body> </html> t specified by XML
Schema; thus it is not supported here. </p> </body>
</html> body> </html>
Since imports are derived (and not modeled), the namespace for an import is the
same as the targetNamespace modeled for the referenced schema, and the implementation
of NDR [Rule 6-36] resolves this constraint.
English
NDR [Rule 6-40]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-49] (REF, EXT)</b> Within the
schema, any immediate child of an xsd:appinfo element SHALL be an element information
item or a comment information item. </p> <p>
<b>Rationale</b> Application information elements are
intended for automatic processing; thus they should contain machine-oriented data,
XML. </p> </body> </html> contain
machine-oriented data, XML. </p> </body>
</html> /body> </html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-49]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-36] (REF, SUB, EXT)</b>
Within the schema, a simple type definition that uses xsd:list SHOULD NOT be defined
if any member of the list requires a property or metadata that is different than other
members of the list. All members of the list SHOULD have the same metadata, and should
be related via the same properties. </p> <p>
<b>Rationale</b> The members of a list are not
individually addressable by NIEM metadata techniques. The members are also not
individually addressable by properties; a property has a value of all the members of
the list. NIEM provides no method for individually addressing a member of a list. If
an individual member of a list needs to be marked up in a manner different than other
members of the list, the use of individual elements may be preferred to the definition
of a list simple type. </p> </body> </html>
individual elements may be preferred to the definition of a list simple type.
</p> </body> </html> /body>
</html>
Definitional.
English
NDR [Rule 7-36]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 5-5] (REF, SUB, EXT)</b> A NIEM
component name SHALL be formed by applying the informative guidelines and examples
detailed in Annex A of <b>[ISO 11179 Part 5]</b>, with
exceptions as specified in the NDR document, most notably those specified in Section
9, Naming Rules. </p> <p>
<b>Rationale</b> The guidelines and examples of
<b>[ISO 11179 Part 5]</b> provide a simple, consistent
syntax for data names that captures context and thereby imparts a reasonable degree of
semantic precision. </p> </body> </html>
imparts a reasonable degree of semantic precision. </p>
</body> </html> </html>
Non-computable constraint.
English
NDR [Rule 5-5]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 6-33] (REF, SUB, EXT, CON)</b> Within the schema,
any element xsd:element SHALL NOT carry the attribute default. </body>
</html> ult. </body> </html> l>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-33]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-23] (REF, SUB, EXT) </b>The
schema SHALL NOT contain the element xsd:group. </p> <p>
<b>Rationale</b> NIEM does not allow groups of elements to
be named other than as named complex types. A group in XML Schema creates a named
entity that may be included in multiple types, and which consists of a sequence of or
choice between element particles. The NIEM has not developed a semantic model for
these components, and they are not integrated into NIEM's design. </p>
</body> </html> s, and they are not integrated into NIEM's
design. </p> </body> </html> body>
</html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-23]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 5-4] (REF, EXT)</b> Within a
NIEM-conformant schema, the data definition provided for each documented component
SHALL follow the requirements and recommendations for data definitions given by
<b>[ISO 11179 Part 4]</b>. </p>
<p> <b>Rationale</b> To advance the goal of
creating semantically rich NIEM-conformant schemas, it is necessary that data
definitions be descriptive, meaningful, and precise. <b>[ISO 11179 Part
4]</b> provides standard structure and rules for defining data
definitions. NIEM uses this standard for component definitions. </p>
</body> </html> tions. NIEM uses this standard for
component definitions. </p> </body> </html>
body> </html>
Non-computable constraint.
English
NDR [Rule 5-4]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-19] (REF, EXT)</b> Within the
schema, an attribute appinfo:namespace owned by an element appinfo:Base SHALL have a
value of either of the following: </p> <p> 1. A namespace
which is the target namespace of a NIEM-conformant schema. </p>
<p> 2. The structures namespace. </p>
</body> </html> <p> 2. The structures
namespace. </p> </body> </html>
</body> </html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 7-19]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 6-30] (REF, SUB) </b>Within the schema, if a
complex type definition carries the attribute final, it MUST set the value for the
attribute to the empty string. </body> </html> y string.
</body> </html> l>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-30]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-61] (REF, EXT)</b> Within the
schema, an element xsd:import that imports a namespace defined by an external schema
MUST have the application information appinfo:ConformantIndicator, with a value of
false. </p> <p>
<b>Rationale</b> Knowledge of the conformance of an
imported schema allows processors to understand the semantics of referenced
components, without additional processing. Namespaces imported into NIEM-conformant
schemas are assumed to be conformant unless otherwise indicated. </p>
</body> </html> are assumed to be conformant unless
otherwise indicated. </p> </body> </html>
</html>
Constraint realized by PSM-MPD transformations, based on isConformant tag for
referenced (external) schema.
English
NDR [Rule 7-61]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 7-21] (REF, EXT)</b> Within the schema, an
element appinfo:Base SHALL own an attribute appinfo:name. </body>
</html> ame. </body> </html> l>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 7-21]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-9] (REF, SUB, EXT)</b> Within
the schema, an element declaration with the attribute name and without the attribute
type MUST carry the attribute abstract with the value true. </p>
<p> <b>Rationale</b> Untyped element
declarations act as wildcards that may carry arbitrary data. By declaring such types
abstract, NIEM allows the creation of type independent semantics without allowing
arbitrary content to appear in XML instances. </p> </body>
</html> bitrary content to appear in XML instances. </p>
</body> </html> body> </html>
Constraint is realized by PSM-XSD transformations.
English
NDR [Rule 6-09]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 7-8] (REF, EXT)</b> Within the schema, any
element xsd:enumeration MUST be a documented component. </body>
</html> ent. </body> </html> l>
( self.base_ElementImport.profiledBy('NIEM_PSM_Profile') and ( (
self.purposeURI='http://reference.niem.gov/niem/resource/mpd/lexicon/1.0/purpose#reference-schema')
or (
self.purposeURI='http://reference.niem.gov/niem/resource/mpd/lexicon/1.0/purpose#extension-schema')
) ) implies self.base_ElementImport.importedElement.oclAsType(Package).packagedElement
->select(c|c.oclIsKindOf(Enumeration)).oclAsType(Enumeration).ownedLiteral
->forAll(literal |
literal.ownedComment->exists(documentation|documentation.stereotypedBy('Documentation')))
OCL2.0
NDR [Rule 7-08]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-60] (REF, EXT) </b>Within the
schema, if both elements NCName and NCNameReference exist, then the
appinfo:ReferenceTarget of any NCNameReference element MUST be the type of the element
NCName. </p> <p>
<b>Rationale</b> By [Rule 7-59], any such pair of
elements, NCName and NCNameReference, will have identical semantics. This rule ensures
that an NCNameReference element is documented to refer to the appropriate type (the
type of the corresponding NCName element) and no other. </p>
</body> </html> of the corresponding NCName element) and
no other. </p> </body> </html>
</html>
A Reference is modeled as a non-aggregate Property. A given property (from a
referenced PropertyHolder) may be redefined to be an aggregate (i.e., containment)
Property. The naming and type constraints are realized by PSM-XSD transformations.
English
NDR [Rule 7-60]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 9-10] (REF, SUB, EXT) </b>A verb used as a term
in the name of an XML Schema component MUST be used in the present tense unless the
concept itself is past tense. </body> </html> st tense.
</body> </html> l>
Non-computable constraint.
English
NDR [Rule 9-10]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-58] (REF, SUB, EXT)</b>
Within the schema, any occurrence of the element xsd:attributeGroup MUST own an
attribute ref. </p> <p>
<b>[Rationale]</b> The only attribute group used in
NIEM-conformant schemas is structures:SimpleObjectAttributeGroup, as established by
rules [Rule 6-59] and [Rule 7-39]. Therefore, NIEM-conformant schemas do not define
additional attribute groups. </p> </body>
</html> not define additional attribute groups. </p>
</body> </html> y> </html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-58]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-57] (REF, SUB, EXT)
</b>Within the schema, a reference element and only a reference element
SHALL be defined to be of type structures:ReferenceType. </p>
<p> <b>Rationale</b> Reference elements must
be of the reference type, and elements of the reference type must be reference
elements. This rule ensures that users always create reference elements using
structures:ReferenceType and cannot use structures:ReferenceType for any other
purpose. </p> </body> </html> se
structures:ReferenceType for any other purpose. </p>
</body> </html> body> </html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 7-57]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 7-10] (REF, EXT)</b> Words or synonyms for the
words within a data element definition SHALL NOT be reused as terms in the
corresponding component name if those words dilute the semantics and understanding of,
or impart ambiguity to, the entity or concept that the component represents.
</body> </html> nt represents. </body>
</html> </html>
Non-computable constraint.
English
NDR [Rule 7-10]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-44] (REF, SUB, EXT)
</b>Within the schema, when a namespace other than the XML namespace or
the XML Schema namespace is used, it MUST be imported into the schema using the
xsd:import element. </p> <p>
<b>Rationale</b> This rule ensures that used namespaces
have recognizable defining sources and that they will cooperate with existing tools.
</p> </body> </html> will cooperate with
existing tools. </p> </body> </html>
/body> </html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-44]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-22] (EXT) </b>The use of
xsd:choice SHALL define syntax, structure, grouping, and cardinality of instances, but
SHALL NOT define semantics. The semantics of a property within an xsd:choice SHALL be
identical to the semantics of the property within an xsd:sequence. </p>
<p> <b>Rationale</b> XML Schema provides the
capability for model groups to be recursively defined. This means that a sequence may
contain a sequence, and a choice may contain a choice. These rules are designed to
keep content models simple, comprehensive, and reusable: The content of an element
should boil down to a simple list of elements, defined in as straightforward a manner
as is possible to meet requirements. </p> </body>
</html> as straightforward a manner as is possible to meet requirements.
</p> </body> </html> body>
</html>
Definitional.
English
NDR [Rule 6-22]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 6-29] (REF, SUB) </b>Within the schema, if a
simple type definition carries the attribute final, it MUST set the value for the
attribute to the empty string. </body> </html> y string.
</body> </html> l>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-29]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-50] (REF, EXT) </b>Within the
schema, any element that is an immediate child of an xsd:appinfo element SHALL be in a
namespace. </p> <p>
<b>Rationale</b> Use of default namespace is allowed, but
content has to have a real namespace, and namespaces must be declared. The XML
namespaces specification includes the concept of content not in a namespace.
Non-namespaced data runs counter to the principle of distinctly identifiable data
definitions. </p> </body> </html> f
distinctly identifiable data definitions. </p> </body>
</html> body> </html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-50]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-3] (REF, SUB, EXT, CON)
</b>Two XML Schema documents SHALL have the same value for attribute
targetNamespace carried by the element xsd:schema, and different values for attribute
version carried by the element xsd:schema if and only if they are different views of
the same set of components. </p> <p>
<b>Rationale</b> These rules embody the basic philosophy
behind NIEM's use of namespaced components: A component is uniquely identified by its
class (e.g. element, attribute, type), its namespace (a URI), and its local name (an
unqualified string). Any two matching component identifiers refer to the same
component, even if the versions of the schemas containing each are different.
</p> </body> </html> ent, even if the
versions of the schemas containing each are different. </p>
</body> </html> body> </html>
Non-computable constraint.
English
NDR [Rule 7-03]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 9-2] (REF, SUB, EXT) </b>The
name of any XML Schema component defined by the schema SHALL be composed of words from
the English language, using the prevalent U.S. spelling, as provided by
<b>[OED]</b>. </p> <p>
<b>Rationale</b> The English language has many spelling
variations for the same word. For example, American English �program� has a
corresponding British spelling �programme.� This variation has the potential to cause
interoperability problems when XML components are exchanged because of the different
names used by the same elements. Providing users with a dictionary standard for
spelling will mitigate this potential interoperability issue. </p>
</body> </html> or spelling will mitigate this potential
interoperability issue. </p> </body> </html>
body> </html>
Non-computable constraint.
English
NDR [Rule 9-2]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 7-22] (REF, EXT)</b> Within the schema, if an
element appinfo:Base indicates a NIEM-conformant namespace, then the value of the
attribute appinfo:name owned by the element appinfo:Base SHALL indicate a schema
component in the indicated namespace. </body> </html> ted
namespace. </body> </html> l>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 7-22]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-34] (REF, SUB, EXT, CON)
</b>Within the schema, any element xsd:attribute SHALL NOT carry the
attribute default. </p> <p>
<b>Rationale</b> The use of default values means that the
act of validating a schema will insert a value into an XML instance where none existed
prior to schema validation. Schema validation is for rejection of invalid instances,
not for modifying instance content, as specified in [Principle 4]. </p>
</body> </html> nce content, as specified in [Principle
4]. </p> </body> </html> body>
</html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-34]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 7-33] (REF, EXT) </b>Within the schema, an
attribute appinfo:namespace carried by an element appinfo:ReferenceTarget SHALL
indicate the namespace of the referenced schema component. The indicated namespace
SHALL be defined by a reference or extension schema. </body>
</html> ension schema. </body> </html>
l>
Constraint resolved by PSM-XSD transformations.
English
NDR [Rule 7-33]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 6-43] (REF, SUB, EXT) </b>Within the schema, the
value of the required attribute schemaLocation carried by the element xsd:import MUST
be resolvable to a XML schema document file that is valid according to
<b>[XMLSchemaStructures]</b> and
<b>[XMLSchemaDatatypes]</b>. </body>
</html> atatypes]</b>. </body>
</html> l>
Constraint realized by PSM-MPD transformations.
English
NDR [Rule 6-43]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 3-7]</b> An IEPD exchange schema MUST NOT declare
any XML element that is not intended for use as an IEP root element.
</body> </html> ent. </body>
</html> l>
Non-computable constraint.
English
MPD [Rule 3-07]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 6-26] (REF, EXT)</b> Within the schema, if an
element declaration carries the attribute block, it MUST set the value for the
attribute to the empty string. </body> </html> y string.
</body> </html> l>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-26]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-46] (REF, EXT) </b>Within the
schema, an element SHALL have at most one instance of an element xsd:annotation as an
immediate child. </p> <p>
<b>Rationale</b> XML Schema allows annotations to be added
to components in a fairly loose manner: there may be multiple annotations, each of
which may have multiple documentation or appinfo elements. This flexibility in the
syntax provides no additional expressivity but does complicate processing, so it is
forbidden in NIEM. </p> </body> </html>
complicate processing, so it is forbidden in NIEM. </p>
</body> </html> </html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-46]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-58] (REF, SUB, EXT)</b>
Within the schema, a complex type SHALL NOT be defined such that an instance of that
type owns the attribute structures:ref. </p> <p>
<b>Rationale</b> The use of references is limited to
reference elements. This constrains the semantics and syntax of references within NIEM
instances. Only structures:ReferenceType may use structures:ref, which is the only
means for referencing within NIEM-conformant instances. </p>
</body> </html> for referencing within NIEM-conformant
instances. </p> </body> </html>
</html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 7-58]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-56] (REF, SUB, EXT)</b>
Within the schema, a complex type definition SHALL include the attribute
structures:sequenceID if the order of an occurrence of the type, within its parent,
relative to its siblings, is meaningful and pertinent and if the schema does not
specify the desired sequential order. </p> <p>
<b>Rationale</b> This rule indicates that, if order is
meaningful and the schema will not always represent the desired order, then data
modelers need to include sequenceID to allow the proper order to be represented in
instances. </p> </body> </html> to allow the
proper order to be represented in instances. </p> </body>
</html> body> </html>
(Constraint not enforced by this model).
English
NDR [Rule 7-56]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 7-32] (REF, EXT) </b>Within the schema, the
element appinfo:ReferenceTarget SHALL indicate a type definition schema component, by
namespace and name. </body> </html> and name.
</body> </html> l>
Constraint resolved by PSM-XSD transformations.
English
NDR [Rule 7-32]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 9-7] (REF, SUB, EXT)</b> The
name of any XML Schema component defined by the schema SHALL use the camel case
formatting convention. </p> <p>
<b>Rationale</b> The foregoing rules establish
lowerCamelCase for all NIEM components that are XML attributes and UpperCamelCase for
all NIEM components that are types, elements, or groups. </p>
</body> </html> that are types, elements, or groups.
</p> </body> </html> </html>
Non-computable constraint.
English
NDR [Rule 9-7]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-28] (REF, SUB, EXT)</b>
Within the schema, if the document element xsd:schema carries the attribute
blockDefault, it MUST set the value for the attribute to the empty string.
</p> <p> <b>Rationale</b>
Restriction of substitution options reduces capacity for reuse; thus, it is forbidden
within NIEM-conformant schemas In particular, setting the block value at the schema
level complicates understanding of component definitions. </p>
</body> </html> tes understanding of component
definitions. </p> </body> </html>
body> </html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-28]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-52] (REF, SUB, EXT)
</b>Within the schema, the element xsd:complexType MUST have as an
immediate child either the element xsd:complexContent or the element
xsd:simpleContent. </p> <p>
<b>Rationale</b> XML Schema provides shorthand to defining
complex content of a complex type, which is to define the complex type with immediate
children that specify elements, or other groups, and attributes. In the desire to
normalize schema representation of types and to be explicit, NIEM forbids the use of
that shorthand. </p> </body> </html> d to be
explicit, NIEM forbids the use of that shorthand. </p>
</body> </html> </html>
Constraint realized by PSM-XSD transformations.
English
NDR [Rule 6-52]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 7-2] (REF, SUB, EXT, CON)</b> Two XML Schema
documents SHALL have the same value for attribute targetNamespace carried by the
element xsd:schema, if and only if they represent the same set of components.
</body> </html> mponents. </body>
</html> l>
Not computable.
English
NDR [Rule 7-02]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-8] (REF, SUB, EXT)</b> The
schema SHALL NOT reference the type xsd:anySimpleType. </p>
<p> <b>Rationale</b> XML Schema provides a
restriction of the �ur-type,� which contains only simple content. This provides a
wildcard for arbitrary text. It is realized in XML Schema as xsd:anySimpleType.
NIEM-conformant schemas must not use xsd:anySimpleType because this feature is
insufficiently constrained to provide a meaningful starting point for content
definitions. Instead, content should be based on one of the more specifically defined
simple types defined by XML Schema. </p> </body>
</html> he more specifically defined simple types defined by XML Schema.
</p> </body> </html> </html>
Constraint is realized by PSM-XSD transformations.
English
NDR [Rule 6-08]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> An external URI for the file; indicates a same-as relationship to a
copy of the file. Implemented as the value of the externalURI attribute of the File
element in the catalog instance. </p> </body>
</html> alURI attribute of the File element in the catalog instance.
</p> </body> </html> he catalog instance.
</p> </body> </html>
externalURI
public
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> The relative path name to the file within the MPD directory
structure. Implemented as the value of the relativePathName attribute of the File
element in the catalog instance. </p> </body>
</html> ute of the File element in the catalog instance.
</p> </body> </html> catalog instance.
</p> </body> </html>
relativePathName
public
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> The nature (type) of the file. Implemented as the value of the
natureURI attribute of the File element in the catalog instance. </p>
</body> </html> ement in the catalog instance.
</p> </body> </html> e. </p>
</body> </html>
natureCode
public
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> The purpose for or function of the file. Implemented as the value of
the purposeURI attribute of the File element in the catalog instance.
</p> </body> </html> element in the catalog
instance. </p> </body> </html> tance.
</p> </body> </html>
purposeCode
public
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> A description of the file. Implemented as the value of the
descriptionText attribute of the File element in the catalog instance.
</p> </body> </html> element in the catalog
instance. </p> </body> </html> tance.
</p> </body> </html>
descriptionText
public
base_Usage
private
ModelPackageDescriptionFile
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> The possible reasons for the connectedness between the MPDs or between
an MPD and a resource. This enumeration defines the possible values for the
relationshipCode attribute of the ModelPackageDescriptionRelationship stereotype. [Note
these NIEM-UML enumeration literals differ from the NIEM MPD Specification v1.0 in that
they use underscore ("_") instead of dash ("-"). This is due to issues with dashes in
some UML tools.] Reference Section 4.2.5 and Appendix B of NIEM MPD Specification v1.0
(http://reference.niem.gov/niem/specification/model-package-description/1.0/).
</p> <p> </p> </body>
</html> ication/model-package-description/1.0/). </p>
<p> </p> </body> </html>
p> </body> </html>
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body> A
relationshipCode value for indicating that this MPD is an incremental update to the
resource referenced in resourceURI. Used by a core or domain update to identify the
domain schema in a NIEM release being incrementally updated (not replaced).
</body> </html> not replaced). </body>
</html> l>
updates
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body> A
relationshipCode value for indicating that this MPD conforms to the specification or
standard referenced in resourceURI. </body> </html> URI.
</body> </html> l>
conforms_to
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body> A
relationshipCode value for indicating that this MPD is a different version of the MPD
referenced in resourceURI. This code value is only needed in cases where significant
name changes might obscure the relationship to the previous version. For example, NIEM
Justice 4.1 is a version of GJXDM 3.0.3. </body> </html>
ion of GJXDM 3.0.3. </body> </html> l>
version_of
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body> A
relationshipCode value for indicating that this MPD is a specialization of the MPD
referenced in resourceURI. This value is the inverse of generalizes.
</body> </html> eralizes. </body>
</html> l>
specializes
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body> A
relationshipCode value for indicating that this MPD is a generalization of the MPD
referenced in resourceURI. This value is the inverse of specializes.
</body> </html> cializes. </body>
</html> l>
generalizes
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body> A
relationshipCode value for indicating that this MPD replaces the MPD referenced in
resourceURI. </body> </html> URI. </body>
</html> l>
supersedes
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body> A
relationshipCode value for indicating that content in this MPD is preferred over
content in the MPD referenced in resourceURI; and at some time in the future will
supersede the MPD referenced in resourceURI </body>
</html> sourceURI </body> </html> l>
deprecates
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body> A
relationshipCode value for indicating that this MPD is an adaptation of the MPD
referenced in resourceURI. </body> </html> URI.
</body> </html> l>
adapts
RelationshipCode
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> An indication of the type of an MPD artifact. This further indicates
how it should be processed by software tools. </p> <p> The
literals of this enumeration correspond to MPD nature URIs of the form
"http://reference.niem.gov/niem/resource/mpd/lexicon/1.0/purpose#<purpose-code>".
</p> <p> [Note these NIEM-UML enumeration literals differ
from the NIEM MPD Specification v1.0 in that they use underscore ("_") instead of dash
("-"). This is due to issues with dashes in some UML tools.] Reference Section 4.2.4 and
Appendix G of NIEM MPD Specification v1.0
(http://reference.niem.gov/niem/specification/model-package-description/1.0/).
</p> <p> </p> </body>
</html> nce.niem.gov/niem/specification/model-package-description/1.0/).
</p> <p> </p> </body>
</html> p> </body> </html>
extension_schema_set
reference_schema_set
subset_schema_set
file
business_rules
catalog
documentation
administrative
endorsement
memorandum
report
conformance_report
quality_assurance_report
test_report
technical_reference
non-normative_reference
normative_reference
metadata_extended
sample_instance
schema
constraint_schema
exchange_schema
extension_schema
incremental_schema
reference_schema
replacement_schema
subset_schema
tool_specific_file
wantlist
file_set
schema_set
constraint_schema_set
exchange_schema_set
PurposeCode
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> The ModelPackageDescriptionRelationship stereotype applies to a
Dependency that represents a relationship between MPDs or between an MPD and another
resource (such as a NIEM specification; as in the case of conforms-to). There are many
ways one MPD may relate to another. This makes it extremely difficult to specify a fixed
set of values that could objectively define an exact relationship between a pair of
MPDs. Therefore, the optional descriptionText attribute is provided to further explain
the nature of any of the eight relationshipCode values available (version_of,
specializes, generalizes, deprecates, supersedes, adapts, conforms_to, updates). In some
cases, the value of relationshipCode may be generic enough to require a more detailed
explanation in descriptionText (for example, if the value is "adapts").
</p> </body> </html> in descriptionText (for
example, if the value is "adapts"). </p> </body>
</html> /body> </html>
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> A more detailed or specific textual explanation of the relationship
between the MPDs or between an MPD and a resource (such as a specification).
</p> <p> The catalog provides a Relationship element with
three attributes (resourceURI, relationshipCode, and descriptionText) to identify the
pedigree of an MPD. There are many ways that one MPD may relate to another. This makes
it extremely difficult to specify a fixed set of values that could objectively define
an exact relationship between a pair of MPDs. Therefore, the optional descriptionText
attribute is provided to further explain the nature of any of the eight
relationshipCode values available (version_of, specializes, generalizes, deprecates,
supersedes, adapts, conforms_to, updates). In some cases, the value of
relationshipCode may be generic enough to require a more detailed explanation in
descriptionText (for example, if the value is "adapts"). </p>
</body> </html> optional descriptionText attribute is
provided to further explain the nature of any of the eight relationshipCode values
available (version_of, specializes, generalizes, deprecates, supersedes, adapts,
conforms_to, updates). In some cases, the value of relationshipCode may be generic
enough to require a more detailed explanation in descriptionText (for example, if the
value is "adapts"). </p> </body> </html> the
value of relationshipCode may be generic enough to require a more detailed explanation
in descriptionText (for example, if the value is "adapts"). </p>
</body> </html>
descriptionText
public
composite
base_Dependency
private
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body> A
classification or reason for the connectedness between the MPDs or between an MPD and
a resource. </body> </html> a resource.
</body> </html> > </html>
relationshipCode
public
composite
ModelPackageDescriptionRelationship
extension_
private
composite
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> A ModelPackageDescription Component represents a NIEM Model Package
Description (MPD). Specifically, it represents the information in an MPD catalog.
Reference NIEM MPD Specification v1.0
(http://reference.niem.gov/niem/specification/model-package-description/1.0/)
<br>An MPD is a logical set of electronic files aggregated and organized
to fulfill a specific purpose in NIEM. Directory organization and packaging of an MPD
should be designed around major themes in NIEM: reuse, sharing, interoperability, and
efficiency. The inclusion of artifacts in an MPD is modeled using a Usage dependency
from the Component representing the MPD to the model element representing the artifact
(most commonly a Namespace Package). <br> </p>
</body> </html> senting the artifact (most commonly a
Namespace Package). <br> </p> </body>
</html> </body> </html>
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 4-5] </b>The URI for an MPD
MUST end in its version number. </p> <p>
</p> <p> The tag value for mpdURI is derived and computed
from the version number. </p> </body>
</html> mputed from the version number. </p>
</body> </html> </html>
derive: self.mpdBaseURI.repr().concat(self.mpdVersionID.repr()).oclAsType(AnyURI)
OCL2.0
MPD [Rule 4-05]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 4-4]</b> Every MPD MUST be assigned a valid http
URI. </body> </html> </body>
</html> l>
self.mpdBaseURI.repr().startsWith('http:/')
OCL2.0
MPD [Rule 4-04]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 4-14]</b> An IEPD or an EIEM MUST contain a
master document located in the MPD root directory whose filename begins with the
substring "master-document". </body> </html> nt".
</body> </html> l>
Constraints on master document are resolved during PSM-MPD transformation.
English
MPD [Rule 4-14]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 4-1] </b>An MPD MUST contain an XML catalog
artifact that validates with the NIEM MPD catalog schema (XSD) and that resides in the
root directory of the MPD and bears the file name "catalog.xml". </body>
</html> ml". </body> </html> l>
Constraint is resolved via PSM-MPD transformations which produce the catalog as
specified by the MPD.
English
MPD [Rule 4-01]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 4-12] </b>Every MPD that is an
IEPD or EIEM MUST contain a change log artifact that: </p>
<p> � Records changes to previous IEPD or EIEM schemas that this MPD
represents. </p> <p> � Begins with the substring
"changelog". </p> <p> � Resides in the root directory of
the MPD. </p> </body> </html>
<p> � Resides in the root directory of the MPD. </p>
</body> </html> </body>
</html>
Constraints on changelogs are resolved by PSM-MPD transformations.
English
MPD [Rule 4-12]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 6-9]</b> Within any artifact of an MPD archive,
any direct reference to another resource (i.e., another artifact such as an image,
schema, stylesheet, etc.) that is required to process or display an artifact SHOULD
exist within the archive at the location specified by that reference.
</body> </html> hat reference. </body>
</html> </html>
Packaging constraints are resolved by PSM-MPD transformations.
English
MPD [Rule 6-9]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 6-5]</b> Absolute references to Internet
resources MUST use a well-known transfer protocol (http, https, ftp, ftps) and MUST
resolve (If applicable, documentation that describes how to resolve with security,
account, and/or password issues MUST be included). </body>
</html> be included). </body> </html>
ml>
Constraints on URIs are partially satisfied by specific URI Constraints expressed
elsewhere in the NDR and MPD. For URI references embedded elsewhere in the model, it
would be difficult to express the constraint in OCL. This constraint must be manually
resolved by the modeler.
English
MPD [Rule 6-5]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-3a]</b> An MPD archive file
MUST use file name syntax defined by the regular expression: </p>
<p> mpd-filename ::= name '-' version '.' class '.zip'
</p> <p> Where: </p> <p
style="margin-left:10.0px;"> name ::= alphanum ((alphanum | special)*
alphanum)? </p> <p style="margin-left:10.0px;"> alphanum
::= [a-zA-Z0-9] </p> <p style="margin-left:10.0px;">
special ::= '.' | '-' | '_' </p> <p
style="margin-left:10.0px;"> version ::= digit+ ('.' digit+)* (status digit+)?
</p> <p style="margin-left:10.0px;"> digit ::= [0-9]
</p> <p style="margin-left:10.0px;"> status ::= 'alpha' |
'beta' | 'rc' | 'rev' </p> <p style="margin-left:10.0px;">
class ::= 'rel' | 'cu' | 'du' | 'iepd' | 'eiem' </p> <p
style="margin-left:0.0px;"> All alpha characters SHOULD be lower case to reduce
the risk of complications across various file systems. See [<a
href="mdel://_17_0_3_24a0131_1321168952839_661693_1978">Rule
4-3</a>] for an explanation of the status options. </p>
<p style="margin-left:0.0px;"> (The regular expression notation used
above is from XML 1.0 (Fifth Edition): <a
href="http://www.w3.org/TR/2008/REC-xml-20081126/#sec-notation">http://www.w3.org/TR/2008/REC-xml-20081126/#sec-notation</a>)
</p> </body> </html> sion notation used
above is from XML 1.0 (Fifth Edition): <a
href="http://www.w3.org/TR/2008/REC-xml-20081126/#sec-notation">http://www.w3.org/TR/2008/REC-xml-20081126/#sec-notation</a>)
</p> </body> </html> body>
</html>
Packaging constraints are resolved by PSM-MPD transformations.
English
MPD [Rule 6-3a]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 4-13.1]</b> If an IEPD or EIEM
contains more than one change log artifact, then each change log artifact MUST:
</p> <p> � Have a file name that begins with the substring
"changelog". </p> <p> � Reside in the MPD root directory .
</p> </body> </html> � Reside in the MPD
root directory . </p> </body> </html>
</html>
Constraints on changelogs are resolved by PSM-MPD transformations.
English
MPD [Rule 4-13.1]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 4-11] </b>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: </p> <p> �
Validates with the NIEM change log schemas (mpd-changelog.xsd and 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. </p>
<p> � Records changes to previous reference schemas that this MPD
represents. </p> <p> � Bears the file name
"changelog.xml". </p> <p> � Resides in the root directory
of the MPD. </p> </body> </html>
"changelog.xml". </p> <p> � Resides in the root directory
of the MPD. </p> </body> </html> /p>
</body> </html>
Constraints on changelog are resolved during PSM-MPD transformations.
English
MPD [Rule 4-11]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 3-6] </b>An IEPD MUST contain at least one
exchange schema artifact that declares at least one top-level root element for IEP
instances specified by the IEPD. </body> </html> the IEPD.
</body> </html> l>
( self.base_Component.profiledBy('NIEM_PSM_Profile') and
(self.mpdClassCode=ModelPackageDescriptionClassCode::iepd) ) implies
self.base_Component.elementImport ->exists(elementImport|
elementImport.stereotypedBy('ModelPackageDescriptionFile') and (
elementImport.getStereotypeApplication('ModelPackageDescriptionFile').purposeURI=
'http://reference.niem.gov/niem/resource/mpd/lexicon/1.0/purpose#exchange-schema' )
and elementImport.importElement.oclAsType(Package).packagedElement
->exists(e|e.stereotypedBy('PropertyHolder') and
e.oclAsType(Class).ownedAttribute->notEmpty()) )
OCL2.0
MPD [Rule 3-06]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 4-15]</b> A NIEM IEPD or EIEM master document
SHOULD (at a minimum) describe the MPD purpose, scope, business value, exchange
information, senders/receivers, interactions, and references to other documentation.
</body> </html> documentation. </body>
</html> l>
Constraints on master document are resolved by PSM-MPD transformations.
English
MPD [Rule 4-15]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-3c]</b> Within an MPD,the
<class> substring in the file name MUST correctly correspond to the
value for the attribute mpdClassCode within catalog.xml. Correct correspondence is:
</p> <table cellpadding="0" cellspacing="0" width="100%">
<tr> <td> IF file name <class>=
</td> <td> THEN catalog.xml mpdClassCode =
</td> </tr> <tr> <td> rel
</td> <td> release </td>
</tr> <tr> <td> cu </td>
<td> core-update </td> </tr>
<tr> <td> du </td> <td>
domain-update </td> </tr> <tr>
<td> iepd </td> <td> iepd
</td> </tr> <tr> <td> eiem
</td> <td> eiem </td> </tr>
</table> </body> </html> cu
</td> <td> core-update </td>
</tr> <tr> <td> du </td>
<td> domain-update </td> </tr>
<tr> <td> iepd </td> <td>
iepd </td> </tr> <tr> <td>
eiem </td> <td> eiem </td>
</tr> </table> </body> </html>
</td> </tr> <tr> <td> iepd
</td> <td> iepd </td> </tr>
<tr> <td> eiem </td> <td>
eiem </td> </tr> </table>
</body> </html>
Packaging constraints are resolved by PSM-MPD transformations.
English
MPD [Rule 6-3c]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 4-3]</b> All NIEM version
numbers adhere to the regular expression: </p> <p> version
::= digit+ ('.' digit+)* (status digit+)? </p> <p> Where:
</p> <p> digit ::= [0-9] </p>
<p> status ::= 'alpha' | 'beta' | 'rc' | 'rev' </p>
<p> 'alpha' indicates early development </p>
<p> 'beta' indicates late development; but changing or incomplete
</p> <p> 'rc' indicates release candidate; complete but
not approved as operational </p> <p> 'rev' indicates very
minor revision that does not impact schema validation </p>
<p> (The regular expression notation used above is from XML 1.0 (Fifth
Edition): <a
href="http://www.w3.org/TR/2008/REC-xml-20081126/#sec-notation">http://www.w3.org/TR/2008/REC-xml-20081126/#sec-notation</a>)
</p> </body> </html> om XML 1.0 (Fifth
Edition): <a
href="http://www.w3.org/TR/2008/REC-xml-20081126/#sec-notation">http://www.w3.org/TR/2008/REC-xml-20081126/#sec-notation</a>)
</p> </body> </html> body>
</html>
self.mpdVersionID.match('[0-9]+(\\.[0-9]+)*((alpha|beta|rc|rev)[0-9]+)?')
OCL2.0
MPD [Rule 4-03]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 6-1] </b>An MPD is packaged as a single
compressed archive of files that represents a sub-tree of a file system in
standard<b> [PK-ZIP]</b> format. This archive MUST
preserve and store the logical directory structure intended by its author.
</body> </html> by its author. </body>
</html> l>
Constraints on packaging are resolved during PSM-MPD transformation.
English
MPD [Rule 6-1]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 3-9]</b> A NIEM-conforming IEPD or EIEM MUST
contain at least one schema that is either a NIEM reference schema or a subset derived
from a NIEM reference schema. </body> </html> e schema.
</body> </html> l>
( self.base_Component.profiledBy('NIEM_PSM_Profile') and (
(self.mpdClassCode=ModelPackageDescriptionClassCode::iepd) or
(self.mpdClassCode=ModelPackageDescriptionClassCode::eiem) ) ) implies
self.base_Component.elementImport
->select(elementImport|elementImport.stereotypedBy('ModelPackageDescriptionFile')).getStereotypeApplication('ModelPackageDescriptionFile').purposeURI
->exists(purposeURI|
(purposeURI='http://reference.niem.gov/niem/resource/mpd/lexicon/1.0/purpose#subset-schema')
or
(purposeURI='http://reference.niem.gov/niem/resource/mpd/lexicon/1.0/purpose#reference-schema')
)
OCL2.0
MPD [Rule 3-09]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 4-9]</b> A URI reference to an
individual MPD artifact from another resource is the concatenation of
</p> <p> � The URI of the MPD that contains the artifact.
</p> <p> � The crosshatch or pound character ("#").
</p> <p> � A fragment identifier that is the locally
unique id of the artifact within the catalog of the MPD itself. </p>
</body> </html> f the artifact within the catalog of the
MPD itself. </p> </body> </html>
body> </html>
Explicit URI references are not modelled for well known artifacts such as schemas.
Serialization of MPD artifacts such as schemas are via PSM-MPD transformations which
construct URI references according to this MPD rule.
English
MPD [Rule 4-09]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 4-7] </b>Each file set artifact in an MPD MUST
have a corresponding FileSet element in the catalog for that MPD. This FileSet element
must identify each file artifact that is a member of that file set artifact.
</body> </html> artifact. </body>
</html> </html>
Constraints for catalog construction are resolved in PSM-MPD transformations.
English
MPD [Rule 4-07]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 6-6] </b>A published IEPD MUST contain all
documents necessary to understand it and allow it to be implemented correctly.
</body> </html> tly. </body>
</html> l>
This constraint is resolved by PSM-MPD transformations.
English
MPD [Rule 6-6]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 3-10]</b> A NIEM IEPD MUST contain at least one
valid sample XML instance (i.e., IEP) artifact for each exchange schema element that
can be the root of a corresponding IEP. </body> </html>
ding IEP. </body> </html> l>
This constraint is realized by PSM-MPD transformations.
English
MPD [Rule 3-10]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 4-10] </b>NIEM namespaces MUST NOT be used as
URIs for MPD artifacts. </body> </html> cts.
</body> </html> l>
Constraints on artifact URIs are resolved during PSM-MPD transformations.
English
MPD [Rule 4-10]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 6-3] </b>An MPD archive MUST uncompress (unzip)
to a one and only one MPD root directory. </body> </html>
ory. </body> </html> l>
Packaging constraints are resolved by PSM-MPD transformations.
English
MPD [Rule 6-3]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 6-2]</b> Within an MPD archive, all XSD and XML
artifacts MUST be valid against and follow all rules for their respective
<b>[NIEM-NDR]</b> conformance targets (i.e., subset,
constraint, extension, exchange, reference schemas, and XML instances); this includes
being well-formed and valid XML Schema documents. </body>
</html> L Schema documents. </body> </html>
l>
This constraint is resolved by a combination of applying all specified NDR-based
constraints and transformations to target artifacts.
English
MPD [Rule 6-2]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-3d]</b> When represented on
the Internet, an MPD archive SHOULD use the following MIME Type: </p>
<p> application/zip+<class> </p>
<p> where </p> <p
style="margin-left:10.0px;"> <class> is one member from the set
{rel, cu, du, iepd, eiem} </p> <p
style="margin-left:0.0px;"> Use of the generic zip MIME type application/zip is
allowed, but discouraged. No other MIME types are allowed when representing MPD
archives. </p> </body> </html> scouraged. No
other MIME types are allowed when representing MPD archives. </p>
</body> </html> body> </html>
Packaging constraints are resolved by transformations.
English
MPD [Rule 6-3d]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 4-2] </b>Every MPD MUST be assigned a version
number. </body> </html> </body>
</html> l>
not(self.mpdVersionID.oclIsUndefined()) and (self.mpdVersionID<>'')
-- This constraint also satisfied by tag mpdVersionID, which is required to have a
value.
OCL2.0
MPD [Rule 4-02]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 6-3b]</b> Within an MPD,the<name>
and <version> substrings in the file name MUST match exactly the values
for attributes mpdName and mpdVersionID within its catalog.xml artifact.
</body> </html> artifact. </body>
</html> l>
Packaging constraints are resolved by PSM-MPD transformations.
English
MPD [Rule 6-3b]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 4-8] </b>Each artifact identified in the catalog
MUST be assigned an id in the format of an NCName (Non-Colonized Name) as defined by
[W3-XML-Namespaces]. This is required for both File and FileSet artifacts.
</body> </html> rtifacts. </body>
</html> l>
All catalog constraints are resolved in PSM-MPD transformation.
English
MPD [Rule 4-08]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 4-13]</b> The initial version of an IEPD or EIEM
MUST contain a change log artifact with at least one entry for its creation date.
</body> </html> ate. </body>
</html> l>
Constraints on changelogs are resolved during PSM-MPD transformation.
English
MPD [Rule 4-13]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 4-3.1] </b>A higher MPD version number within a
version series does NOT imply compatibility between versions. Compatibility between or
among MPD versions MUST be explicitly stated in documentation. </body>
</html> entation. </body> </html> l>
Satisfaction of this constraint requires comparative analysis between versions;
can not be expressed easily in OCL.
English
MPD [Rule 4-03.1]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 6-7]</b> A published IEPD MUST link (through its
catalog) to any EIEM it is based on. </body> </html> on.
</body> </html> ml>
An EIEM is an MPD with a packageCode of EIEM. An EIEM is typically bundled as a
reusable model library which can be referenced from IEPDs. This relationship between
EIEM and IEPD is used by PSM-MPD transformations to construct the catalog entries in
resolution of this constraint.
English
MPD [Rule 6-7]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 4-6] </b>Each file artifact in an MPD MUST have a
corresponding File element in the catalog for that MPD. </body>
</html> MPD. </body> </html> l>
Constraints for catalog construction are resolved in PSM-MPD transformation.
English
MPD [Rule 4-06]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 6-4]</b> Within an MPD archive, the value of each
xsd:import schemaLocation attribute MUST be a relative path reference that resolves to
the correct schema within the sub-tree. </body> </html>
sub-tree. </body> </html> l>
Packaging constraints are resolved by PSM-MPD transformations.
English
MPD [Rule 6-4]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 6-8]</b> Within an MPD archive, if
non-NIEM-conforming schemas from other standards are used and referenced within an
MPD, then all xsd:import, xsd:include, and xsd:redefine constructs used within those
schemas MUST be modified as needed to have a value for the schemaLocation attribute
that is a relative path reference that resolves to the correct schema within the
sub-tree. </body> </html> ema within the sub-tree.
</body> </html> l>
The schemaLocation constraints are resolved during PSM-MPD transformation.
English
MPD [Rule 6-8]
base_Component
private
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body> Many
published MPDs will be periodically revised and updated; therefore, versioning is
required to clearly indicate that changes have occurred. A version number is actually
part of the unique identification for an MPD (to be discussed in a subsequent
section). All NIEM version numbers adhere to the regular expression:
[0-9]+(\.[0-9]+)*((alpha|beta|rc|rev)[0-9]+)? Where: <ul>
<li> "alpha" indicates early development </li>
<li> "beta" indicates late development; but changing or incomplete
</li> <li> "rc" indicates release candidate; complete but
not approved as operational </li> <li> "rev" indicates
very minor revision that does not impact schema validation </li>
</ul> </body> </html> ional
</li> <li> "rev" indicates very minor revision that does
not impact schema validation </li> </ul>
</body> </html> n </li> </ul>
</body> </html>
mpdVersionID
public
composite
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> The left hand substring of an MPD URI that does not include its
mpdVersionID. The concatenation of mpdBaseURI and mpdVersionID becomes the value of
the mpdURI attribute of the Catalog element in the catalog instance.
</p> <p> </p> </body>
</html> ance. </p> <p> </p>
</body> </html> p> </body>
</html>
mpdBaseURI
public
composite
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> The classification code of the MPD. Implemented as the value of the
mpdClassCode attribute of the Catalog element in the catalog instance. This code
designates the classification or kind of the MPD. </p>
</body> </html> This code designates the classification or
kind of the MPD. </p> </body> </html> kind
of the MPD. </p> </body> </html>
mpdClassCode
public
composite
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> A description of the MPD. A statement that provides an explanation
or additional detail. </p> <p> Implemented as the value of
the descriptionText attribute of the Catalog element in the catalog instance.
</p> </body> </html> element in the catalog
instance. </p> </body> </html> ce.
</p> </body> </html>
descriptionText
public
composite
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body> A label
that defines how this MPD must be handled or can be distributed to protect the
information it contains; the security marking for the MPD. Implemented as the value of
the SecurityMarkingText element in the catalog instance. Default is "unclassified".
</body> </html> t element in the catalog instance. Default
is "unclassified". </body> </html> "unclassified".
</body> </html>
SecurityMarkingText
public
composite
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body> Date
this MPD was published or created. Implemented as the value of the CreationDate
element in the catalog instance. </body> </html> catalog
instance. </body> </html> </html>
CreationDate
public
composite
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> Date the MPD was last revised. Implemented as the value of the
LastRevisionDate element in the catalog instance. </p>
</body> </html> the catalog instance. </p>
</body> </html> /p> </body>
</html>
LastRevsionDate
public
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> An estimate of the projected date the MPD is expected to be revised
again (if known). Implemented as the value of the NextRevisionDate element in the
catalog instance. </p> </body> </html> the
NextRevisionDate element in the catalog instance. </p>
</body> </html> instance. </p>
</body> </html>
NextRevisionDate
public
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
Description of the current state of development or usage of the MPD; may also project
future plans for the MPD. Implemented as the value of the StatusText element in the
catalog instance. </body> </html> the StatusText element
in the catalog instance. </body> </html> instance.
</body> </html>
StatusText
public
composite
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body> A
keyword associated with the MPD; a common alias, term, or phrase that would help to
facilitate search and discovery of this MPD. Implemented as the value of the
KeywordText element in the catalog instance. </body>
</html> lue of the KeywordText element in the catalog instance.
</body> </html> g instance. </body>
</html>
*
KeywordText
public
composite
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body> A NIEM
Domain applicable to, associated with, or that uses the MPD. Implemented as the value
of the DomainText element in the catalog instance. </body>
</html> lement in the catalog instance. </body>
</html> </body> </html>
*
DomainText
public
composite
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body> A
description for the purpose, function, intended use of, or reason for the existence of
the MPD. Implemented as the value of the PurposeText element in the catalog instance.
</body> </html> PurposeText element in the catalog
instance. </body> </html> tance. </body>
</html>
*
PurposeText
public
composite
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body> A
description of a transactional, design, or exchange pattern the MPD uses (generally,
applicable to IEPDs only). Implemented as the value of the ExchangePatternText element
in the catalog instance. </body> </html> atternText
element in the catalog instance. </body> </html> ce.
</body> </html>
*
ExchangePatternText
public
composite
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body> Name of
an agency, organization, or entity that uses the MPD (in particular to share or
exchange data). Implemented as the value of the ExchangePartnerName element in the
catalog instance. </body> </html> xchangePartnerName
element in the catalog instance. </body> </html> ce.
</body> </html>
*
ExchangePartnerName
public
composite
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body> A name
for the authoritative source for the MPD; can be author, creator, sponsor, etc.
(person, organization, or entity). Implemented as the value of the ASName element in
the catalog instance. </body> </html> the ASName element
in the catalog instance. </body> </html> instance.
</body> </html>
ASName
public
composite
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body> An
address or description for the location of the authoritative source for the MPD.
Implemented as the value of the ASAddressText element in the catalog instance.
</body> </html> xt element in the catalog instance.
</body> </html> ce. </body>
</html>
ASAddressText
public
composite
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body> A URL
for the Web site of the authoritative source for the MPD. Implemented as the value of
the ASWebSiteURL element in the catalog instance. </body>
</html> lement in the catalog instance. </body>
</html> </body> </html>
ASWebSiteURL
public
composite
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body> A point
of contact (POC) for the authoritative source for the MPD; metadata used to contact
the authoritative source. Implemented as a POCType with values for name, email, and
telephone in the catalog instance. </body> </html> for
name, email, and telephone in the catalog instance. </body>
</html> g instance. </body> </html>
*
POC
public
composite
ModelPackageDescription
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> An indication of the type of an MPD artifact. This further indicates
how it should be processed by software tools. The literals of this enumeration
correspond to MPD nature URIs of the form
"http://reference.niem.gov/niem/resource/mpd/lexicon/1.0/nature#<nature-code>".
</p> <p> [Note these NIEM-UML enumeration literals differ
from the NIEM MPD Specification v1.0 in that they use underscore ("_") instead of dash
("-"). This is due to issues with dashes in some UML tools.] Reference Section 4.2.5 and
Appendix G of NIEM MPD Specification v1.0
(http://reference.niem.gov/niem/specification/model-package-description/1.0/).
</p> <p> </p> </body>
</html> m/specification/model-package-description/1.0/).
</p> <p> </p> </body>
</html> p> </body> </html>
mpd
domain_update
iepd
release
binary
doc
image
gif
jpg
png
mdb
pdf
ppt
svg
vsd
xls
zip
character
csv
html
text
xml
catalog
changelog
owl
rdf
schematron
wantlist
wsdl
xhtml
xmi
xsd
xslt
file_set
NatureCode
extension_ModelPackageDescriptionFileSet
private
composite
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body> A
specified classification (type or kind) of the MPD. Implemented as the value of the
mpdClassCode attribute of the Catalog element in the catalog instance. One and only one
classification is allowed for any given MPD. <p> [Note these NIEM-UML
enumeration literals differ from the NIEM MPD Specification v1.0 in that they use
underscore ("_") instead of dash ("-"). This is due to issues with dashes in some UML
tools.] Reference Section 4.2.5 and Appendix B of NIEM MPD Specification v1.0
(http://reference.niem.gov/niem/specification/model-package-description/1.0/).
</p> </body> </html>
cification/model-package-description/1.0/). </p> </body>
</html> </html>
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body> An
Enterprise Information Exchange Model (EIEM) is an MPD that incorporates BIECs that
meet enterprise business needs for exchanging data using NIEM [NIEM-BIEC]. An EIEM is
an adaptation of NIEM schemas, tailored and constrained for and by an enterprise. An
EIEM will contain the following schemas that are commonly used or expected to be used
by the authoring enterprise: one standard NIEM schema subset and one or more NIEM
extension schemas that extend existing NIEM data components or establish new data
components. <br> </body> </html> ish new
data components. <br> </body> </html>
y> </html>
eiem
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> NIEM Information Exchange Package Documentation (IEPD) is an MPD
that defines a recurring XML data exchange. An NIEM IEPD is a set of valid XML schemas
that may include portions of NIEM Core schemas, portions of NIEM Domain schemas,
enterprise-specific or IEPD-specific extension schemas, and at least one exchange
schema that defines a document element (as defined in [W3-XML-InfoSet]). The schemas
contained in an IEPD work together to define a class of XML instances that
consistently encapsulate data for information exchanges. Each XML instance in this
class validates against the set of XML schemas contained within the IEPD.
</p> </body> </html> gainst the set of XML
schemas contained within the IEPD. </p> </body>
</html> </html>
iepd
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> When necessary, the NIEM PMO can publish a core update. This is
essentially identical to a domain update in terms of structure and use, with two
important exceptions. First, a core update records changes that apply to a particular
NIEM core version or another core update. This also means it is applicable to all NIEM
releases using that same core version. Second, a core update is never published to
replace a NIEM core. It is intended to add new schemas, new data components, new code
values, etc. to a core without waiting for the next major release. In some cases,
minor modifications to existing data components are possible. </p>
</body> </html> modifications to existing data components
are possible. </p> </body> </html>
</html>
core_update
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body> A NIEM
release is an MPD containing a full set of harmonized reference schemas that
coherently define all content within a single version of NIEM. NIEM releases include
major, minor, and micro releases (as defined in the NIEM High Level Version
Architecture (HLVA)). <br> </body> </html>
tecture (HLVA)). <br> </body> </html>
/html>
release
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> A domain update is an MPD containing reference schemas that
represent changes to NIEM domains. The [NIEM-HLVA] defines a domain update as both a
process and a NIEM product. Through use and analysis of NIEM releases and published
content, domain users will identify issues and new data requirements for the domain
and sometimes Core. NIEM domains use these issues as the basis for incremental
improvements, extensions, and proposed changes to future NIEM releases. Both the
process and product of the process are referred to as domain update.
</p> </body> </html> of the process are
referred to as domain update. </p> </body>
</html> </html>
domain_update
ModelPackageDescriptionClassCode
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> A ModelPackageDescriptionFileSet Component represents a set of files
in an MPD that are grouped for a specific purpose, function, or classification. For
example, a set of MPD files might represent a schema subset, extension schema set, set
of documentation, or set of test files. The MPD catalog uses the File element to
represent artifacts, and the FileSet element to represent a set of artifacts. Note that
both files and file sets are considered MPD artifacts. Reference Sections 4.2.3 and
4.2.4 of NIEM MPD Specification v1.0
(http://reference.niem.gov/niem/specification/model-package-description/1.0/).
</p> </body> </html>
.gov/niem/specification/model-package-description/1.0/). </p>
</body> </html> </html>
self.base_Package.namespace.stereotypedBy('ModelPackageDescription')
OCL2.0
unnamed1
The external URI for the file set; indicates a same-as relationship to a copy of
the file set. Implemented as the value of the externalURI attribute of the FileSet
element in the catalog instance.
externalURI
public
The nature (type) of the file set. Implemented as the value of the natureURI
attribute of the FileSet element in the catalog instance.
natureCode
public
The purpose or function of the file set. Implemented as the value of the
purposeURI attribute of the FileSet element in the catalog instance.
purposeCode
public
A description of the file set. Implemented as the value of the descriptionText
attribute of the FileSet element in the catalog instance.
descriptionText
public
base_Component
private
ModelPackageDescriptionFileSet
extension_ModelPackageDescriptionFile
private
composite
Model_Package_Description_Profile
http://www.omg.org/spec/NIEM-UML/20120501/Model_Package_Description_Profile
The NIEM PSM Profile comprises stereotypes that are used in NIEM PSMs. These
stereotypes need not be used with a NIEM PIM, but they may be in order to provide
additional platform-specific markup.Further, the NIEM PIM Profile imports the NIEM Common
Profile and, therefore, includes all the stereotypes and metaclasses covered by that
profile.
extension_RepresentationRestriction
private
composite
XSDRepresentationRestriction specifies a restriction on the representation in an XML
schema of the values of a base DataType.
A DataType with an XSDRepresentationRestriction must have exactly one
generalization.
self.base_DataType.generalization->notEmpty()
OCL2.0
must have one generalization
whiteSpace is a restriction on the value space of the DataType. It is implemented
in XML Schema as the value of the value attribute on the xsd:whiteSpace element, the
child of the xsd:restriction element which is the immediate child of the
xsd:simpleType element.
whiteSpace
public
base_DataType
private
XSDRepresentationRestriction
XSDPropertyKindCode supports the kind attribute of XSDProperty by providing values
to specify if an XSD property is represented as an xsd:element or xsd:attribute.
element
attribute
XSDPropertyKindCode
extension_XSDStructureId
private
composite
An XSDProperty Property represents a NIEM property, which is implemented in XML
Schema as either an attribute declaration and use or an element declaration and
particle. If an XSDProperty Property is the client of a References Realization, then the
supplier of the Realization defines the declaration of the NIEM property. Otherwise, the
declaration of the NIEM property is defined implicitly to be the top-level attribute or
element definition of the same name within the target namespace of the Namespace Package
that contains the XSDProperty Property. All NIEM properties represented by XSDProperty
Properties with the same name within the same package that are not clients of References
Realizations share the same implicit attribute or element declaration.
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 9-5] (REF, SUB, EXT)</b> Within the schema, any
attribute declaration SHALL have a name that begins with a lower-case letter
('a'-'z'). </body> </html> 'a'-'z'). </body>
</html> l>
(self.kind=XSDPropertyKindCode::attribute) implies
self.base_Property.name.firstToUpper()<>self.base_Property.name
OCL2.0
NDR [Rule 9-5]
If kind=attribute, then an XSDProperty must have multiplicity 1..1, must not be a
derived union and must not subset any other property. If the type is not empty, it
must be a DataType.
( (self.kind=XSDPropertyKindCode::element) implies( (self.base_Property.upper=1)
and (self.base_Property.lower=1) and not (self.base_Property.isDerivedUnion) and
self.base_Property.subsettedProperty->isEmpty() ) ) and(
not(self.base_Property.type.oclIsUndefined()) implies
self.base_Property.type.oclIsKindOf(DataType) )
OCL2.0
XSDPropertyAttributeKind
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-14] (REF, EXT)</b> A
component definition SHALL begin with a standard opening phrase that depends on the
class of the component per Table 7-1 in NDR: Standard Opening Phrases:
</p> <p> <b>Rationale</b> A
standard opening phrase based on component class helps to ensure consistent
definitions that appropriate for the type of component item being defined. These
opening phrases also provide a cue that facilitates recognition of the particular kind
of component. </p> </body> </html> s
recognition of the particular kind of component. </p>
</body> </html> </html>
self.base_Property.ownedComment ->exists(documentation|
documentation.stereotypedBy('Documentation') and
(self.base_Property.type.oclIsUndefined() implies documentation.body.startsWith('A
data concept for a ')) and (self.base_Property.type.stereotypedBy('AssociationType')
implies documentation.body.startsWith('A relationship ')) and
(self.base_Property.type.stereotypedBy('AugmentationType') implies
documentation.body.startsWith('Supplements ')) and
(self.base_Property.type.stereotypedBy('MetadataType') implies
(documentation.body.startsWith('Metadata about ') or
documentation.body.startsWith('Information that further qualifies ')) and
(self.base_Property.name.match('.*Date.*') implies documentation.body.startsWith('A
date ')) and (self.base_Property.name.match('.*Quantity.*') implies
documentation.body.match('A .*count/number of ')) -- Element with an image
representation term "A(n) (optional adjective) image/picture/photograph of..." and
(self.base_Property.name.match('.*Indicator.*') implies documentation.body.match('True
if .*; false otherwise.*')) -- Element with an identification representation term
"A(n) (optional adjective) identification..." and
(self.base_Property.name.match('.*ID.*') implies documentation.body.match('An
Identifier .*')) -- Element with a status representation term "A(n) (optional
adjective) status/state of..." and (self.base_Property.name.match('.*Name.*') implies
documentation.body.match('A name of .*')) -- Element with a category text
representation term "A kind of..." -- Element with a description text representation
term "A description of..." and
(not(self.base_Property.type.stereotypedBy('AugmentationType') or
self.base_Property.type.stereotypedBy('MetadataType')) implies
documentation.body.match('An? .* ')) )
OCL2.0
NDR [Rule 7-14]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 9-31] (REF, SUB, EXT)</b>
Within the schema, the name of any reference element SHALL use the representation term
suffix Reference. </p> <p>
<b>Rationale</b> Reference elements are identical in
semantics to elements that are not by reference. However, they refer to their values
by a reference attribute instead of carrying it as content of the XML element. The use
of a suffix helps indicate that the elements refer to, instead of contain, their
values, yet allows the basic semantics (e.g., property, representation term) to
persist. </p> <p> Note that the use of the representation
term suffix is one of the situations in which there is a slight divergence from the
general rule for name generation as discussed in [Rule 9-12]. </p>
</body> </html> vergence from the general rule for name
generation as discussed in [Rule 9-12]. </p> </body>
</html> body> </html>
( (self.kind=XSDPropertyKindCode::element) and
(self.base_Property.aggregation=AggregationKind::none) ) =
self.base_Property.name.endsWith('Reference')
OCL2.0
NDR [Rule 9-31]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 9-3] (REF, SUB, EXT) </b>The
name of any XML Schema component defined by the schema SHALL contain only the
following characters: </p> <p> � Upper-case letters
('A'-'Z'). </p> <p> � Lower-case letters ('a'-'z').
</p> <p> � Digits ('0'-'9'). </p>
<p> � Hyphen ('-'). </p> <p> Other
characters, such as the underscore ('_') character and the period ('.') character
SHALL NOT appear in component names in NIEM-conformant schemas. </p>
</body> </html> od ('.') character SHALL NOT appear in
component names in NIEM-conformant schemas. </p> </body>
</html> > </body> </html> ml>
self.base_Property.name.match('[\\w|\\-]*')
OCL2.0
NDR [Rule 9-3]
If an XSDProperty has kind=element and a non-empty type, then that type must be a
Class stereotyped as a NIEMType. If it has kind=element and an empty type, then it
must be a derived union.
( ( (self.kind=XSDPropertyKindCode::element) and
not(self.base_Property.type.oclIsUndefined()) ) implies
self.base_Property.type.stereotypedBy('NIEMType') ) and ( (
(self.kind=XSDPropertyKindCode::element) and self.base_Property.type.oclIsUndefined()
) implies self.base_Property.isDerivedUnion )
OCL2.0
XSDPropertyElementKind
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 9-19] (REF, SUB, EXT) </b>Within the schema, the
name of an element declaration that is of simple content MUST use a representation
term found in NDR Table 9-2: Representation Terms. </body>
</html> on Terms. </body> </html> l>
( (self.kind=XSDPropertyKindCode::element) and
self.base_Property.type.oclIsKindOf(DataType) ) implies (
self.base_Property.name.match('.*Name.*') or self.base_Property.name.match('.*Text.*')
or self.base_Property.name.match('.*Quantity.*') or
self.base_Property.name.match('.*Percent.*') or
self.base_Property.name.match('.*Rate.*') or
self.base_Property.name.match('.*Value.*') or
self.base_Property.name.match('.*Numeric.*') or
self.base_Property.name.match('.*Measure.*') or
self.base_Property.name.match('.*Indicator.*') or
self.base_Property.name.match('.*URI.*') or self.base_Property.name.match('.*ID.*') or
self.base_Property.name.match('.*Time.*') or self.base_Property.name.match('.*Date.*')
or self.base_Property.name.match('.*DateTime.*') or
self.base_Property.name.match('.*Code.*') or
self.base_Property.name.match('.*Video.*') or
self.base_Property.name.match('.*Sound.*') or
self.base_Property.name.match('.*Picture.*') or
self.base_Property.name.match('.*Graphic.*') or
self.base_Property.name.match('.*BinaryObject.*') or
self.base_Property.name.match('.*Amount.*') )
OCL2.0
NDR [Rule 9-19]
An XSDProperty must be the ownedAttribute of a DataType or a Class stereotyped as
a NIEMType.
self.base_Property.owner.oclIsKindOf(DataType) or
self.base_Property.owner.stereotypedBy(NIEMType)
OCL2.0
XSDPropertyOwner
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 9-22] (REF, SUB, EXT)
</b>Within the schema, the name of an attribute declaration MUST use a
representation term from NDR Table 9-2: Representation Terms. </p>
<p> <b>Rationale</b> An element that
represents a value listed in the table should have a representation term. It should do
so even if its type is complex with multiple parts. For example, a type with multiple
fields may represent a sound binary, a date, or a name. </p>
</body> </html> may represent a sound binary, a date, or a
name. </p> </body> </html>
</html>
(self.kind=XSDPropertyKindCode::attribute) implies
self.base_Property.name.match('.*Name.*') or self.base_Property.name.match('.*Text.*')
or self.base_Property.name.match('.*Quantity.*') or
self.base_Property.name.match('.*Percent.*') or
self.base_Property.name.match('.*Rate.*') or
self.base_Property.name.match('.*Value.*') or
self.base_Property.name.match('.*Numeric.*') or
self.base_Property.name.match('.*Measure.*') or
self.base_Property.name.match('.*Indicator.*') or
self.base_Property.name.match('.*URI.*') or self.base_Property.name.match('.*ID.*') or
self.base_Property.name.match('.*Time.*') or self.base_Property.name.match('.*Date.*')
or self.base_Property.name.match('.*DateTime.*') or
self.base_Property.name.match('.*Code.*') or
self.base_Property.name.match('.*Video.*') or
self.base_Property.name.match('.*Sound.*') or
self.base_Property.name.match('.*Picture.*') or
self.base_Property.name.match('.*Graphic.*') or
self.base_Property.name.match('.*BinaryObject.*') or
self.base_Property.name.match('.*Amount.*')
OCL2.0
NDR [Rule 9-22]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<b>[Rule 9-6] (REF, SUB, EXT) </b>Within the schema, any
XML Schema component other than an attribute declaration SHALL have a name that begins
with an upper-case letter ('A'-'Z'). </body> </html>
'A'-'Z'). </body> </html> l>
(self.kind=XSDPropertyKindCode::element) implies
(self.base_Property.name.firstToUpper()=self.base_Property.name)
OCL2.0
NDR [Rule 9-6]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-10] (REF, SUB, EXT)</b>
Within the schema, an attribute declaration with attribute name MUST carry the
attribute type. </p> <p>
<b>Rationale</b> Untyped XML Schema attributes allow
arbitrary content, with no semantics. Attributes must have a type so that specific
syntax and semantics will be provided. </p> </body>
</html> and semantics will be provided. </p>
</body> </html> dy> </html>
(self.kind=XSDPropertyKindCode::attribute) implies
not(self.base_Property.type.oclIsUndefined())
OCL2.0
NDR [Rule 6-10]
base_Property
public
Indicates whether the NIEM property is implemented in XML Schema as an attribute
declaration and attribute use or element declaration and element particle: if
"attribute", the NIEM property is implemented in XML Schema as an attribute
declaration and attribute use; if "element", the NIEM property is implemented as an
element declaration and element particle.
kind
public
Implemented in XML Schema as the value of the nillable attribute on the
xsd:element element. Note that an XSDProperty that represents an XML attribute may not
have a nillable value.
nillable
public
If present, implemented as the value of the fixed attribute of the xsd:attribute
or xsd:element.
fixed
public
XSDProperty
extension_XSDSimpleContent
private
composite
XSDAnyProperty stereotype represents a property that is unrestricted with respect to
the properties type, which is implemented in XML Schema as the xsd:any particle.
An XSDAnyProperty must have an empty type and must not be a derived union or
subset any other property.
self.base_Property.type.oclIsUndefined() and
not(self.base_Property.isDerivedUnion) and
self.base_Property.subsettedProperty->isEmpty()
OCL2.0
XSDAnyPropertyType
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 6-11] (REF, SUB)</b> The schema
SHALL NOT contain the element xsd:any. </p> <p>
<b>Rationale</b> The xsd:any particle (see Model Group
Restrictions for an informative definition of particle) provides a wildcard that may
carry arbitrary content. The particle xsd:any may appear within constraint schemas,
extension schemas, and exchange schemas. </p> </body>
</html> s, extension schemas, and exchange schemas. </p>
</body> </html> </html>
self.base_Property.owner.owner.getTargetDirectedRelationships()
->select(d|d.stereotypedBy('ModelPackageDescriptionFile'))
->forAll(mpdf|
(mpdf.getStereotypeApplication('ModelPackageDescriptionFile').purposeURI<>'http://reference.niem.gov/niem/resource/mpd/lexicon/1.0/purpose#reference-schema')
and
(mpdf.getStereotypeApplication('ModelPackageDescriptionFile').purposeURI<>'http://reference.niem.gov/niem/resource/mpd/lexicon/1.0/purpose#subset-schema')
)
OCL2.0
NDR [Rule 6-11]
base_Property
private
Determines how or if the value of a NIEM property should be processed; values are:
"lax", "skip", and "strict".
"strict"
processContents
public
The namespace in which values of this property must be defined. Implemented in XML
Schema as the value of the namespace attribute on the xsd:any element.
"##any"
valueNamespace
public
XSDAnyProperty
Enumeration XSDWhiteSpaceCode supports the whiteSpace attribute of the
XSDWhiteSpaceCode attribute as per the XSD definitions.
replace
collapse
preserve
XSDWhiteSpaceCode
extension_NIEMProperty
public
XSDSimpleContent represents a relationship between two type definitions: the first
is a complex type definition with simple content whose content type is the second. This
relationship is implemented in XML Schema through base attribute on the xsd:extension or
xsd:restriction element of the first type definition, the actual value of which resolves
to the second type definition. Section 3.4 of XML Schema Structures addresses simple
content types in XML Schema; Sections 6.5.1, 6.5.2, and 7.4 of NIEM NDR v1.3 address
simple content types in NIEM-conformant XML Schema.
The client of an XSDSimpleContent Realization must be a Class stereotyped as a
NIEMType.
self.base_Realization.client->forAll(c|c.stereotypedBy('NIEMType'))
OCL2.0
Client must be a <<NIEMType>>
The suppler of an XSDSimpleContent Realization must be a DataType.
self.base_Realization.supplier->forAll(s|s.oclIsKindOf(DataType))
OCL2.0
supplier must be a <DataType>
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 9-1] (REF, SUB, EXT) </b>Within
the schema, a complex type that is a direct extension of a simple type from the XML
Schema namespace simple type MAY use the same local name as the simple type if and
only if the extension adds no content other than the attribute group
structures:SimpleObjectAttributeGroup. </p> <p>
<b>Rationale</b> It is useful to build complex type bases
for further extension. The NIEM distribution proxy schema xsd.xsd provides complex
type bases for some of the simple types in the XML Schema namespace. However, the
complex types in this proxy schema reuse the local names of the simple types they
extend, even though the simple type names may not be NIEM-conformant. Requiring name
changes for those NIEM-provided complex type bases would work against user
understanding, for those already familiar with the names of the XML Schema namespace
simple types being extended. </p> </body>
</html> already familiar with the names of the XML Schema namespace
simple types being extended. </p> </body>
</html> </body> </html>
self.base_Realization.client->forAll(complexType|self.base_Realization.supplier->forAll(simpleType|simpleType.name=complexType.name))
implies self.base_Realization.client.oclAsType(Class).ownedAttribute->isEmpty()
OCL2.0
NDR [Rule 9-1]
base_Realization
private
XSDSimpleContent
extension_XSDAnyElement
private
composite
An SequenceId Property is implemented in XML schema as a use of the
structures:sequenceId property. The name of the property must be "sequenceId", the type
must be integer and the multiplicity must be 1..1.
A SequenceID Property must have the name "sequenceID", the type "integer" and
multiplicity 1..1.
self.base_Property.name = "sequenceId" and self.base_Property.type.name =
"integer" and self.base_Property.type.oclIsKindOf(PrimitiveType) and
self.base_Property.lower = 1 and self.base_Property.upper = 1
OCL2.0
XSDStructureId
base_Property
private
SequenceID
XSDProcessContentsCode supports the processContents attribute of the XSDAnyProperty
stereotype.
strict
lax
skip
XSDProcessContentsCode
The XSDDeclaration stereotype is a specialization of the common References
stereotype. However, it is constrained such that its client must be an XSDProperty
Property and its supplier must be an XSDProperty Property or a Namepsace Package. By
default, the namespace of the global XSD�property declaration referenced by XSDProperty
is the namespace of its class. The XSDDeclaration stereotype allows the modeler to
specify the namespace a XSDProperty will reference based on the namespace of another
XSDProperty or the target namespace of a Namespace Package. Specifically, the client of
the XSDDeclaration Realization shall reference the namespace indicated by the supplier
of the XSDDeclaration Realization, the client of the maps to one of the following: an
attribute use schema component or a particle component whose term property is an element
declaration schema component. In the first case, the supplier maps to the attribute
declaration schema component for the attribute use component. In the second case, the
supplier maps to the element declaration schema component for the particle schema
component.
XSDDeclaration
NIEM_PSM_Profile
http://www.omg.org/spec/NIEM-UML/20120501/NIEM_PSM_Profile
The NIEM PIM Profile comprises stereotypes that are used in NIEM PIMs but not NIEM
PSMs. Further, the NIEM PIM Profile imports the NIEM Common Profile and, therefore,
includes all the stereotypes and metaclasses covered by that profile. In addition, the UML
metamodel subset covered by the NIEM PIM Profile also includes the metaclasses Association
and AssociationClass, even though they are not specifically extended by any stereotypes in
the profile.
An Augments Generalization specifies that the special Class is an augmentation type
that is restricted to apply to instances of the general Class.
base_Generalization
private
Augments
extension_RoleOf
private
composite
The contents of an InformationModel Package provide a platform-independent
perspective on the structure of information to be exchanged in NIEM messages. Such a
model is always taken to represent a NIEM namespace, but it may also be given a default
purpose as modeled, independent of the implementation of that namespace. This allows a
modeler to identify the intended purposes (e.g., reference, subset, exchange, etc.) of
various information models within a set, without having to create a complete MPD model
for the set.
base_Package
private
The default purpose for which an information model is intended. If an
InformationModel Package is modeled as being included as an artifact in an MPD, then,
unless otherwise specified, the purpose of the artifact is by default taken to be the
schema purpose code corresponding to the value of the defaultPurpose attribute.
defaultPurpose
public
InformationModel
The ReferenceName stereotype is used on an Element that has a name that does not
conform to the naming conventions required by the NIEM NDR or is otherwise not the
desired NIEM name. The NIEMName attribute must provide a name for the Element that
conforms to the relevant NDR naming rules for the specific kind of Element to which the
stereotype is applied.
base_Element
private
A NIEM NDR-conformant name to be applied to an Element. The NIEMName will override
any name generated from the UML name..
NIEMName
public
ReferenceName
extension_Augments
private
composite
extension_InformationModel
private
composite
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body> The
possible purposes for an information model. This enumeration provides the allowed values
for the defaultPurpose attribute of the InformationModel stereotype. The values
correspond to the schema purpose codes for an MPD artifact. </body>
</html> MPD artifact. </body> </html>
ml>
subset
constraint
exchange
extension
incremental
reference
replacement
DefaultPurposeCode
extension_
private
composite
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> The RoleOf stereotype is applied to a Property of a Class representing
a NIEM role type, whose type identifies the base type of that role type. A RoleOf
Property must be a reference (i.e., have aggregation=none). A NIEM role type is a type
that represents a particular function, purpose, usage, or role of an object.
</p> </body> </html> usage, or role of an
object. </p> </body> </html>
</html>
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 9-35] (REF, SUB, EXT)</b>
Within the schema, the name of a role SHALL use the property term RoleOf.
</p> <p> <b>Rationale</b>
Using the property term RoleOf immediately identifies an element as representing a
role. </p> </body> </html> ement as
representing a role. </p> </body> </html>
</html>
This constraint is enforced by the PIM/PSM transformation. The Transformation
ensures that the "RoleOf" property term becomes part of the target PSM property name.
English
NDR [Rule 9-35]
<html> <head> <style> p {padding:0px;
margin:0px;} </style> </head> <body>
<p> <b>[Rule 7-40] (REF, SUB, EXT)</b>
Within the schema, any element with a name beginning with the string RoleOf SHALL
represent a base type, of which the containing type represents a role.
</p> <p> <b>Rationale</b> A
RoleOf element references its corresponding base element. The RoleOf label on the
reference element ensures that a role object is distinguishable from other objects and
its link to the associated base is also distinguishable from the additional properties
that are characteristic of this role or that add information. </p>
</body> </html> are characteristic of this role or that
add information. </p> </body> </html>
</html>
This constraint is implemented by the PIM/PSM transformation. Identifying a
<Property> as a <<RoleOf>> corresponds to
the NIEM naming convention used to identify the roleOf...reference and furthermore
establishes the owning <Classifier> as a NIEM Role.
English
NDR [Rule 7-40]
base_Property
private
RoleOf
extension_
private
composite
RolePlayedBy Generalization specifies that the special class is to be considered the
type of a role that is played by instances of the general class. In the PSM this will
map to a property with the "RoleOf" prefix..
base_Generalization
private
RolePlayedBy
NIEM_PIM_Profile
http://www.omg.org/spec/NIEM-UML/20120501/NIEM_PIM_Profile
The NIEM UML Profile imports the NIEM PIM Profile, the NIEM PSM Profile and the Model
Package Description Profile, so all three of these profiles can effectively be imported
just by importing the single NIEM UML Profile.
NIEM_UML_Profile
http://www.omg.org/spec/NIEM-UML/20120501
NIEM_UML_Profile
org.omg.xmi.nsPrefix
NIEM_UML_Profile
org.omg.xmi.nsPrefix
NIEM_Common_Profile
org.omg.xmi.nsPrefix
NIEM_PIM_Profile
org.omg.xmi.nsPrefix
NIEM_PSM_Profile
org.omg.xmi.nsPrefix
Model_Package_Description_Profile