This document specifies normative rules and non-normative guidance for building a National Information Exchange Model (NIEM) information exchange package documentation (IEPD).

This document deprecates the Model Package Description (MPD) construct as of NIEM 5.0.

This specification represents the work of the NIEM Technical Architecture Committee (NTAC), the NIEM Business Architecture Committee (NBAC), and their predecessors. It is a product of the NIEM Management Office (NMO).

Email comments on this specification to information@niem.gov or submit them via the GitHub issue tracker.

• 1. Introduction
  • 1.1. Background
  • 1.2. Purpose
  • 1.3. Scope
  • 1.4. Audience
• 2. Basic Concepts and Terminology
  • 2.1. IETF Best Current Practice 14 terminology
  • 2.2. Character Case Sensitivity
  • 2.3. Artifacts
  • 2.4. Schema Document and Namespace Correspondence in NIEM
  • 2.5. Namespaces Used in this Specification
  • 2.6. XML Validation
  • 2.7. Reference Schema Documents
  • 2.8. Rules
• 3. Conformance Targets
  • 3.1. Conformance Target Terminology
  • 3.2. IEPD Conformance Targets
    • 3.2.1. Information Exchange Package Documentation
      • 3.2.1.1. Well-Formed IEPD
    • 3.2.2. IEP Conformance Targets
    • 3.2.3. Artifact Conformance Targets
  • 3.3. Rule Applicability Codes for Conformance Targets
• 4. IEPD XML Schema Document Artifacts
  • 4.1. Reference Schema Documents
  • 4.2. Subset Document Schemas
    • 4.2.1. Basic Subset Concepts
    • 4.2.2. Constructing a Schema Document Subset
  • 4.3. Extension Schema Documents
  • 4.4. External Schema Documents
  • 4.5. Constraint Schema Document Sets
• 5. IEPD Documentation Artifacts
  • 5.1. NIEM IEPD Catalog
    • 5.1.1. IEPD Catalog as a Table of Contents
    • 5.1.2. Extending an IEPD Catalog
  • 5.2. Metadata Concepts
    • 5.2.1. IEPD Name Syntax (c:iepdName)
    • 5.2.2. IEPD Conformance Target Identifier (c:iepdConformanceTargetIdentifierURIList)
    • 5.2.3. IEPD Version Numbering Scheme (c:iepdVersionID)
    • 5.2.4. URI Schemes
      • 5.2.4.1. IEPD URI Scheme (c:iepdURI)
      • 5.2.4.2. URI Scheme for IEPD Artifacts (c:externalURI)
      • 5.2.4.3. URI Scheme for Local IEPD Artifacts (c:pathURI)
      • 5.2.4.4. IEPD Relationships and Lineage (c:resourceURI)
      • 5.2.4.5. Resolving an IEPD URI with a Fragment
      • 5.2.4.6. URI Resolution Involving Reference Elements
      • 5.2.4.7. XML Catalog URI
      • 5.2.4.8. Summary of IEPD URIs
  • 5.3. Change Log
  • 5.4. ReadMe Artifact
    • 5.4.1. Readme Content
  • 5.5. XML Catalogs
  • 5.6. Defining Information Exchange Packages
    • 5.6.1. Validity Context and Constraints
    • 5.6.2. Declaring Validity Constraints
      • 5.6.2.1. c:ValidityConstraintWithContext
      • 5.6.2.2. c:ValidityConstraint
      • 5.6.2.3. c:ValidityContext
      • 5.6.2.4. c:HasDocumentElement
      • 5.6.2.5. c:ValidToXPath
      • 5.6.2.6. c:XMLSchemaValid
      • 5.6.2.7. c:SchematronValid
      • 5.6.2.8. c:RelaxNGValid
      • 5.6.2.9. c:ConformsToConformanceTarget
      • 5.6.2.10. c:ConformsToRule
    • 5.6.3. IEP Sample Instance XML Documents
  • 5.7. Conformance Assertion
• 6. Optional IEPD Artifacts
  • 6.1. NIEM Wantlist
  • 6.2. Business Rules
• 7. Organization, Packaging, and Other Criteria
  • 7.1. Artifact Sets
    • 7.1.1. Constraint on Elements of Type c:SchemaDocumentSetType
  • 7.2. IEPD File Name Syntax
  • 7.3. Artifact Links to Other Resources
  • 7.4. IEPD Completeness
  • 7.5. Duplication of Artifacts
• Appendix A. IEPD Catalog XML Schema Document
• Appendix B. Example IEPD Catalog Document for Cursor on Target
• Appendix C. Common IEPD Artifacts
• Appendix D. Conformance Assertion Example
• Appendix E. Guidance for IEPD Directories (non-normative)
• Appendix F. Acronyms and Abbreviations
• Appendix G. References
• Appendix H. Index of Definitions
• Appendix I. Index of Rules

This specification defines rules and practices for constructing and packaging a National Information Exchange Model (NIEM)information exchange package documentation (IEPD). To the NIEM program, the IEPD is considered the point of interoperability.

This specification assumes familiarity with NIEM, its basic concepts, architecture, processes, design rules, and general conformance rules. NIEM training and reference materials are located on the [NIEM TechHub]. In addition to those materials, readers of this specification may wish to be familiar with the current versions of the following:

• [NIEM Conformance Specification]
• [NIEM Conformance Targets Attribute Specification]
• [NIEM Naming and Design Rules]
• [NIEM Code List Specification]
• [NIEM High-Level Version Architecture]

This specification uses and is a peer to the [NIEM Naming and Design Rules].

The section defines and discusses baseline terms and concepts that will be used throughout this document. Presentation in this section is sequenced for understanding. Each subsection builds upon previous ones.

c           http://reference.niem.gov/niem/resource/iepd/catalog/5.0/
er	    urn:oasis:names:tc:entity:xmlns:xml:catalog
nc	    http://release.niem.gov/niem/niem-core/5.0/
structures  http://release.niem.gov/niem/structures/5.0/
xs          http://www.w3.org/2001/XMLSchema

This section introduces conformance targets, a concept fundamental to understanding the normative rules defined in this specification. This section also defines and explains conformance targets used in this specification.

There are several purposes for defining conformance targets in NIEM specifications. A conformance target establishes and identifies a class of artifact associated with a set of rules. Based on these rules, tools and operations may be developed to process or use these artifacts consistently.

Conformance targets also satisfy a need to ensure developers do not conform to NIEM in name only. Once committed to using NIEM, developers and organizations need well-defined conformance targets and rules to know exactly how to conform. Funding agencies require conformance targets that correspond to interoperability goals. An agency that is funding development of a set of systems will need to ensure it funds the development of NIEM-conformant IEPDs that support the exchange of NIEM-conformant IEPs. Tools and system developers need conformance targets that identify real world requirements corresponding to their use cases and tool capabilities. Many of these tools have not yet been developed. Therefore, this specification attempts to cover a broad range of general use cases.

XML schema document artifacts are the essential content of IEPDs because they normatively define and declare data components. The purpose of an IEPD is determined by the XML schema document or document set(s) it contains; furthermore, each XML schema document may have a different purpose. The [NIEM Naming and Design Rules] addresses some schema documents as conformance targets including reference schema documents, extension schema documents, and schema document sets. Each conformance target may adhere to a different (though possibly overlapping) set of conformance rules. Consult the current [NIEM Naming and Design Rules] for these rules. NIEM also employs a special technique that relies on constraint schema document sets (See Section 4.5, Constraint Schema Document Sets, below).

The following subsections define each type of NIEM schema document and document set.

XML schema documents (and the schemas that result from them) are the essence of a NIEM IEPD. However, a variety of documentation files may be incorporated into a NIEM IEPD. One particular documentation file is required in every IEPD: iepd-catalog.xml, the IEPD catalog document. This file contains basic metadata, relationship and lineage data, conformance target specifications, and validation information.

A readme artifact (formerly known as a master document) is mandatory for IEPDs. IEPDs are often built by different developers, and may be registered into a repository for reuse by many other users, developers, and implementers; therefore, a minimal form of documentation is absolutely necessary. An IEPD readme file is the primary source and starting point for human readable documentation, and should reference (and describe) any other separate documentation artifacts. This requirement ensures that baseline documentation is consistently rooted in a clearly visible artifact within each IEPD.

The following subsections address these documentation artifacts and the concepts, metadata, and content each supports.

5.2. Metadata Concepts

The IEPD catalog also contains both required and optional metadata for the IEPD and its artifacts and artifact sets. The following subsections specify the syntax, formats, and semantics for that metadata.

5.2.1. IEPD Name Syntax (c:iepdName)

An IEPD’s official name is the value of the c:iepdName attribute owned by the c:IEPD element in the IEPD’s catalog document. This value is constrained by the regular expression pattern on c:iepdName within the IEPD catalog schema Appendix A, IEPD Catalog XML Schema Document, below:

[A-Za-z]([-_ ]?[A-Za-z0-9]+)*

The regular expression above indicates that an IEPD name:

• Begins with an alpha character (upper or lower case).
• Ends with an alphanumeric character (upper or lower case).
• May contain alphanumeric characters.
• May contain single spaces, single dashes, and single underscores as separators.

IEPD author’s often reuse the official IEPD name in metadata within the file name. Note that c:iepdName is of xs:token type and allows single spaces and upper case alpha characters. That said, be sure to consider differences in operating system or file system treatment of spaces and character case within file and directory names. (See Rule 7-5, IEPD ZIP file Name Syntax (IEPD), below.

c:iepdName is not the same thing as the name of the file containing the IEPD, described in Section 7.2, IEPD File Name Syntax, below.

5.2.2. IEPD Conformance Target Identifier (c:iepdConformanceTargetIdentifierURIList)

An IEPD conformance target identifier is a conformance target identifier to which the given IEPD claims to conform. The IEPD catalog c:iepdConformanceTargetIdentifierURIList attribute declares a list of conformance target identifiers, identifying the conformance targets to which the IEPD claims to conform.

The c:iepdConformanceTargetIdentifierURIList attribute is an XML list type that may declare that an IEPD conforms to multiple conformance targets. An IEPD developer can establish a new IEPD conformance target identifier in addition to those provided by this and other NIEM specifications. The identifier represents the new conformance target which should be associated with one or more rules or constraints to which an IEPD must conform if it is assigned that identifier.

An IEPD authoring organization might use another classification system for its IEPDs. For example, the organization ABC might establish the conformance target identifier http://example.org/niem-iepd/1.0/#abc-org to indicate its IEPDs also conform to its own stricter set of IEPD conformance rules. Thus, an IEPD catalog document for its published IEPDs would contain the c:iepdConformanceTargetIdentifierURIList component shown in Figure 5-1, IEPD catalog c:iepdConformanceTargetIdentifierURIList attribute for organization ABC., below, indicating conformance to three conformance targets.

Figure 5-1: IEPD catalog c:iepdConformanceTargetIdentifierURIList attribute for organization ABC.

c:iepdConformanceTargetIdentifierURIList=
 "http://reference.niem.gov/niem/specification/iepd/5.0/#IEPD
  http://example.org/niem-iepd/1.0/#abc-org"

5.2.3. IEPD Version Numbering Scheme (c:iepdVersionID)

Published IEPDs may be periodically revised and updated; therefore, versioning is required to clearly indicate changes have occurred. In order to maintain some consistency while allowing reasonable flexibility to authors, this specification establishes a simple version numbering scheme that is consistent with most common practices. This is the same version numbering scheme that is used for NIEM releases.

An IEPD version number is the value of the c:iepdVersionID attribute owned by the c:IEPD element within its IEPD catalog document. A consistent version number syntax is enforced by the IEPD catalog schema in Appendix A, IEPD Catalog XML Schema Document, below. The syntax rule is as follows:

Rule 5-9. IEPD Version Number Syntax

[Rule 5-9] (WF-IEPD) (Constraint)

An IEPD MUST be assigned a version number that adheres to the regular expression:

	version ::= digit+ ('.' digit+)* (status digit+)?
	Where:	
		digit   ::= [0-9]
		status  ::= 'alpha' | 'beta' | 'rc' | 'rev'

The meaning of the status values are as follows:

• alpha indicates early development; changing significantly.
• beta indicates late development; but changing or incomplete.
• rc indicates release candidate; complete but not approved as operational.
• rev indicates very minor revision that does not impact schema validation.

The regular expression notation used above is from [W3C XML 1.0] Notation.

Note that the absence of a status string in the version number indicates that the version has been baselined and published.

The following examples are valid IEPD version numbers:

• 1
• 1.2
• 1.3.1.0
• 1.2alpha13
• 199.88.15rev6

There are two implications in Rule 5-9, IEPD Version Number Syntax (WF-IEPD), above. The first is that in some cases this version scheme implies and confirms a chronology of releases. For example, a given product labeled version 2.3 must have been released before the same product labeled 2.3.1. Therefore, version 2.3.1 is more current than version 2.3.

However, this is a multi-series version scheme, and chronological relationships exist only within a given series. So, for example, nothing can be said about a chronological relationship between versions 2.2.4 and 2.3. This is because version 2.2.4 is in a different series (i.e., 2.2) and could actually have been released after 2.3. Figure 5-2, Example versioning system, below, illustrates a system of versions that uses the numbering scheme of Rule 5-9, IEPD Version Number Syntax (WF-IEPD), above.

Figure 5-2: Example versioning system

Figure 5-2, Example versioning system, above, illustrates eight different version series. Within this illustration these are the only sequences that have chronological relationships that can be identified through version numbers.

• Series 2 is {2.2, 2.3, 2.4}
• Series 3 is {3.0, 3.1, 3.2}
• Series 2.2 is {2.2, 2.2.1, 2.2.2, 2.2.3, 2.2.4}
• Series 2.3 is {2.3, 2.3.1}
• Series 2.4 is {2.4, 2.4.1}
• Series 3.0 is {3.0, 3.0.1, 3.0.2}
• Series 3.1 is {3.1, 3.1.1}
• Series 3.2 is {3.2, 3.2.1, 3.2.2}

The second implication of Rule 5-9, IEPD Version Number Syntax (WF-IEPD), above, is that pre-releases are easily identified by the strings alpha, beta, and rc. These strings are simple visible indicators of IEPD status or stage of development.

This specification places no further restrictions or meaning (implied or otherwise) on a version number. Authors have the option to use integers between dots to indicate degree of compatibility or other relationships between versions as needed. For example, for a given IEPD, the author may declare that if an instance validates to version 4.2.3, then it will also validate to version 4.2. Such a claim is acceptable. However, this specification does not imply any such relationships. Any meaning assigned to version sequence by an authoritative source should be unambiguously documented within the IEPD.

IEPD version numbers within a version series do NOT imply compatibility between versions. Compatibility between or among IEPD versions MUST be explicitly stated in documentation.

Note that an author who updates an existing IEPD to a new version may choose the version number based on its previous version number or not, as long as it follows the version number syntax.

Version number syntax applies to IEPDs only; there is no requirement to apply this syntax to artifact versioning.

5.2.4. URI Schemes

All IEPDs use Uniform Resource Identifiers (URIs) to identify artifacts and other resources. Several kinds of URIs are employed by IEPDs to reference other IEPDs, IEPD artifacts (internally and externally), conformance targets, documents, and other resources. For each type of URI used in an IEPD catalog document, this section describes its purpose, options, and syntax based on [RFC 3986 URI].

The following definitions will be useful to understanding IEPD rules defined in later subsections that involve various kinds of URIs.

[Definition: path name]

A general form of the name of a file or directory that specifies a unique location in a file system. A path name points to a file system location by following the directory tree hierarchy expressed in a string of characters in which path components, separated by a delimiting character, represent each subdirectory. If a path name terminates in a file name, then it specifies the location of that file.

[Definition: resolve URI]

A function (or action) that takes a URI string of the form xs:anyURI and returns the resource it identifies. If the URI is local (i.e., within an IEPD) and the resource does not exist, then this function fails. If a URI is remote or of unknown location (e.g., a URN), then this function (or action) may require human assistance to determine if a resource associated with the URI exists (pass) or not (fail).

5.2.4.1. IEPD URI Scheme (c:iepdURI)

To facilitate IEPD sharing and reuse, the assignment of a URI (Uniform Resource Identifier) to an IEPD is essential. This is enforced by the IEPD catalog schema document Appendix A, IEPD Catalog XML Schema Document, below. It is also important to ensure that an IEPD URI is absolute.

Rule 5-10. IEPD URI Is Absolute

[Rule 5-10] (WF-IEPD) (Constraint)

In an IEPD catalog document, the value of a c:iepdURI attribute of type xs:anyURI MUST match the production <absolute-URI> as defined by [RFC 3986 URI], §4.3, Absolute URI.

This rule implies that a URI assigned to an IEPD must be valid. Furthermore, the entity (person or organization) assigning the IEPD URI either (1) is the registrant of the domain name or namespace identifier, or (2) has authority from the registrant to assign this URI.

Examples of valid IEPD URIs:

• http://gbi.georgia.gov/gcic/niem/sort-entry/1.1/
• http://www.acq.osd.mil/ncbdp/nm/pseag/seiwg-niem/1.0/
• http://ncsc.org/niem/icwa/1.0
• http://cb.acf.hhs.gov/neice/1.0/exchange/

This specification does not mandate that basic IEPD catalog metadata be designed into an IEPD URI. However, including such can obviously provide convenient visual recognition. That said, an author should ensure any metadata embedded in the URI accurately reflect the IEPD catalog metadata (in particular, the values of c:iepdURI, c:iepdName, c:iepdVersionID, and c:iepdConformanceTargetIdentifierURIList defined in the IEPD catalog document).

5.2.4.2. URI Scheme for IEPD Artifacts (c:externalURI)

Artifacts in other IEPDs can be referenced from within an IEPD to identify equivalence (signify reuse, one aspect of lineage). To support this concept, the following IEPD URI rules are necessary:

Rule 5-11. IEPD URI Supports Fragment

[Rule 5-11] (WF-IEPD) (Constraint)

A valid IEPD URI MUST support the inclusion of a fragment identifier (as a suffix) [RFC 3986 URI].

This rule ensures that an IEPD can always uniquely identify and refer to each artifact within another IEPD. This IEPD specification follows [RFC 3986 URI] which forbids a URI to contain more than a single fragment identifier. To construct an IEPD artifact URI, add a fragment (that locally identifies the artifact) to an IEPD URI, and therefore, an IEPD URI cannot already contain a fragment.

Rule 5-12. IEPD URI Has No Fragment

[Rule 5-12] (WF-IEPD) (Constraint)

A valid IEPD URI MUST NOT contain a fragment identifier [RFC 3986 URI].

Rationale: If a URI for an IEPD (do NOT confuse this with a URI for an IEPD artifact) already contains a fragment identifier, then that URI cannot be employed as an IEPD artifact URI, because [RFC 3986 URI] only allows a single fragment identifier.

By the following rule, each file artifact or artifact set is uniquely identified by its path name relative to the IEPD root directory.

Rule 5-13. IEPD Artifact URI Syntax

[Rule 5-13] (WF-IEPD) (Interpretation)

Within an IEPD a URI reference to an artifact in another external IEPD (i.e., an IEPD artifact URI) is the concatenation of:

• The URI of the IEPD that contains the artifact.
• A pound-sign character ("#" — also known as a hashtag character).
• An identifier that is the artifact’s locally unique path name relative to the IEPD root directory.

An artifact set has a locally unique path name. An artifact has a path name that terminates with its file name which is unique to the directory it resides in.

The following are examples of valid IEPD artifact URIs:

• http://example.gov/niem-iepd/pmix/3.0/#subset/niem-core.xsd (a file artifact)
• http://example.gov/niem-iepd/pmix/3.0beta2/#extension/ext-1.1.xsd (a file artifact)
• http://example.gov/niem-iepd/pmix/3.0/#application-info (a set artifact)
• http://example.gov/niem-iepd/pmix/3.0/#iep-sample/query (a set artifact)

Artifact URIs are used as values for the c:externalURI attribute in the IEPD catalog XML document to declare equivalence relationships between artifacts (See Appendix A, IEPD Catalog XML Schema Document, below). A simple scenario follows. Consider two different IEPDs with the following URIs:

1. http://example.gov/niem-iepd/pmix/3.0/
2. http://www.abc.org/niem-iepd/order/2.1.2rev3/

The author of IEPD (2) has decided to reuse the base-xsd/extension/req1.xsd artifact in IEPD (1) as-is. They can optionally create an IEPD catalog c:ExtensionSchemaDocument entry for this artifact (assuming it is an extension schema document), and add the attribute:

c:externalURI="http://example.org/niem-iepd/pmix/3.0/#base-xsd/extension/req1.xsd"

Additional c:externalURI attributes may be added to this entry if the author knows of other uses of this same artifact in other IEPDs and wishes to acknowledge them.

A URI does not have the same meaning as namespace. NIEM namespaces cannot be used as IEPD artifact URIs. Recall that the target namespace used in a subset schema document derived from a NIEM release schema document is identical to the target namespace of that release schema document. Furthermore, an IEPD may contain multiple subsets. NIEM namespaces are not necessarily unique to an artifact within an IEPD. Later, Section 5.5, XML Catalogs, below, will describe the use of [XML Catalogs 1.1] to correlate namespaces to local URIs in order to resolve them to local resources.

The value of c:externalURI is an identifier for a remote resource that is not necessarily accessible online. For this reason, even though such URIs should be correct (i.e. a resource with that URI should exist), their verification is not within the scope of this specification.

5.2.4.3. URI Scheme for Local IEPD Artifacts (c:pathURI)

An IEPD uses the file directory system of path names and file names to identify local artifacts and artifact sets. All local URIs are relative to the location of the IEPD catalog document, and therefore, they are also relative to the IEPD root directory since the IEPD catalog document resides in the IEPD root directory.

In general, every value of attribute c:pathURI in an IEPD catalog document will be a relative path name to a directory (i.e., an artifact set), or to a file (i.e., an artifact). The following are typical examples of each:

Artifact Set: c:pathURI="base-xsd/niem/niem-core/3.0"

Artifact:      c:pathURI="base-xsd/niem/niem-core/3.0/niem-core.xsd"

Note that per Table 5-1, Summary of RFC 3986 URI: Generic Syntax, below, and Table 5-2, Summary of IEPD URI attributes, below, a local URI may contain an optional fragment. Although c:pathURI has no use for a URI with a fragment, IEPD documentation artifacts could reference a subpart within a local artifact by using a relative URI with a fragment.

Despite its simplicity, c:pathURI comes with over a dozen rules that help to define an information exchange package documentation. These rules ensure that every c:pathURI attribute value in a well-formed IEPD resolves to a correct local resource:

Rule 5-14. c:pathURI Resolves to a Resource

[Rule 5-14] (WF-IEPD) (Constraint)

Within an IEPD catalog document, the value of a c:pathURI attribute MUST resolve to a resource.

Rule 5-15. c:pathURI for c:XMLCatalog

[Rule 5-15] (WF-IEPD) (Constraint)

Within an IEPD catalog document, the value of a c:pathURI attribute owned by a c:XMLCatalog element MUST resolve to an XML catalog document.

Rule 5-16. c:pathURI for c:IEPDChangeLog

[Rule 5-16] (WF-IEPD) (Constraint)

Within an IEPD catalog document, the value of a c:pathURI attribute owned by a c:IEPDChangeLog element MUST resolve to a change log.

Rule 5-17. c:pathURI for c:ReadMe

[Rule 5-17] (WF-IEPD) (Constraint)

Within an IEPD catalog document, the value of a c:pathURI attribute owned by a c:ReadMe element MUST resolve to a readme artifact.

Rule 5-18. c:pathURI for c:IEPSampleXMLDocument

[Rule 5-18] (WF-IEPD) (Constraint)

Within an IEPD catalog document, the value of a c:pathURI attribute owned by a c:IEPSampleXMLDocument element MUST resolve to an XML document.

Rule 5-19. c:pathURI for c:BusinessRulesArtifact

[Rule 5-19] (WF-IEPD) (Constraint)

Within an IEPD catalog document, the value of a c:pathURI attribute owned by a c:BusinessRulesArtifact element MUST resolve to a business rule schema or business rules artifact.

Rule 5-20. c:pathURI for c:XMLSchemaDocument

[Rule 5-20] (WF-IEPD) (Constraint)

Within an IEPD catalog document, the value of a c:pathURI attribute owned by a c:XMLSchemaDocument element MUST resolve to an XML schema document.

Rule 5-21. c:pathURI for c:ExternalSchemaDocument

[Rule 5-21] (WF-IEPD) (Constraint)

Within an IEPD catalog document, the value of a c:pathURI attribute owned by a c:ExternalSchemaDocument element MUST resolve to an XML schema document.

Rule 5-22. c:pathURI for c:ReferenceSchemaDocument

[Rule 5-22] (WF-IEPD) (Constraint)

Within an IEPD catalog document, the value of a c:pathURI attribute owned by a c:ReferenceSchemaDocument element MUST resolve to a NIEM reference schema document.

Rule 5-23. c:pathURI for c:ExtensionSchemaDocument

[Rule 5-23] (WF-IEPD) (Constraint)

Within an IEPD catalog document, the value of a c:pathURI attribute owned by a c:ExtensionSchemaDocument element MUST resolve to a NIEM extension schema document.

Rule 5-24. c:pathURI for c:SubsetSchemaDocument

[Rule 5-24] (WF-IEPD) (Constraint)

Within an IEPD catalog document, the value of a c:pathURI attribute owned by a c:SubsetSchemaDocument element MUST resolve to a NIEM subset schema document.

Note: It is not possible for a Schematron rule to verify that the URI resolves to a NIEM subset schema document, only that it is a schema document.

Rule 5-25. c:pathURI for c:Wantlist

[Rule 5-25] (WF-IEPD) (Constraint)

Within an IEPD catalog document, the value of a c:pathURI attribute owned by a c:Wantlist element MUST resolve to a NIEM wantlist XML document.

Rule 5-26. c:pathURI for c:SchematronSchema

[Rule 5-26] (WF-IEPD) (Constraint)

Within an IEPD catalog document, the value of a c:pathURI attribute owned by a c:SchematronSchema element MUST resolve to a Schematron schema.

Rule 5-27. c:pathURI for c:RelaxNGSchema

[Rule 5-27] (WF-IEPD) (Constraint)

Within an IEPD catalog document, the value of a c:pathURI attribute owned by a c:RelaxNGSchema element MUST resolve to a RelaxNG schema.

Rule 5-28. c:pathURI for c:SchemaDocumentSet

[Rule 5-28] (WF-IEPD) (Constraint)

Within an IEPD catalog document, the value of a c:pathURI attribute owned by a c:SchemaDocumentSet element MUST resolve to an XML schema document set.

Rule 5-29. c:pathURI for c:ConstraintSchemaDocumentSet

[Rule 5-29] (WF-IEPD) (Constraint)

Within an IEPD catalog document, the value of a c:pathURI attribute owned by a c:ConstraintSchemaDocumentSet element MUST resolve to a NIEM XML schema document set.

Rule 5-30. Schema document set interpreted as constraint schema document set

[Rule 5-30] (WF-IEPD) (Interpretation)

Any XML schema document set whose c:pathURI attribute resolves to a constraint schema document set MUST be interpreted to be a constraint schema document set.

5.2.4.4. IEPD Relationships and Lineage (c:resourceURI)

An important business requirement is transparency of IEPD lineage. Data lineage is also referred to as data provenance, how the data was derived and where it came from. There are two basic views of data provenance: (1) as data annotations; and (2) as a graph of data relationships [Principles of Data Integration], Chapter 14 Data Provenance.

The IEPD Specification adapts the latter view of data provenance to enable a simple framework for recording IEPD lineage within an IEPD catalog. The URI scheme for IEPDs and their artifacts and sets enables a graph of relationships. An IEPD may internally identify and record relationships to other IEPDs, including families, versions, adaptations, specializations, generalizations, etc.

The next few paragraphs require understanding of URIs for IEPDs and IEPD artifacts. See Section 5.2.4.1, IEPD URI Scheme (c:iepdURI), above, and Section 5.2.4.2, URI Scheme for IEPD Artifacts (c:externalURI), above.

The IEPD catalog provides a c:Relationship element with two attributes (c:resourceURI and c:relationshipCode) and an optional element (nc:DescriptionText) to identify ancestry and other relationships to other IEPDs. There are many ways that one IEPD may relate to another. This makes it difficult to specify a fixed set of values that can objectively define an exact relationship between a pair of IEPDs. Therefore, the optional nc:DescriptionText element is provided to further explain the nature of any of the c:relationshipCode values. The set is: {version_of, specializes, generalizes, deprecates, supersedes, adapts, conforms_to, updates}. In some cases, the value of c:relationshipCode may be generic enough to require a more detailed explanation in nc:DescriptionText (for example, if its value is adapts).

As was described in Section 5.2.4.2, URI Scheme for IEPD Artifacts (c:externalURI), above, the IEPD catalog also enables an author to record more fine-grained ancestry between IEPDs using the c:externalURI attribute. This attribute records an explicit equivalence relationship between artifacts reused across IEPDs.

Note that a c:resourceURI attribute is used to identify a remote resource that is only related to the IEPD whose catalog declares it. The resource is not required for validation. Therefore, the IEPD is not required to contain this resource. As in the case of c:externalURI, the value of a c:resourceURI should be correct (i.e., a resource with that URI should exist). However, in this case, existence verification is considered outside the scope of this specification.

5.2.4.5. Resolving an IEPD URI with a Fragment

Rule 5-31. Resolve IEPD URI with Fragment

[Rule 5-31] (WF-IEPD) (Interpretation)

Given an absolute IEPD URI [RFC 3986 URI], §4.3, Absolute URI with a fragment, resolve this URI as follows:

1. Resolve the base URI (per [RFC 3986 URI]) to retrieve the resource IEPD. If the resource IEPD does not exist, then fail (existence error).

2. Apply the fragment (without "#") to the IEPD resource:

   1. Locate a structures:id attribute value that matches the fragment string. If more than one exist, then fail (ambiguity error). If none exists, then continue.
   2. Locate a path name (for a directory or file) that matches the fragment string. If more than one exist, then fail (ambiguity error). If none exists, then fail (existence error).
3. Return the element, directory, or file found.

In the presence of NIEM reference elements, URI resolution may require an additional step to account for indirect references. Be sure to review Section 5.2.4.6, URI Resolution Involving Reference Elements, below, if this case applies.

5.2.4.6. URI Resolution Involving Reference Elements

A NIEM element can indirectly reference its content rather than carry or encapsulate it. A NIEM element with simple content derived from type xs:anyURI may appear in an instance XML document as an element information item that has an attribute xs:anyURI, in which case, rather than locally containing a URI as simple content, it will instead refer to another element that contains a URI. Under some circumstances, this might impact URI resolution described in Rule 5-31, Resolve IEPD URI with Fragment (WF-IEPD), above.

Thus, the structures:ref attribute value refers to another element that carries the content (for both elements) and owns a structures:id attribute with a value equal to that of structures:ref.

The IEPD catalog document reuses NIEM Core and so it conforms to NIEM. Therefore, one or more NIEM reference elements from various locations may refer to a single content bearing instance of the same element (with a unique structures:id). The definition of resolve URI and the URI-related rules in this section assume content bearing elements. If a URI resolution rule applies to an element in reference element form, then URI resolution will be applied at the site of the content-bearing element form it refers to (where the URI will be).

5.2.4.7. XML Catalog URI

An XML catalog document conforms to [XML Catalogs 1.1]. For the purpose of IEPD validation, the following rules ensure that an XML catalog document contains URIs that correctly resolve.

Rule 5-32. XML Catalog uri Value Resolves to Resource

[Rule 5-32] (XML-catalog) (Constraint)

Within an XML catalog document, the value of a uri attribute owned by a er:uri element MUST resolve to a resource.

Rule 5-33. XML Catalog uri Value Resolves to Resource with Correct Target Namespace

[Rule 5-33] (XML-catalog) (Constraint)

Within an XML catalog document, given an XML schema document resolved by the value of a uri attribute owned by a er:uri element, the XML schema document target namespace MUST equal the value of the name (a namespace string) attribute owned by the er:uri element.

5.2.4.8. Summary of IEPD URIs

This section summarizes the various URIs used in the IEPD catalog document. It also presents a summary of [RFC 3986 URI]. See that reference for explanation and details of URI syntax.

Table 5-1: Summary of RFC 3986 URI: Generic Syntax

Id	URI Syntax	Meaning	Examples
1	<absolute-URI>	absolute URI only (no fragment)	http://nlets.org/rap/3.1/
2	<URI>	absolute URI and optional fragment	http://nlets.org/rap/3.1/#rap-sheet2
3	<relative-reference>	optional relative part and optional fragment	/iep-sample/query.xml or #A3 or /iep-sample/query.xml#A3
4	<URI-reference>	<URI> or <relative-reference>	any example in 1, 2, or 3 above

 

As the table above indicates, [RFC 3986 URI] allows a <relative-reference> to contain a fragment or even be a fragment itself. However, a c:pathURI is required to resolve to a local resource. Therefore, rules in this specification preclude a c:pathURI value from taking the fragment-only form of a <relative-reference>.

Table 5-2: Summary of IEPD URI attributes

IEPD Attribute	URI Syntax (refer to table above)
c:iepdURI	<absolute-URI>
c:pathURI	<relative-reference>; excluding fragment-only format; relative to IEPD catalog document
c:externalURI	<URI>
c:resourceURI	<URI>

 

Aside from the required artifacts, IEPD content is relatively flexible. A variety of other optional documentation files may be incorporated into an IEPD. When applicable, these may include (but are not limited to) files that describe or explain:

• Implementation details (hardware, software, configuration, etc.)
• Use of multiple root elements
• Use of multiple subsets or mixed releases
• How to use/reuse an IEPD for various purposes (such as Web Services)
• Rationales and/or business purposes

In addition to documentation artifacts, a variety of other optional files can be added to an IEPD to facilitate tool support and make reuse, adaptation, and/or implementation easier. These are often files that are inputs to or outputs from software tools. Examples include content diagrams, content models in tool-specific formats, and business rules (either formal or informal representations).

An IEPD author may include any files believed to be useful to understand, implement, reuse, and/or adapt an IEPD.

An IEPD of relatively simple content and scope may only need to contain the minimum mandatory artifacts required by this specification in order to understand and implement it. (See Appendix C, Common IEPD Artifacts, below, for a listing of the mandatory and common optional artifacts for each type of IEPD.)

Files vary widely in format and are often specific to the tools an author uses to parse, consume, or output them. Therefore, if tool-specific files are included in an IEPD, it is also a good practice to include copies of those files in formats that display with standard Web browsers or other cost-free, publicly available viewing tools (e.g., ASCII text, PDF, CSV, HTML, JPG, GIF, PNG). This guidance is intended to encourage and facilitate maximal sharing and distribution of IEPDs; it does not prohibit and is not intended to discourage the inclusion of other file formats.

In particular, this specification does not discourage use of Microsoft file formats for documentation and other optional artifacts. Microsoft Office products are in common use, and free viewers are available for many of them (See https://www.microsoft.com/en-us/microsoft-365/microsoft-office).

An IEPD is a logical set of electronic files aggregated and organized to fulfill a specific purpose in NIEM. Directory organization and packaging of an IEPD should be designed around major themes in NIEM: reuse, sharing, interoperability, and efficiency.

NIEM XSD and XML artifacts in an IEPD must be valid for both XML Schema and NIEM. This also implies these artifacts must adhere to applicable [NIEM Naming and Design Rules] conformance target rules.

There are many ways to organize IEPD directories that may depend on a number of factors including (not limited to) business purpose and complexity. For this reason, strict rules for IEPD directory structure are difficult to establish. Therefore, IEPD authors may create their own logical directory structures subject to the rules of this section.

The foregoing rule ensures that:

• Unpacking an IEPD in ZIP file format will not scatter its contents on a storage device.
• One common starting directory always exists to explore or use any IEPD.
• iepd-catalog and change log artifacts will always be found in the IEPD root directory.

	<c:FileSet c:pathURI="samples/">
		<nc:DescriptionText>All IEP samples within this IEPD.</nc:DescriptionText>
	</c:FileSet>
		

	<c:FileSet>
		<nc:DescriptionText>All IEP samples in this IEPD</nc:DescriptionText>
		<c:FileSet c:pathURI="samples/" />
		<c:FileSet c:pathURI="iep-samples-1/" />
		<c:FileSet c:pathURI="iep-samples-2/" />
		<c:FileSet c:pathURI="iep-samples-supplement/" />
		<c:IEPSampleXMLDocument c:pathURI="iep/test-case1.xml" c:mimeMediaTypeText="text/xml" />
		<c:IEPSampleXMLDocument c:pathURI="test/test-case2.xml" c:mimeMediaTypeText="text/xml" />
	</c:FileSet>
		

	iepd-filename ::= name '-' version '.iepd.zip'
	Where: 
		name     ::= alphanum ((alphanum | special)* alphanum)?
		alphanum ::= [a-z0-9]
		special  ::= '.' | '-' | '_'
		version  ::= digit+ ('.' digit+)* (status digit+)?
		digit    ::= [0-9]
		status   ::= 'alpha' | 'beta' | 'rc' | 'rev'

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
  ct:conformanceTargets="http://reference.niem.gov/niem/specification/naming-and-design-rules/5.0/#ReferenceSchemaDocument"
  targetNamespace="http://reference.niem.gov/niem/resource/iepd/catalog/5.0/"
  version="5.0"
  xmlns:appinfo="http://release.niem.gov/niem/appinfo/5.0/"
  xmlns:c="http://reference.niem.gov/niem/resource/iepd/catalog/5.0/"
  xmlns:ct="http://release.niem.gov/niem/conformanceTargets/3.0/"
  xmlns:nc="http://release.niem.gov/niem/niem-core/5.0/"
  xmlns:niem-xs="http://release.niem.gov/niem/proxy/niem-xs/5.0/"
  xmlns:structures="http://release.niem.gov/niem/structures/5.0/"
  xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:annotation>
    <xs:documentation>Information Exchange Package Documentation (IEPD) Catalog schema document.  Defines an iepd-catalog.xml artifact for IEPDs.  The purpose of this schema is to facilitate consistent declaration of IEPD content, conformance targets, metadata, and lineage to process, display, review, register, search, and discover IEPDs efficiently, as well as instructions for validating IEPs to IEPDs.  This XML Schema document is supported by a subset of NIEM 5.0.
    </xs:documentation>
    <xs:appinfo>
      <appinfo:LocalTerm term="EXI" literal="Efficient XML Interchange"/>
      <appinfo:LocalTerm term="IANA" literal="Internet Assigned Numbers Authority"/>
      <appinfo:LocalTerm term="ID" literal="Identifier"/>
      <appinfo:LocalTerm term="IEP" literal="Information Exchange Package" definition="an instance XML document"/>
      <appinfo:LocalTerm term="IEPD" literal="Information Exchange Package                                                 Documentation"/>
      <appinfo:LocalTerm term="MIME" literal="Multipurpose Internet Mail Extension"/>
      <appinfo:LocalTerm term="OASIS" literal="Organization for the Advancement                                                of Structured Information Standards"/>
      <appinfo:LocalTerm term="SSGT" literal="Schema Subset Generation Tool"/>
      <appinfo:LocalTerm term="URI" literal="Uniform Resource Identifier"/>
      <appinfo:LocalTerm term="Wantlist" definition="An XML file that represents a                                                       NIEM schema document subset; used by NIEM Schema Subset Generation                                                       Tool to input/output a schema document subset"/>
    </xs:appinfo>
  </xs:annotation>
  <xs:import namespace="http://release.niem.gov/niem/appinfo/5.0/" schemaLocation="niem/xsd/utility/appinfo.xsd"/>
  <xs:import namespace="http://release.niem.gov/niem/conformanceTargets/3.0/" schemaLocation="niem/xsd/utility/conformanceTargets.xsd"/>
  <xs:import namespace="http://release.niem.gov/niem/niem-core/5.0/" schemaLocation="niem/xsd/niem-core.xsd"/>
  <xs:import namespace="http://release.niem.gov/niem/proxy/niem-xs/5.0/" schemaLocation="niem/xsd/adapters/niem-xs.xsd"/>
  <xs:import namespace="http://release.niem.gov/niem/structures/5.0/" schemaLocation="niem/xsd/utility/structures.xsd"/>
  <xs:element name="IEPDCatalog" type="c:IEPDCatalogType">
    <xs:annotation>
      <xs:documentation>An IEPD catalog that describes IEPD artifacts and metadata.
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:complexType name="IEPDCatalogType">
    <xs:annotation>
      <xs:documentation>A data type for an IEPD catalog.</xs:documentation>
    </xs:annotation>
    <xs:complexContent>
      <xs:extension base="structures:ObjectType">
        <xs:sequence>
          <xs:element ref="nc:DescriptionText" minOccurs="0"/>
          <xs:element ref="c:IEPDInformation" minOccurs="0"/>
          <xs:element ref="c:IEPConformanceTarget" minOccurs="0" maxOccurs="unbounded"/>
          <xs:element ref="c:ArtifactOrArtifactSet" minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:attribute ref="c:iepdURI" use="required"/>
        <xs:attribute ref="c:iepdConformanceTargetIdentifierURIList" use="required"/>
        <xs:attribute ref="c:iepdName" use="required"/>
        <xs:attribute ref="c:iepdVersionID" use="required"/>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>
  <xs:element name="ArtifactOrArtifactSet" abstract="true">
    <xs:annotation>
      <xs:documentation>
        A data concept for a file or file set in an IEPD.
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <!-- File artifact classifiers for a table of contents =========================== -->
  <xs:element name="File" type="c:FileType" substitutionGroup="c:ArtifactOrArtifactSet">
    <xs:annotation>
      <xs:documentation>
        A generic electronic file artifact in an IEPD; a file stored on a computer system.
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:complexType name="FileType">
    <xs:annotation>
      <xs:documentation>A data type for an IEPD file artifact.</xs:documentation>
    </xs:annotation>
    <xs:complexContent>
      <xs:extension base="structures:ObjectType">
        <xs:sequence>
          <xs:element ref="c:RequiredFile" minOccurs="0" maxOccurs="unbounded"/>
          <xs:element ref="nc:DescriptionText" minOccurs="0"/>
        </xs:sequence>
        <xs:attribute ref="c:pathURI" use="required"/>
        <xs:attribute ref="c:mimeMediaTypeText" use="optional"/>
        <xs:attribute ref="c:externalURI" use="optional"/>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>
  <xs:element name="XMLCatalog" type="c:FileType" substitutionGroup="c:ArtifactOrArtifactSet">
    <xs:annotation>
      <xs:documentation>
        An IEPD artifact that is an OASIS XML catalog.
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="IEPDChangeLog" type="c:FileType" substitutionGroup="c:ArtifactOrArtifactSet">
    <xs:annotation>
      <xs:documentation>
        An IEPD artifact that contains a record of the IEPD changes.
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="ReadMe" type="c:FileType" substitutionGroup="c:ArtifactOrArtifactSet">
    <xs:annotation>
      <xs:documentation>An IEPD read-me artifact.</xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="IEPSampleXMLDocument" type="c:FileType" substitutionGroup="c:ArtifactOrArtifactSet">
    <xs:annotation>
      <xs:documentation>
        An example IEPD instance XML document or IEP artifact.
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="BusinessRulesArtifact" type="c:FileType" substitutionGroup="c:ArtifactOrArtifactSet">
    <xs:annotation>
      <xs:documentation>
        An IEPD artifact that contains business rules 
        and constraints on exchange content.
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="XMLSchemaDocument" type="c:FileType" substitutionGroup="c:ArtifactOrArtifactSet">
    <xs:annotation>
      <xs:documentation>
        An IEPD artifact that is an XML schema document (i.e., an XSD that
        is not necessarily a NIEM subset, extension, or reference schema).
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="ExternalSchemaDocument" type="c:FileType" substitutionGroup="c:XMLSchemaDocument">
    <xs:annotation>
      <xs:documentation>
        An IEPD artifact that is a schema document external to NIEM.
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="ExtensionSchemaDocument" type="c:FileType" substitutionGroup="c:XMLSchemaDocument">
    <xs:annotation>
      <xs:documentation>An IEPD artifact that is a NIEM extension schema document.
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="SubsetSchemaDocument" type="c:FileType" substitutionGroup="c:XMLSchemaDocument">
    <xs:annotation>
      <xs:documentation>An IEPD artifact that is a subset schema document.
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="ReferenceSchemaDocument" type="c:FileType" substitutionGroup="c:XMLSchemaDocument">
    <xs:annotation>
      <xs:documentation>An IEPD artifact that is a reference schema document (from a release, domain update, or core update).
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="EXIXMLSchema" type="c:XMLSchemaType" substitutionGroup="c:ArtifactOrArtifactSet">
    <xs:annotation>
      <xs:documentation>
        An XML Schema to be used for EXI serialization of an IEP Class.
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="Wantlist" type="c:FileType" substitutionGroup="c:ArtifactOrArtifactSet">
    <xs:annotation>
      <xs:documentation>An IEPD artifact that represents a NIEM schema subset 
        and is used as an import or export for the NIEM SSGT.</xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="ConformanceAssertion" type="c:FileType" substitutionGroup="c:ArtifactOrArtifactSet">
    <xs:annotation>
      <xs:documentation>An IEPD artifact that is a signed declaration 
        that a NIEM IEPD is NIEM-conformant.</xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="ConformanceReport" type="c:FileType" substitutionGroup="c:ArtifactOrArtifactSet">
    <xs:annotation>
      <xs:documentation>
	An IEPD artifact either auto-generated by a NIEM-aware software tool or manually prepared 
	that checks NIEM conformance and/or quality and renders a detailed report of results.
	This report may also be an auto-generated and manually prepared hybrid artifact. 
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="SchematronSchema" type="c:FileType" substitutionGroup="c:ArtifactOrArtifactSet">
    <xs:annotation>
      <xs:documentation>A Schematron schema document.</xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="RelaxNGSchema" type="c:FileType" substitutionGroup="c:ArtifactOrArtifactSet">
    <xs:annotation>
      <xs:documentation>A RelaxNG schema.</xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="Documentation" type="c:FileType" substitutionGroup="c:ArtifactOrArtifactSet">
    <xs:annotation>
      <xs:documentation>
        An IEPD artifact that is a form of explanatory documentation.
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="ApplicationInfo" type="c:FileType" substitutionGroup="c:ArtifactOrArtifactSet">
    <xs:annotation>
      <xs:documentation>
        An IEPD artifact that is used by a software tool (e.g., import, export, input, output, etc.).
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <!-- For declaring sets of dependent artifacts =================================== -->
  <xs:element name="RequiredFile" type="c:FileType">
    <xs:annotation>
      <xs:documentation>
        An IEPD file artifact that another artifact depends on and should not be separated from.
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <!-- Artifact Set Classifiers ==================================================== -->
  <xs:element name="FileSet" type="c:FileSetType" substitutionGroup="c:ArtifactOrArtifactSet">
    <xs:annotation>
      <xs:documentation>
        A generic IEPD artifact set; used to group artifacts that are not accounted for by other set classifiers.
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:complexType name="FileSetType">
    <xs:annotation>
      <xs:documentation>A data type for a set of IEPD file artifacts.</xs:documentation>
    </xs:annotation>
    <xs:complexContent>
      <xs:extension base="structures:ObjectType">
        <xs:sequence>
          <xs:element ref="nc:DescriptionText" minOccurs="0"/>
          <xs:element ref="c:ArtifactOrArtifactSet" minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:attribute ref="c:pathURI" use="optional"/>
        <xs:attribute ref="c:externalURI" use="optional"/>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>
  <xs:element name="SchemaDocumentSet" type="c:SchemaDocumentSetType" substitutionGroup="c:ArtifactOrArtifactSet">
    <xs:annotation>
      <xs:documentation>
        An IEPD artifact set that may include subset schema documents, extension and external schema documents, and other supporting artifacts.
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="ConstraintSchemaDocumentSet" type="c:SchemaDocumentSetType" substitutionGroup="c:ArtifactOrArtifactSet">
    <xs:annotation>
      <xs:documentation>
        An IEPD artifact set of constraint schema documents and other supporting artifacts.
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:complexType name="SchemaDocumentSetType">
    <xs:annotation>
      <xs:documentation>
        A data type for an IEPD artifact set that may include subset schema documents, extension schema documents, and external schema documents or constraint schema documents.
      </xs:documentation>
    </xs:annotation>
    <xs:complexContent>
      <xs:extension base="c:FileSetType"/>
    </xs:complexContent>
  </xs:complexType>
  <!-- Primitives ================================================================== -->
  <xs:attribute name="iepdURI" type="xs:anyURI">
    <xs:annotation>
      <xs:documentation>
        A globally unique identifier (URI) for an IEPD.
      </xs:documentation>
    </xs:annotation>
  </xs:attribute>
  <xs:attribute name="iepdName" type="c:IEPDNameSimpleType">
    <xs:annotation>
      <xs:documentation>A descriptive label or title for an IEPD.</xs:documentation>
    </xs:annotation>
  </xs:attribute>
  <xs:simpleType name="IEPDNameSimpleType">
    <xs:annotation>
      <xs:documentation>
        A data type for an IEPD name, label, or title.
      </xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:token">
      <xs:pattern value="[A-Za-z]([-_ ]?[A-Za-z0-9]+)*"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:attribute name="iepdVersionID" type="c:IEPDVersionIDSimpleType">
    <xs:annotation>
      <xs:documentation>
        An identifier that distinguishes releases of a given IEPD.
      </xs:documentation>
    </xs:annotation>
  </xs:attribute>
  <xs:simpleType name="IEPDVersionIDSimpleType">
    <xs:annotation>
      <xs:documentation>
        A data type for an identifier that distinguishes releases of a given IEPD.
      </xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:token">
      <xs:pattern value="[0-9]+(\.[0-9]+)*((alpha|beta|rc|rev)[0-9]+)?"/>
    </xs:restriction>
  </xs:simpleType>
  <!-- =========================================================================== -->
  <xs:attribute name="iepdConformanceTargetIdentifierURIList" type="c:IEPDConformanceTargetIdentifierURIListSimpleType">
    <xs:annotation>
      <xs:documentation>
        A list of one or more URIs that each represents an IEPD class to which the IEPD claims conformance.
      </xs:documentation>
    </xs:annotation>
  </xs:attribute>
  <xs:simpleType name="IEPDConformanceTargetIdentifierURIListSimpleType">
    <xs:annotation>
      <xs:documentation>
        A data type that ensures at least one conformance target is identified as an IEPD conformance target.
      </xs:documentation>
    </xs:annotation>
    <xs:restriction base="c:IEPDConformanceTargetIdentifierListSimpleType">
      <xs:minLength value="1"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="IEPDConformanceTargetIdentifierListSimpleType">
    <xs:annotation>
      <xs:documentation>
        A data type for one or more URIs that are IEPD conformance target classes.
      </xs:documentation>
    </xs:annotation>
    <xs:list itemType="xs:anyURI"/>
  </xs:simpleType>
  <!-- =========================================================================== -->
  <xs:attribute name="pathURI" type="xs:anyURI">
    <xs:annotation>
      <xs:documentation>
        A URI for the pathname of a local artifact relative to the IEPD root directory.
      </xs:documentation>
    </xs:annotation>
  </xs:attribute>
  <xs:attribute name="externalURI" type="xs:anyURI">
    <xs:annotation>
      <xs:documentation>
        A globally unique identifier (URI) for an artifact in another IEPD that is reused by this IEPD.
      </xs:documentation>
    </xs:annotation>
  </xs:attribute>
  <xs:attribute name="mimeMediaTypeText" type="xs:string">
    <xs:annotation>
      <xs:documentation>
        A classification for an IEPD file artifact from the IANA MIME media classes: http://www.iana.org/assignments/media-types.
      </xs:documentation>
    </xs:annotation>
  </xs:attribute>
  <xs:complexType name="RelationshipType">
    <xs:annotation>
      <xs:documentation>
        A data type for a reference to another IEPD related to this IEPD.
      </xs:documentation>
    </xs:annotation>
    <xs:complexContent>
      <xs:extension base="structures:ObjectType">
        <xs:sequence>
          <xs:element ref="nc:DescriptionText" minOccurs="0"/>
        </xs:sequence>
        <xs:attribute ref="c:relationshipCode" use="required"/>
        <xs:attribute ref="c:resourceURI" use="required"/>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>
  <xs:attribute name="resourceURI" type="xs:anyURI">
    <xs:annotation>
      <xs:documentation>
        A globally unique identifier (URI) for another IEPD or document to which this IEPD relates.
      </xs:documentation>
    </xs:annotation>
  </xs:attribute>
  <xs:attribute name="relationshipCode" type="c:RelationshipCodeSimpleType">
    <xs:annotation>
      <xs:documentation>
        A classification or reason for the connectedness between this IEPD and the resource referenced in resourceURI.
      </xs:documentation>
    </xs:annotation>
  </xs:attribute>
  <xs:simpleType name="RelationshipCodeSimpleType">
    <xs:annotation>
      <xs:documentation>
        A data type for a classification of the relationship between IEPDs.
      </xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:token">
      <xs:enumeration value="version_of">
        <xs:annotation>
          <xs:documentation>
            A relationshipCode value for indicating that this IEPD is a different version of the IEPD 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.
          </xs:documentation>
        </xs:annotation>
      </xs:enumeration>
      <xs:enumeration value="specializes">
        <xs:annotation>
          <xs:documentation>
            A relationshipCode value for indicating that this IEPD is a specialization of the IEPD referenced in resourceURI.  This value is the inverse of generalizes.
          </xs:documentation>
        </xs:annotation>
      </xs:enumeration>
      <xs:enumeration value="generalizes">
        <xs:annotation>
          <xs:documentation>
            A relationshipCode value for indicating that this IEPD is a generalization of the IEPD referenced in resourceURI.  This value is the inverse of specializes.
          </xs:documentation>
        </xs:annotation>
      </xs:enumeration>
      <xs:enumeration value="supersedes">
        <xs:annotation>
          <xs:documentation>
            A relationshipCode value for indicating that this IEPD replaces the IEPD referenced in resourceURI.
          </xs:documentation>
        </xs:annotation>
      </xs:enumeration>
      <xs:enumeration value="deprecates">
        <xs:annotation>
          <xs:documentation>
            A relationshipCode value for indicating that content in this IEPD is preferred over content in the IEPD referenced in resourceURI; and at some time in the future will supersede the IEPD referenced in resourceURI.
          </xs:documentation>
        </xs:annotation>
      </xs:enumeration>
      <xs:enumeration value="adapts">
        <xs:annotation>
          <xs:documentation>
            A relationshipCode value for indicating that this IEPD is an adaptation of the IEPD referenced in resourceURI.
          </xs:documentation>
        </xs:annotation>
      </xs:enumeration>
      <xs:enumeration value="updates">
        <xs:annotation>
          <xs:documentation>
            A relationshipCode value for indicating that this IEPD is an incremental update to the resource referenced in resourceURI.
          </xs:documentation>
        </xs:annotation>
      </xs:enumeration>
      <xs:enumeration value="conforms_to">
        <xs:annotation>
          <xs:documentation>
            A relationshipCode value for indicating that this IEPD conforms to the specification or standard referenced in resourceURI.
          </xs:documentation>
        </xs:annotation>
      </xs:enumeration>
      <xs:enumeration value="derives_from">
        <xs:annotation>
          <xs:documentation>
            A relationshipCode value for indicating that this IEPD has been derived from another (may have other uses as well).
          </xs:documentation>
        </xs:annotation>
      </xs:enumeration>
    </xs:restriction>
  </xs:simpleType>
  <!-- IEP Conformance Targets ==================================================== -->
  <xs:element name="IEPConformanceTarget" type="c:IEPConformanceTargetType">
    <xs:annotation>
      <xs:documentation>
        A class or category of IEPs which has a set of validity constraints and a unique identifier. Every IEP is an instance of one or more IEP Conformance Targets.
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:complexType name="IEPConformanceTargetType">
    <xs:annotation>
      <xs:documentation>
        A data type for a class or category of IEP, which has a set of validity constraints and a unique identifier.
      </xs:documentation>
    </xs:annotation>
    <xs:complexContent>
      <xs:extension base="structures:ObjectType">
        <xs:sequence>
          <xs:element ref="nc:DescriptionText" minOccurs="0"/>
          <xs:element ref="c:ValidityConstraintWithContext" minOccurs="0" maxOccurs="unbounded"/>
          <xs:element ref="c:ArtifactOrArtifactSet" minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>
  <xs:element name="ValidityConstraintWithContext" abstract="true">
    <xs:annotation>
      <xs:documentation>
        A data concept for a rule or instructions for validating an IEP candidate (XML document) using some context within that XML document.
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="ValidityConstraint" abstract="true" substitutionGroup="c:ValidityConstraintWithContext">
    <xs:annotation>
      <xs:documentation>
        A data concept for a rule or instructions for validating an IEP candidate.
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="ValidityContext" type="c:ValidityContextType" substitutionGroup="c:ValidityConstraintWithContext">
    <xs:annotation>
      <xs:documentation>
        A rule or instructions for validating an IEP candidate within context defined by an XPath expression.
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:complexType name="ValidityContextType">
    <xs:annotation>
      <xs:documentation>
        A data type for a rule or instructions for validating an IEP candidate within context defined by an XPath expression.
      </xs:documentation>
    </xs:annotation>
    <xs:complexContent>
      <xs:extension base="structures:ObjectType">
        <xs:sequence>
          <xs:element ref="nc:DescriptionText" minOccurs="0"/>
          <xs:element ref="c:ValidityConstraint" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:attribute ref="c:xPathText" use="required"/>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>
  <!-- Validity Constraints ======================================================== -->
  <xs:element name="ValidToXPath" type="c:XPathType" substitutionGroup="c:ValidityConstraint">
    <xs:annotation>
      <xs:documentation>
        A validity constraint that has a an XPath expression that MUST have an effective Boolean value of "TRUE" when applied to a valid IEP. 
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:complexType name="XPathType">
    <xs:annotation>
      <xs:documentation>A data type for an XPath expression.</xs:documentation>
    </xs:annotation>
    <xs:complexContent>
      <xs:extension base="structures:ObjectType">
        <xs:sequence>
          <xs:element ref="nc:DescriptionText" minOccurs="0"/>
        </xs:sequence>
        <xs:attribute ref="c:xPathText" use="required"/>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>
  <xs:attribute name="xPathText" type="xs:string">
    <xs:annotation>
      <xs:documentation>An XPath expression.</xs:documentation>
    </xs:annotation>
  </xs:attribute>
  <xs:element name="XMLSchemaValid" type="c:XMLSchemaType" substitutionGroup="c:ValidityConstraint">
    <xs:annotation>
      <xs:documentation>
        A validity constraint that indicates that an artifact must be locally XML Schema valid against an XML schema described/asssembled using one or more XML catalog documents or (more explicitly) one or more XML schema documents.
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:complexType name="XMLSchemaType">
    <xs:annotation>
      <xs:documentation>A data type for a validity constraint that  indicating an XML Schema against which an artifact may be validated, or which can be used for other purposes.  c:XMLSchemaDocument identifies the root or starting XML schema document.
      </xs:documentation>
    </xs:annotation>
    <xs:complexContent>
      <xs:extension base="structures:ObjectType">
        <xs:sequence>
          <xs:element ref="nc:DescriptionText" minOccurs="0"/>
          <xs:element ref="c:XMLCatalog" minOccurs="0" maxOccurs="unbounded"/>
          <xs:element ref="c:XMLSchemaDocument" minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>
  <xs:element name="SchematronValid" type="c:SchematronValidationType" substitutionGroup="c:ValidityConstraint">
    <xs:annotation>
      <xs:documentation>A validity constraint that indicates that an artifact must be valid against the rules carried by a Schematron file, starting with the identified validation roots.
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:complexType name="SchematronValidationType">
    <xs:annotation>
      <xs:documentation>
        A data type for a Schematron validation constraint, indicating a Schematron schema document against which an artifact may be validated as well as a description of the validation roots for assessment of validity.
      </xs:documentation>
    </xs:annotation>
    <xs:complexContent>
      <xs:extension base="structures:ObjectType">
        <xs:sequence>
          <xs:element ref="nc:DescriptionText" minOccurs="0"/>
          <xs:element ref="c:SchematronSchema"/>
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>
  <xs:element name="RelaxNGValid" type="c:RelaxNGValidationType" substitutionGroup="c:ValidityConstraint">
    <xs:annotation>
      <xs:documentation>
        A validity constraint that indicates that an artifact must be valid against the rules carried by a RelaxNG schema.
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:complexType name="RelaxNGValidationType">
    <xs:annotation>
      <xs:documentation>
        A data type for a RelaxNG validation constraint, indicating a RelaxNG schema document against which an artifact may be validated, as well as a description of the validation roots for assessment of validity.
      </xs:documentation>
    </xs:annotation>
    <xs:complexContent>
      <xs:extension base="structures:ObjectType">
        <xs:sequence>
          <xs:element ref="nc:DescriptionText" minOccurs="0"/>
          <xs:element ref="c:RelaxNGSchema"/>
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>
  <xs:element name="HasDocumentElement" type="c:QualifiedNamesType" substitutionGroup="c:ValidityConstraintWithContext">
    <xs:annotation>
      <xs:documentation>
        A validity constraint that indicates that an artifact has a document element with a name that is one of the given qualified names.
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:complexType name="QualifiedNamesType">
    <xs:annotation>
      <xs:documentation>A data type for a set of qualified names.</xs:documentation>
    </xs:annotation>
    <xs:complexContent>
      <xs:extension base="structures:ObjectType">
        <xs:sequence>
          <xs:element ref="nc:DescriptionText" minOccurs="0"/>
        </xs:sequence>
        <xs:attribute ref="c:qualifiedNameList" use="required"/>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>
  <xs:attribute name="qualifiedNameList" type="c:QualifiedNameListSimpleType">
    <xs:annotation>
      <xs:documentation>A list of qualified names.</xs:documentation>
    </xs:annotation>
  </xs:attribute>
  <xs:simpleType name="QualifiedNameListSimpleType">
    <xs:annotation>
      <xs:documentation>A data type for a list of qualified names.</xs:documentation>
    </xs:annotation>
    <xs:list itemType="xs:QName"/>
  </xs:simpleType>
  <xs:element name="ConformsToConformanceTarget" type="c:ConformanceTargetType" substitutionGroup="c:ValidityConstraint">
    <xs:annotation>
      <xs:documentation>
        A validity constraint that indicates that an artifact must conform to the given conformance target.
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:complexType name="ConformanceTargetType">
    <xs:annotation>
      <xs:documentation>
        A data type for identifying and describing a conformance target.
      </xs:documentation>
    </xs:annotation>
    <xs:complexContent>
      <xs:extension base="structures:ObjectType">
        <xs:sequence>
          <xs:element ref="nc:DescriptionText" minOccurs="0"/>
        </xs:sequence>
        <xs:attribute ref="c:conformanceTargetURI" use="required"/>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>
  <xs:attribute name="conformanceTargetURI" type="xs:anyURI">
    <xs:annotation>
      <xs:documentation>A URI for a conformance target.</xs:documentation>
    </xs:annotation>
  </xs:attribute>
  <xs:element name="ConformsToRule" type="c:TextRuleType" substitutionGroup="c:ValidityConstraint">
    <xs:annotation>
      <xs:documentation>
        A validity constraint that indicates that an artifact must conform to the given text rule, drafted in a human language.
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:complexType name="TextRuleType">
    <xs:annotation>
      <xs:documentation>
        A data type for a rule drafted in a human language.
      </xs:documentation>
    </xs:annotation>
    <xs:complexContent>
      <xs:extension base="structures:ObjectType">
        <xs:sequence>
          <xs:element ref="nc:DescriptionText" minOccurs="0"/>
          <xs:element ref="c:RuleText"/>
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>
  <xs:element name="RuleText" type="nc:TextType">
    <xs:annotation>
      <xs:documentation>A rule written in a human language.</xs:documentation>
    </xs:annotation>
  </xs:element>
  <!-- Metadata ==================================================================== -->
  <xs:element name="IEPDInformation" type="c:IEPDInformationType">
    <xs:annotation>
      <xs:documentation>A set of descriptive data about an IEPD.</xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:complexType name="IEPDInformationType">
    <xs:annotation>
      <xs:documentation>
        A data type for a set of descriptive data about an IEPD.
      </xs:documentation>
    </xs:annotation>
    <xs:complexContent>
      <xs:extension base="structures:ObjectType">
        <xs:sequence>
          <xs:element ref="c:AuthoritativeSource" minOccurs="0"/>
          <xs:element ref="c:CreationDate" minOccurs="0"/>
          <xs:element ref="c:LastRevisionDate" minOccurs="0"/>
          <xs:element ref="c:StatusText" minOccurs="0"/>
          <xs:element ref="c:Relationship" minOccurs="0" maxOccurs="unbounded"/>
          <xs:element ref="c:KeywordText" minOccurs="0" maxOccurs="unbounded"/>
          <xs:element ref="c:DomainText" minOccurs="0" maxOccurs="unbounded"/>
          <xs:element ref="c:PurposeText" minOccurs="0" maxOccurs="unbounded"/>
          <xs:element ref="c:ExchangePatternText" minOccurs="0" maxOccurs="unbounded"/>
          <xs:element ref="c:ExchangePartnerName" minOccurs="0" maxOccurs="unbounded"/>
          <xs:element ref="c:ExtendedInformation" minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>
  <xs:element name="ExtendedInformation" abstract="true">
    <xs:annotation>
      <xs:documentation>
        A data concept for a user-defined descriptive data about an IEPD.
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="AuthoritativeSource" type="nc:EntityType">
    <xs:annotation>
      <xs:documentation>
        An official sponsoring or authoring organization responsible for an IEPD.
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="CreationDate" type="niem-xs:date">
    <xs:annotation>
      <xs:documentation>A date this IEPD was published.</xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="LastRevisionDate" type="niem-xs:date">
    <xs:annotation>
      <xs:documentation>
        A date the latest changes to an IEPD were published (i.e., CreationDate of previous version).
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="StatusText" type="niem-xs:string">
    <xs:annotation>
      <xs:documentation>
        A description of the current state of this IEPD in development; may also project future plans for the IEPD.
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="Relationship" type="c:RelationshipType">
    <xs:annotation>
      <xs:documentation>A reference to another IEPD related to this IEPD.</xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="KeywordText" type="niem-xs:string">
    <xs:annotation>
      <xs:documentation>
        A common alias, term, or phrase that would help to facilitate search and discovery of this IEPD.
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="DomainText" type="niem-xs:string">
    <xs:annotation>
      <xs:documentation>
        A description of the environment or NIEM Domain in which this IEPD is applicable or used.
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="PurposeText" type="niem-xs:string">
    <xs:annotation>
      <xs:documentation>
        A description of the intended usage and reason for which an IEPD exists.
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="ExchangePatternText" type="niem-xs:string">
    <xs:annotation>
      <xs:documentation>
        A description of a transactional or design pattern used for this IEPD.
      </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="ExchangePartnerName" type="niem-xs:string">
    <xs:annotation>
      <xs:documentation>
        A name of an entity or organization that uses this IEPD.
      </xs:documentation>
    </xs:annotation>
  </xs:element>
</xs:schema>

Below is a simple example of an IEPD catalog document for a Cursor on Target IEPD. The entire IEPD and other example IEPDs and supporting artifacts are available on the [NIEM Template IEPD repository].

<?xml version="1.0" encoding="UTF-8"?>
<c:IEPDCatalog xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://reference.niem.gov/niem/resource/iepd/catalog/5.0/ iepd-catalog.xsd"
    xmlns:c="http://reference.niem.gov/niem/resource/iepd/catalog/5.0/"
    xmlns:nc="http://release.niem.gov/niem/niem-core/5.0/"
    xmlns:structures="http://release.niem.gov/niem/structures/5.0/"
    xmlns:cot="http://example.com/cot-niem/0.9/" c:iepdURI="http://example.com/cot-iepd/0.9rc2/"
    c:iepdConformanceTargetIdentifierURIList="http://reference.niem.gov/niem/specification/model-package-description/4.0/#IEPD"
    c:iepdName="cot-iepd" c:iepdVersionID="0.9rc1">
    <c:IEPDInformation>
        <c:AuthoritativeSource>
            <nc:EntityOrganization>
                <nc:OrganizationName>CoT Program Office</nc:OrganizationName>
                <nc:OrganizationPrimaryContactInformation>
                    <nc:ContactWebsiteURI> https://partners.mitre.org/sites/CoTUserGroup/
                    </nc:ContactWebsiteURI>
                </nc:OrganizationPrimaryContactInformation>
            </nc:EntityOrganization>
        </c:AuthoritativeSource>
        <c:CreationDate>2014-08-04</c:CreationDate>
        <c:StatusText>Release Candidate</c:StatusText>
    </c:IEPDInformation>
    <c:IEPConformanceTarget structures:id="CoT-NIEM-IEP">
        <nc:DescriptionText>
                An IEP class equivalent to Cursor-on-Target 2.0 messages
            </nc:DescriptionText>
        <c:HasDocumentElement c:qualifiedNameList="cot:Event"/>
        <c:XMLSchemaValid>
            <c:XMLCatalog c:pathURI="base-xsd/xml-catalog.xml"/>
        </c:XMLSchemaValid>
        <c:SchematronValid>
            <c:SchematronSchema c:pathURI="schematron/business-rules.sch"/>
        </c:SchematronValid>
        <c:EXIXMLSchema>
            <c:XMLCatalog c:pathURI="exi-xsd/exi-xml-catalog.xml"/>
            <c:XMLSchemaDocument c:pathURI="extension/cot-niem.xsd"/>
        </c:EXIXMLSchema>
        <c:IEPSampleXMLDocument c:pathURI="iep-samples/iep1.xml"/>
    </c:IEPConformanceTarget>
    <c:ReadMe c:pathURI="00-README.txt"/>
    <c:IEPDChangeLog c:pathURI="01-changelog.txt"/>
    <c:ConformanceAssertion c:pathURI="02-conformance.txt"/>
    <c:Wantlist c:pathURI="base-xsd/niem/wantlist.xml"/>
    <c:ExtensionSchemaDocument c:pathURI="base-xsd/extension/cot-niem.xsd"/>
    <c:ExtensionSchemaDocument c:pathURI="base-xsd/extension/cot-niem-codes.xsd"/>
    <c:ReferenceSchemaDocument c:pathURI="base-xsd/extension/milops-future-ref.xsd"/>
</c:IEPDCatalog>

Notes:

• (IEPD) in artifact name indicates a required artifact for an IEPD.
• (ref) indicates name is hyperlinked to a defined term in the specification.
• * in filename syntax indicates wildcard.

A NIEM conformance assertion is a required artifact for an IEPD. The following is a simple example of a conformance assertion (in this case, a self assertion by the author, but with assistance from colleagues. The concept is to provide implementers with some information that indicates how well an IEPD has been checked for quality and conformance with respect to XML Schema and NIEM. The assertion can be as simple as the assertion clause. However, clearly the more detail that is provided, the stronger the case for conformance and quality will be.

NIEM releases (and their associated core supplements) and domain updates generally follow a consistent directory organization. When employing a release, its supplements, and updates within IEPDs whether as-is or as subsets, developers are encouraged to maintain their original directory structures. However, aside from applicable rules previously stated in the preceding sections, there are no normative rules for organizing directories within IEPDs.

Guidance for directory structuring may be useful to authors, especially in the case of a relatively simple IEPD with a single schema document subset, and a few extension and external schema documents. The following are common non-normative practices for IEPD directories:

1. Create a root directory for the IEPD from the name and version identifier of the IEPD. For example my_iepd-3.2rev4. (Rule 7-3, IEPD Archive Uncompresses to a Single Root Directory (WF-IEPD), above)
2. For every IEPD, an iepd-catalog.xml artifact (Rule 5-1, IEPD Has an iepd-catalog.xml in its Root Directory (WF-IEPD), above) is required to be in the IEPD root directory

3. If extending the IEPD catalog document, then per Rule 5-3, IEPD Catalog Extension XML Catalog Document in Root Directory (IEPD-catalog), above iepd-catalog-extension-xml-catalog.xml must reside in the same relative directory as the iepd-catalog.xml it supports (normally, the IEPD root directory). iepd-catalog-extension.xsd can be located anywhere in the IEPD because iepd-catalog-extension-xml-catalog.xml correlates its namespace to its URI. However, this specification recommends both artifacts be co-located in the IEPD root directory for visibility:

   • iepd-catalog-extension-xml-catalog.xml (Rule 5-3, IEPD Catalog Extension XML Catalog Document in Root Directory (IEPD-catalog), above)
   • iepd-catalog-extension.xsd

4. Include the following artifacts and ensure each is identified (tagged) appropriately within the IEPD catalog document:

   • readme artifact
   • change log artifact
   • conformance-assertion artifact
   • conformance-report artifact (if present)

   Recommend these artifacts be located in the IEPD root directory.

5. Create the following directories within the IEPD root directory:

   • base-xsd — will contain the NIEM subset and its associated extension, external, and custom NIEM schema documents. These are the NIEM XML schema documents used to validate conformance of an instance XML document. Subdirectories under base-xsd may include:

     • niem — a NIEM schema subset organized as the Schema Subset Generation Tool (SSGT) generates it (including wantlist.xml and xml-catalog.xml artifacts).
     • extension — for NIEM extension schema documents.
     • external — for non-NIEM standards used by the IEPD.
     • niem-custom — for NIEM schema documents that may be customized (extended or restricted) such as structures.xsd.
   • constraint-xsd — will contain constraint schema documents organized as necessary. Usually this schema document set will be organized similarly to schema documents in base-xsd because it is customary to start with the base schema set and constrain it as necessary.
6. If using Schematron, create a schematron subdirectory for any Schematron schemas (or create the appropriate subdirectory name for any other kinds of business rule artifacts).
7. If using specialized XML schema documents for optimized EXI serialization, create an exi-xsd subdirectory for them.
8. Create an iep-sample subdirectory for sample IEPs (Rule 5-43, IEPD Has an IEP Sample for Each c:IEPConformanceTarget (IEPD), above).
9. If more documentation artifacts (e.g., text, graphics, media) are necessary, create a documentation subdirectory for miscellaneous explanatory documentation. As needed, create additional subdirectories within this one to organize documentation artifacts. The readme artifact in the IEPD root directory should refer to or index documentation in this subdirectory.
10. If necessary, create an application-info subdirectory for tool-specific artifacts (inputs, outputs, imports, exports, models, etc.). Again, as needed, use additional subdirectories to organize artifacts of this nature. The readme artifact can and should also refer to or index artifacts in this subdirectory.
11. Maintain a NIEM wantlist within the same subdirectory as the subset it generates (Rule 6-1, Wantlist Location (WF-IEPD), above).
12. Maintain an xml-catalog.xml closest to the XML schema document set it relates to. Use er:nextCatalog elements as needed to help maintain this proximity).
13. Finally, if it becomes necessary to maintain multiple constraint-xsd or extension subdirectories (or any other subdirectories) together in the same directory, then simply suffix each directory name with a distinct character string (for example, extension1, extension2, etc.; or extension-abc, extension-zyx, etc.)

Obviously, there are many other ways to organize for more complex business requirements in which a single IEPD employs multiple releases, core supplements, subsets, constraint sets, and domain updates. Regardless of directory organization and file naming, an IEPD author must always configure all IEP conformance targets using the IEPD catalog c:IEPConformanceTarget element and the appropriate validation artifacts (such as XML catalogs, Schematron schemas, RelaxNG schemas, etc.).

The guidance above results in the IEPD directory structure and naming that appears below. Notes are in parentheses. Filenames within the extension, external, schematron, and iep-sample subdirectories are non-normative examples. Authors are free to assign names for such files according to their own requirements (if they do not violate rules in this specification).

	/my_iepd-3.2rev4			(root directory of IEPD)

		iepd-catalog.xml				(normative artifact name)
		iepd-catalog-extension.xsd
		iepd-catalog-extension-xml-catalog.xml	(normative artifact name)
		changelog.*
		conformance-assertion.*
		readme.*

		/base-xsd

			/niem			(subset)
				/xsd
					/adapters
					/auxiliary
					/codes
						/genc
					/domains
					/external
						/have
						/ogc
					/utility
						appinfo.xsd
						code-lists-instance.xsd
						code-lists-schema-appinfo.xsd
						conformanceTargets.xsd
						structures.xsd
					niem-core.xsd
					wantlist.xml
					xml-catalog.xml

			/niem-custom		(extension/restriction of structures)
				structures.xsd

			/extension
				query.xsd
				response.xsd
				extension1.xsd
				extension2.xsd
				...
				xml-catalog.xml

			/external
				/stix
				/ic-ism
				...
				xml-catalog.xml

		/constraint-xsd			(constraint schema document sets)

			/niem			(constraints on subset)
				/adapters
				/appinfo
				/codes
				/conformanceTargets
				...
				wantlist.xml
				xml-catalog.xml

			/extension		(constraints on extensions)
				query.xsd
				extension1.xsd
				xml-catalog.xml

		/exi-xsd
			gml.xsd
			xs.xsd
			...

		/schematron
			business-rules1.sch
			business-rules2.sch
			...
			
		/iep-sample
			query.xml
			request.xml
			...

		/application-info
			... (tool inputs, outputs, etc.)

		/documentation
			... (human readable documentation)

[BCP 14]: Internet Engineering Task Force Best Current Practice 14. Available from https://www.ietf.org/rfc/bcp/bcp14.txt. BCP 14 is composed of:

[FEA Data Reference Model 1.0]: The Federal Enterprise Architecture Data Reference Model, Version 1.0, September 2004. The version 1.0 document is longer publicly available. A more recent DRM Version 2.0, 17 November 2005 is available from https://obamawhitehouse.archives.gov/sites/default/files/omb/assets/egov_docs/DRM_2_0_Final.pdf

[GJXDM IEPD Guidelines 1.1]: GJXDM Information Exchange Package Documentation Guidelines, Version 1.1, Global XML Structure Task Force (GXSTF), 2 March 2005. Available from http://it.ojp.gov/documents/global_jxdm_IEPD_guidelines_v1_1.pdf

[ISO 11179-4]: ISO/IEC 11179-4 Information Technology — Metadata Registries (MDR) — Part 4: Formulation of Data Definitions Second Edition, 15 July 2004. Available from http://standards.iso.org/ittf/PubliclyAvailableStandards/c035346_ISO_IEC_11179-4_2004(E).zip.

[ISO RelaxNG]: Document Schema Definition Language (DSDL) — Part 2: Regular-grammar-based validation — RELAX NG, ISO/IEC 19757-2:2008, Second Edition, 15 December 2008. Available from http://standards.iso.org/ittf/PubliclyAvailableStandards/c052348_ISO_IEC_19757-2_2008(E).zip. See also http://relaxng.org.

[ISO Schematron]: Document Schema Definition Languages (DSDL) — Part 3: Rule-based validation using Schematron, ISO/IEC 19757-3:2020, Third Edition, 2020-06. Available from https://www.iso.org/standard/74515.html.

[Logical Entity Exchange Specifications]: Logical Entity Exchange Specifications, Version 5.0, 12 October 2016. Available from https://it.ojp.gov/NISS/iepd/457.

[NIEM Code List Specification]: Webb Roberts, ed. National Information Exchange Model Code Lists Specification, Version 4.0, NIEM Technical Architecture Committee (NTAC). Available from https://reference.niem.gov/niem/specification/code-lists/4.0/.

[NIEM Conformance Specification]: National Information Exchange Model Conformance Specification, Version 5.0, NIEM Technical Architecture Committee (NTAC). Available from https://reference.niem.gov/niem/specification/conformance/5.0/.

[NIEM Conformance Targets Attribute Specification]: NIEM Conformance Targets Attribute Specification, Version 3.0, NIEM Technical Architecture Committee (NTAC). Available from https://reference.niem.gov/niem/specification/conformance-targets-attribute/3.0/.

[NIEM High-Level Version Architecture]: NIEM High Level Version Architecture (HLVA), Version 3.0, NIEM Technical Architecture Committee. Available from https://reference.niem.gov/niem/specification/high-level-version-architecture/3.0/.

[NIEM Naming and Design Rules]: Webb Roberts. National Information Exchange Model Naming and Design Rules, Version 5.0, NIEM Technical Architecture Committee (NTAC). https://reference.niem.gov/niem/specification/naming-and-design-rules/5.0/.

[NIEM SSGT]: NIEM Schema Subset Generation Tool (SSGT). Available from http://tools.niem.gov/niemtools/ssgt/index.iepd.

[NIEM TechHub]: NIEM's TechHub provides the developer community with resources and training that will help them use NIEM. Available from https://niem.github.io/.

[NIEM Template IEPD repository]: The NIEM Template IEPD can be used as a starting point or a reference for developing a new IEPD. Available from https://github.com/NIEM/Template-IEPD/.

[XML Catalogs 1.1]: XML Catalogs, Organization for the Advancement of Structured Information Standards (OASIS) Standard v1.1, 7 October 2005. Available from https://www.oasis-open.org/committees/download.php/14809/std-entity-xml-catalogs-1.1.html.

[PKZIP]: APPNOTE.TXT - .ZIP File Format Specification, Version: 6.3.2, Revised: 28 September 2007, Copyright (c) 1989 - 2007 PKWare Inc. Available from http://www.pkware.com/documents/casestudies/APPNOTE.TXT.

[Principles of Data Integration]: Doan, A., Halevy, A., and Ives, X. (2012), Principles of Data Integration, New York, NY: Morgan Kaufmann.

[RFC 3986 URI]: Berners-Lee, T., et al., Uniform Resource Identifier (URI): Generic Syntax, Request for Comment 3986, Network Working Group, January 2005. Available from http://tools.ietf.org/html/rfc3986.

[RFC 3987 IRI]: Duerst, M., and Suignard, M., Internationalized Resource Identifiers (IRIs), Request For Comment 3987, January 2005. Avalailable from http://tools.ietf.org/html/rfc3987.

[EXI Format 1.0]: Efficient XML Interchange (EXI) Format, Version 1.0 (Second Edition), W3C Recommendation, 11 February 2014. Available from http://www.w3.org/TR/2014/REC-exi-20140211/.

[W3C XML 1.0]: Extensible Markup Language (XML), Version 1.0, Fifth Edition, W3C Recommendation 26 November 2008. Available from http://www.w3.org/TR/2008/REC-xml-20081126/.

[W3C XML InfoSet]: XML Information Set, Second Edition, W3C Recommendation 4 February 2004. Available from http://www.w3.org/TR/2004/REC-xml-infoset-20040204/.

[W3C XML Namespaces]: Namespaces in XML 1.0, Third Edition, World Wide Web Consortium 8 December 2009. Available from https://www.w3.org/TR/2009/REC-xml-names-20091208/.

[W3C XML Schema Part 2 Datatypes]: XML Schema Part 2: Datatypes, Second Edition, W3C Recommendation 28 October 2004. Available from http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/.

[W3C XML Schema Part 1 Structures]: XML Schema Part 1: Structures, Second Edition, W3C Recommendation 28 October 2004. Available from http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/.

[W3C XPath 3.1]: XML Path Language (XPath) 3.1, W3C Recommendation 21 March 2017. Available from https://www.w3.org/TR/2017/REC-xpath-31-20170321/.

[XSLT 1.0]: XSL Transformations (XSLT), Version 1.0, W3C Recommendation 16 November 1999. Available from http://www.w3.org/TR/1999/REC-xslt-19991116.

[XSLT 2.0]: XSL Transformations (XSLT), Version 2.0, Second Edition, W3C Recommendation 21 April 2009. Available from https://www.w3.org/TR/2009/PER-xslt20-20090421/.

[XSLT 3.0]: XSL Transformations (XSLT), Version 3.0, W3C Recommendation 8 June 2017. Available from https://www.w3.org/TR/2017/REC-xslt-30-20170608/.

• artifact: Section 2.3, Artifacts
• artifact set: Section 2.3, Artifacts
• business rule schema: Section 6.2, Business Rules
• business rules: Section 6.2, Business Rules
• change log: Section 5.3, Change Log
• conformance assertion: Section 5.7, Conformance Assertion
• conformance target: Section 3.1, Conformance Target Terminology
• conformance target identifier: Section 3.1, Conformance Target Terminology
• constraint rule: Section 2.8, Rules
• constraint schema document set: Section 4.5, Constraint Schema Document Sets
• data component: Section 2.7, Reference Schema Documents
• extension schema document: Section 4.3, Extension Schema Documents
• external adapter type: Section 4.4, External Schema Documents
• external schema document: Section 4.4, External Schema Documents
• full NIEM information exchange package: Section 3.2.2, IEP Conformance Targets
• IEP conformance target: Section 5.6, Defining Information Exchange Packages
• IEPD catalog document: Section 5.1, NIEM IEPD Catalog
• IEPD conformance target identifier: Section 3.1, Conformance Target Terminology
• IEPD root directory: Section 7, Organization, Packaging, and Other Criteria
• information exchange package: Section 3.2.2, IEP Conformance Targets
• information exchange package documentation: Section 3.2.1, Information Exchange Package Documentation
• instance XML document: Section 3.2.1, Information Exchange Package Documentation
• interpretation rule: Section 2.8, Rules
• NIEM wantlist: Section 6.1, NIEM Wantlist
• path name: Section 5.2.4, URI Schemes
• readme artifact: Section 5.4, ReadMe Artifact
• reference schema document: Section 2.7, Reference Schema Documents
• reference schema document set: Section 2.7, Reference Schema Documents
• resolve URI: Section 5.2.4, URI Schemes
• schema component: Section 2.6, XML Validation
• schema document subset: Section 4.2.1, Basic Subset Concepts
• Schematron schema: Section 6.2, Business Rules
• subset schema document: Section 4.2.1, Basic Subset Concepts
• validity constraint context: Section 5.6.1, Validity Context and Constraints
• well-formed IEPD: Section 3.2.1.1, Well-Formed IEPD
• XML catalog document: Section 5.5, XML Catalogs
• XML document: Section 2.6, XML Validation
• XML Schema: Section 2.6, XML Validation
• XML schema assembly: Section 2.6, XML Validation
• XML schema document: Section 2.6, XML Validation
• XML schema validation: Section 2.6, XML Validation
• ZIP file: Section 3.2.1.1, Well-Formed IEPD

• Rule 3-1, IEPD conformance target identifier (IEPD): Section 3.2.1, Information Exchange Package Documentation
• Rule 3-2, IEPD is well-formed (WF-IEPD): Section 3.2.1.1, Well-Formed IEPD
• Rule 4-1, Fundamental NIEM Subset Rule (Schema-subset): Section 4.2.1, Basic Subset Concepts
• Rule 5-1, IEPD Has an iepd-catalog.xml in its Root Directory (WF-IEPD): Section 5.1, NIEM IEPD Catalog
• Rule 5-2, IEPD Catalog Document Valid to iepd-catalog.xsd (IEPD-catalog): Section 5.1, NIEM IEPD Catalog
• Rule 5-3, IEPD Catalog Extension XML Catalog Document in Root Directory (IEPD-catalog): Section 5.1.2, Extending an IEPD Catalog
• Rule 5-4, IEPD Catalog Extension XML Catalog Document Name Is iepd-catalog-extension-xml-catalog.xml (IEPD-catalog): Section 5.1.2, Extending an IEPD Catalog
• Rule 5-5, IEPD Catalog Extension XML Catalog Document Resolves Namespaces to URIs (IEPD-catalog): Section 5.1.2, Extending an IEPD Catalog
• Rule 5-6, IEPD Catalog Extension Schema Document Conforms to NDR Extension Schema Document Rules (IEPD-catalog): Section 5.1.2, Extending an IEPD Catalog
• Rule 5-7, IEPD Catalog Schema and Its Extensions Conform to NDR Schema Set Rules (IEPD-catalog): Section 5.1.2, Extending an IEPD Catalog
• Rule 5-8, IEPD Schema Document Extension Support Schemas Are Supersets of Spec Subsets (IEPD-catalog): Section 5.1.2, Extending an IEPD Catalog
• Rule 5-9, IEPD Version Number Syntax (WF-IEPD): Section 5.2.3, IEPD Version Numbering Scheme (c:iepdVersionID)
• Rule 5-10, IEPD URI Is Absolute (WF-IEPD): Section 5.2.4.1, IEPD URI Scheme (c:iepdURI)
• Rule 5-11, IEPD URI Supports Fragment (WF-IEPD): Section 5.2.4.2, URI Scheme for IEPD Artifacts (c:externalURI)
• Rule 5-12, IEPD URI Has No Fragment (WF-IEPD): Section 5.2.4.2, URI Scheme for IEPD Artifacts (c:externalURI)
• Rule 5-13, IEPD Artifact URI Syntax (WF-IEPD): Section 5.2.4.2, URI Scheme for IEPD Artifacts (c:externalURI)
• Rule 5-14, c:pathURI Resolves to a Resource (WF-IEPD): Section 5.2.4.3, URI Scheme for Local IEPD Artifacts (c:pathURI)
• Rule 5-15, c:pathURI for c:XMLCatalog (WF-IEPD): Section 5.2.4.3, URI Scheme for Local IEPD Artifacts (c:pathURI)
• Rule 5-16, c:pathURI for c:IEPDChangeLog (WF-IEPD): Section 5.2.4.3, URI Scheme for Local IEPD Artifacts (c:pathURI)
• Rule 5-17, c:pathURI for c:ReadMe (WF-IEPD): Section 5.2.4.3, URI Scheme for Local IEPD Artifacts (c:pathURI)
• Rule 5-18, c:pathURI for c:IEPSampleXMLDocument (WF-IEPD): Section 5.2.4.3, URI Scheme for Local IEPD Artifacts (c:pathURI)
• Rule 5-19, c:pathURI for c:BusinessRulesArtifact (WF-IEPD): Section 5.2.4.3, URI Scheme for Local IEPD Artifacts (c:pathURI)
• Rule 5-20, c:pathURI for c:XMLSchemaDocument (WF-IEPD): Section 5.2.4.3, URI Scheme for Local IEPD Artifacts (c:pathURI)
• Rule 5-21, c:pathURI for c:ExternalSchemaDocument (WF-IEPD): Section 5.2.4.3, URI Scheme for Local IEPD Artifacts (c:pathURI)
• Rule 5-22, c:pathURI for c:ReferenceSchemaDocument (WF-IEPD): Section 5.2.4.3, URI Scheme for Local IEPD Artifacts (c:pathURI)
• Rule 5-23, c:pathURI for c:ExtensionSchemaDocument (WF-IEPD): Section 5.2.4.3, URI Scheme for Local IEPD Artifacts (c:pathURI)
• Rule 5-24, c:pathURI for c:SubsetSchemaDocument (WF-IEPD): Section 5.2.4.3, URI Scheme for Local IEPD Artifacts (c:pathURI)
• Rule 5-25, c:pathURI for c:Wantlist (WF-IEPD): Section 5.2.4.3, URI Scheme for Local IEPD Artifacts (c:pathURI)
• Rule 5-26, c:pathURI for c:SchematronSchema (WF-IEPD): Section 5.2.4.3, URI Scheme for Local IEPD Artifacts (c:pathURI)
• Rule 5-27, c:pathURI for c:RelaxNGSchema (WF-IEPD): Section 5.2.4.3, URI Scheme for Local IEPD Artifacts (c:pathURI)
• Rule 5-28, c:pathURI for c:SchemaDocumentSet (WF-IEPD): Section 5.2.4.3, URI Scheme for Local IEPD Artifacts (c:pathURI)
• Rule 5-29, c:pathURI for c:ConstraintSchemaDocumentSet (WF-IEPD): Section 5.2.4.3, URI Scheme for Local IEPD Artifacts (c:pathURI)
• Rule 5-30, Schema document set interpreted as constraint schema document set (WF-IEPD): Section 5.2.4.3, URI Scheme for Local IEPD Artifacts (c:pathURI)
• Rule 5-31, Resolve IEPD URI with Fragment (WF-IEPD): Section 5.2.4.5, Resolving an IEPD URI with a Fragment
• Rule 5-32, XML Catalog uri Value Resolves to Resource (XML-catalog): Section 5.2.4.7, XML Catalog URI
• Rule 5-33, XML Catalog uri Value Resolves to Resource with Correct Target Namespace (XML-catalog): Section 5.2.4.7, XML Catalog URI
• Rule 5-34, IEPD Has a Change Log (IEPD): Section 5.3, Change Log
• Rule 5-35, Readme Describes Purpose, Scope, Business Value, etc. (WF-IEPD): Section 5.4, ReadMe Artifact
• Rule 5-36, IEPD Has a ReadMe Artifact (IEPD): Section 5.4, ReadMe Artifact
• Rule 5-37, Conformance Target Identifier (IEPD-catalog): Section 5.6, Defining Information Exchange Packages
• Rule 5-38, IEP Conformance Target Has a structures:id (IEPD-catalog): Section 5.6, Defining Information Exchange Packages
• Rule 5-39, IEPD Declares One or More IEP Conformance Targets (IEPD): Section 5.6, Defining Information Exchange Packages
• Rule 5-40, Validity contraint context is value of c:xPathText (IEPD-catalog): Section 5.6.2.3, c:ValidityContext
• Rule 5-41, IEP has Document Element (IEP): Section 5.6.2.4, c:HasDocumentElement
• Rule 5-42, Validating an XPath Expression (IEP): Section 5.6.2.5, c:ValidToXPath
• Rule 5-43, IEPD Has an IEP Sample for Each c:IEPConformanceTarget (IEPD): Section 5.6.3, IEP Sample Instance XML Documents
• Rule 5-44, Validating an IEP Sample XML Document (IEP): Section 5.6.3, IEP Sample Instance XML Documents
• Rule 5-45, IEPD Has Conformance Assertion (IEPD): Section 5.7, Conformance Assertion
• Rule 6-1, Wantlist Location (WF-IEPD): Section 6.1, NIEM Wantlist
• Rule 7-1, An IEPD in ZIP File Format Preserves Logical Directory Structure. (WF-IEPD): Section 7, Organization, Packaging, and Other Criteria
• Rule 7-2, XSD and XML Documents Conform to Applicable NDR Conformance Targets (WF-IEPD): Section 7, Organization, Packaging, and Other Criteria
• Rule 7-3, IEPD Archive Uncompresses to a Single Root Directory (WF-IEPD): Section 7, Organization, Packaging, and Other Criteria
• Rule 7-4, Constraint on Elements of Type c:SchemaDocumentSetType (IEPD-catalog): Section 7.1.1, Constraint on Elements of Type c:SchemaDocumentSetType
• Rule 7-5, IEPD ZIP file Name Syntax (IEPD): Section 7.2, IEPD File Name Syntax
• Rule 7-6, IEPD Reference to Resource Uses Common URI Scheme (WF-IEPD): Section 7.3, Artifact Links to Other Resources
• Rule 7-7, IEPD Completeness (IEPD): Section 7.4, IEPD Completeness
• Rule 7-8, IEPD External Schema Documents Are Local Resources (WF-IEPD): Section 7.4, IEPD Completeness
• Rule 7-9, Key IEPD Resources Are Local Resources (WF-IEPD): Section 7.4, IEPD Completeness