This document specifies the National Information Exchange Model (NIEM) version architecture. This specification identifies the processes, artifacts, responsibilities and how they interact to produce new releases of and updates to the NIEM model. This draft establishes a regular schedule for major and minor releases per the new Release Optimization Strategy (approved by the NIEM Executive Steering Council in June 2014).
This document defines the design for versioning that evolved from the collaborative work of the NIEM Technical Architecture Committee (NTAC), and subsequent work of the NIEM Business Architecture Committee (NBAC). The Release Optimization Strategy is a recommendation to the Executive Steering Council (ESC) to allow a regular annual NIEM release as needed. In June 2014 the ESC approved the recommendation. [NIEM High-Level Version Architecture v3.0] supersedes the previous [NIEM High-Level Version Architecture v1.0] dated 31 July 2008.
This specification is a product of the NIEM Program Management Office (PMO).
Email comments on this specification to firstname.lastname@example.org.
This document describes the National Information Exchange Model (NIEM) version architecture at a high level. It describes the approach and the major artifacts involved, without specifying them at a detailed level. This document is intended to frame further discussion and specification efforts, leading to a precise specification in the future.
The version architecture discusses issues that have inherently conflicting tradeoffs. It seeks a balance of concepts drawn from previous NTAC discussions and ideas. Major tradeoffs include:
The HLVA describes how NIEM governance updates the data components and schema documents that comprise a NIEM release. This document is a high-level, abstract form of the eventual specification. It describes, at a high level, topics that will be specified by a complete version architecture.
This specification does not address version management for information exchange package documentation (IEPD). Creation and management of IEPDs is the responsibility of NIEM stakeholders and developers, and processes for IEPD versioning and management are independent of NIEM core and domains. The NIEM PMO defines IEPD conformance, but IEPD development, management, and implementation fall outside its scope. Nonetheless, in the near term the PMO intends to publish guidance (through the NIEM Technical Architecture Committee) for managing IEPDs, versioning IEPDs, and processing their associated information exchange packages (IEP).
This document assumes that the reader is familiar with NIEM and its artifacts. Readers needing additional background on NIEM should refer to documents on the NIEM Web site at http://reference.niem.gov/.
The NIEM is represented as a set of XML Schema documents that define data components. Implementers of information exchange package documentation (IEPD) use these data components to define information exchange packages (IEP) that will be transmitted in an implementation. The goal of NIEM is to define common data components that are highly reusable, to improve the economy of implementing information exchanges, to increase comprehension of those exchanges, and to reduce errors in exchanges.
The NIEM Technical Architecture Committee (NTAC) and the NIEM Business Architecture Committee (NBAC) govern NIEM architecture and content respectively. The NBAC and NTAC may appoint standing subcommittees and transitory tiger teams who take responsibility for specific issues. NTAC and NBAC make technical recommendations to the NIEM Program Management Office (PMO). The PMO is the operational body that directs and executes NIEM daily operations, development, maintenance, and public relations. The Executive Steering Council (ESC) is the senior executive level group that reviews and approves major NIEM directions and activities.
The aggregation of the Executive Steering Council (ESC), the NIEM Program Management Office (PMO), the NIEM Technical Architecture Committee (NTAC), and the NIEM Business Architecture Committee (NBAC).
A NIEM domain is sometimes associated with or managed by an organization independent of NIEM, and may have its own rules, procedures, schedule, and priorities. The data components that make up NIEM are published as a set of NIEM releases. Each NIEM release is composed of a set of schema documents that include a NIEM core schema document, special infrastructure schema documents (
appinfo.xsd), multiple domain schema documents, and code table schema documents. Each domain or code table schema document has a body of domain representatives that is responsible for its content and maintains its own timeline for updates and publication. For this document, the term domain applies to both domain and code table working groups.
The NIEM High Level Version Architecture (HLVA) described by this document is meant to achieve the following objectives:
There is a reliable schedule for
Providing schedules ensures that participants in the activities know when their input is due and timelines for required work. It also ensures that release users can plan for release dates.
The following are not objectives of the NIEM High Level Version Architecture (HLVA):
The HLVA provides a framework for changes to be performed, in a systematic way, on a set of artifacts. These are outlined in subparts of this section. The activities that lead to changes in the schema documents and other artifacts are driven by a desire to improve the model. Improvements include correcting errors, meeting previously unforeseen requirements, and adapting to new needs and new uses of the model. One concern is how we define improvement to the model. A common term for improving systems is harmonization, a term which we adopt for this effort.
Harmonization (of a schema document or set of schema documents) is the process of modifying a schema document set in an incremental fashion for the purpose of improving the quality of the schema document set with respect to some criteria. For example, a schema document set may be harmonized to reduce semantic overlap of its components. A schema document set may also be harmonized to ensure uniformity of the vocabulary used in definitions of its components.
Harmonization may be conducted within a single schema document, or may be conducted across multiple schema documents of a schema document set.
The version architecture does not anticipate that NIEM will ever be completely harmonized (a theoretically perfect state for a schema document set, in which all components perfectly satisfy all criteria). In practice, a fully harmonized state is never reached, and the goal of harmonization is incremental improvement, rather than perfection.
This section outlines the basic structure of the architecture. Many details are in later sections.
There are several classes of information that are employed by the version architecture. They are defined as follows:
As defined by [NIEM MPD Specification 3.0.1]:
- includes a set of logically cohesive W3C XML Schema documents and other supporting files that represent one or more reusable or implementable XML information models, and
- has an MPD class of
- adheres to all the rules in [NIEM MPD Specification 3.0.1] for the model package description conformance target.
This term may be abbreviatedMPD.
An MPD that is a set of schema documents published by the NIEM PMO. Each schema document defines data components for use in information exchanges. A release should:
A NIEM release can be any one of three types:
A NIEM release in which the NIEM core has not changed from previous releases in the series, but at least one or more domain reference schema documents have changed. A second integer greater than zero in the version number indicates a minor release (for example, NIEM version 2.1). Note also that major version 2.0 and minor version 2.1 are in the same series (i.e., series 2) and contain the same NIEM core schema document.
A NIEM release in which neither the NIEM core nor the domain reference schema documents have changed from the previous major or minor release, but one or more new reference schema documents have been added (without impact to domain or core schemas). A third integer greater than zero in the version number indicates a micro release (for example, NIEM version 2.1.1; note that this release does not currently exist).
A published update is a schema document or set of schema documents that is issued by a NIEM domain or NIEM governance body. An update may be new content or may be an update of content that was previously included in a NIEM release. A published update may define new versions of content from NIEM release or other published content. The issuing body vets each update before publication, but the update is not subject to review by other NIEM bodies. A published update must be conformant, but otherwise it has fewer constraints on quality than does a NIEM release.
There are currently two kinds of published updates in NIEM:
A special NIEM release MPD that adds or supplements components in an existing (i.e., previously published) NIEM core within a NIEM release. A core supplement is published to the publication area by the NIEM PMO (at the recommendation of NBAC and NTAC). A core supplement is additive or supplemental in nature; it cannot replace or modify components in a published NIEM core.
Through review and usage of published releases, potentially new or missing requirements, flaws, or other concerns will be identified in NIEM. These issues are recorded for review, discussion, and action (as needed) by NIEM governance.
Users of NIEM schema documents and components will find problems that should be addressed. These will include erroneous syntax or definitions, inconsistencies between different parts of the model, and new requirements that are not yet satisfied. A NIEM issue is a record of one of these problems. An issue’s record may include discussion of the problem, possible solutions, and changes to the model required to resolve the problem.
There are several data stores in the architecture. General terms are used here, to avoid introducing any requirements or restrictions associated with an existing tool, such as a registry, repository, or specific Web software such as Bugzilla or Sharepoint. This description seeks only to describe requirements and functionality for these data stores.
A tool or network location that supports registration, modification, and collaborative discussion of issues pertaining to NIEM schema documents, concepts, data components, and other artifacts. (This may be or may include the NCCT - NIEM Configuration and Control Tool.)
A tool or network location that supports cooperative editing of artifacts, as well as discussion by domains and other NIEM working groups. Each domain or working group receives its own partition within the collaboration area. Partitions are private; access to each is restricted to members of the appropriate working group.
There are five major activities involved in managing versions of NIEM. domain representatives, NBAC, and NTAC engage in these processes as they improve and extend NIEM.
A process through which NBAC initiates tiger teams and working groups to resolve inconsistencies, overlaps, and other semantic issues between the domains, and between the domains and core. The results of these efforts will go into the issue tracking area, to be included in the next appropriate major or minor release.
The NIEM versioning process contains several activities, performed by various parties. This section walks through these activities, and highlights the inputs and outputs of each. Each activity and artifact is discussed in more detail in later sections.
The following is a brief high-level walkthrough of versioning, and describes the processes diagrammed in Figure 3-1, Activity flow for the NIEM versioning processes., above. The items numbers are keyed to the diagram.
0, such as
4.2. For those issues that are not resolved via domain reconciliation, issues in the issue tracking area are updated, created, and closed, as appropriate.
0, such as
This section contains further discussion and details of the major activities of the NIEM version architecture.
In response to these issues, domains publish domain updates to their namespaces. They identify and define new content that they require. They define and update code tables that they require. These updates are published in the domain partitions of the publication area.
The NIEM Business Architecture Committee (NBAC) reconciles these requests with the latest published release, in order to produce a coherent NIEM schema document set. This reconciliation will result in a schema document set that is easily used by IEPD developers.
The NBAC makes decisions on how to accommodate changes. In the publication area, domains publish updates prior to NBAC approval, ensuring autonomy of the domains. The NBAC determines how best to migrate these updates into the next minor release. The NBAC conducts domain reconciliation annually.
This reconciliation process will consist of the following stages:
Gather and prepare input to the reconciliation process.
This input will come from open issues in the issue tracking area, and from domain partitions of the publication area. The content of the publication area will be evaluated for impacts. Reports will be prepared that may include:
Reports containing technical metrics that quantify the
Starting with the previous NIEM release, the NBAC will review and apply the changes that were requested by the domains. For each proposed domain update, approve the update, or modify it as required to maintain high quality across all NIEM schema documents.
When a change is applied, make modifications in other domains, as required, to keep the schema document set coherent. Where domain updates introduce integrity issues, modify the schema document set to eliminate those problems. Propagate domain updates through impacted namespaces, as appropriate.
Note that there is no requirement or implication that any harmonization will be done by tools, or automatically in any way. The goal of this architecture is to ensure that the responsible party has the authority, schedule, goal, and ability to do what is needed to ensure that domain changes result in a coherent set of domain schema documents that can easily be used in IEPDs.
Through the process of domain reconciliation, the NBAC will resolve many issues of cross-domain conflict. This may include changes to one domain that affect another domain, or overlaps of content between domains. Through the reconciliation process, the NBAC will make adjustments as-needed to ensure that domain updates do not harm the quality of the NIEM release as a whole.
During its periodic domain reconciliation, the NBAC may conduct additional harmonization. Issues addressed may be
low hanging fruit, such as particularly easy or notable problems. Or, the NBAC may try to resolve one or more aspects of harmonization across the NIEM model, such as vocabulary consistency. During reconciliation, it is likely that time will be short, and the level of effort will be limited. So, during reconciliation, extremely broad changes would be avoided, as would changes that required significant consideration by subject matter experts. Such issues would be handled by tiger teams and small groups in a separate process referred to as cross-domain harmonization.
The NBAC, as the designated body for harmonization, may make any decision that it deems prudent to integrate domain updates with the previous NIEM release. This may include the modification of dependent namespaces to accommodate domain changes, the creation of new elements for indirect (substitution) methods, and the modification of definitions and component names.
The NBAC may also choose to reject, in whole or in part, any domain update. The rejected domain content is still available (without change) in the publication area. However, it will not be part of domain reconciliation, and will not be included in future NIEM releases. The NBAC has the responsibility to act in the best interest of the entire NIEM community; it rejects domain content only to protect community interests, and it provides written justification when doing so.
This document uses the term coherence to describe whether components of a schema document set refer to each other in a consistent manner:
A schema document set is coherent when it has the following properties:
The coherence of a NIEM schema document set is best described by comparing a set that is not coherent with one that is. Imagine the following sequence of events, leading to the situation in Figure 4-1, A schema document set that is not coherent, below:
ThingIDcomponent within a Domain A component.
The schema document set in Figure 4-1, A schema document set that is not coherent, above, is not coherent, because it contains two versions of the same element: the new
ThingID element in
domainB-2, and the old
ThingID element used in
domainA-1. This is a duplication of semantics.
An IEPD with schema document sets that are not coherent can require significant work to make its schema documents work together. For example, the IEPD author might design an extension namespace to duplicate the changes to
domainB-1:ThingID that distinguishes it from
domainB-2:ThingID. These changes would likely cascade to related XML types, and similar changes would be required for each incompatibility between versions. Such an environment, in which many domains are updating frequently, will ultimately present IEPD developers with substantial problems.
This problem will be resolved when Domain A publishes version 2 of its content, taking care to reuse components from version 2 of Domain B. Afterwards, the IEPD developer using the latest versions of Domains A and B will be working with the coherent schema document set shown in Figure 4-2, A coherent schema document set, below.
Such a schema document set would not require custom extensions to fix problems related to incoherence. A later version of the version architecture specification will address specific rules for and the structure of version identifiers in the domain schema documents. For example, it may be desirable for version identifiers for
bumped namespaces to be easily distinguished from version identifiers for domain-initiated changes.
When a domain has created its updated content, it may determine that the content should be released as a coherent NIEM release. This will be verified by tools that check conformance and coherence of the resulting schema document set. Once these checks are complete, a domain may wish to publish its update directly as a NIEM micro release in the release area, rather than as a published update in the publication area. To do so, the domain must request and receive NBAC approval.
Schemas published in this manner may be more durable than schema documents published to the publication area. That is, schema documents so published may work better with more versions of NIEM. NIEM releases will not refer to schema documents in the publication area; schema documents from the publication area are reconciled and modified before their release, and they receive new target namespace URIs. Schemas published directly to releases avoid reconciliation. They also will not have to be modified as they go from the publication area to the release area, as they avoid the first step. A prime candidate, and simple example, of this method is a code table. By defining a code element such that it is substitutable for an element from a NIEM release, multiple versions of a schema document set may be usable at the same time. A new version of such a code table may be released as part of a NIEM micro release without requiring rework of other schema documents. NIEM micro releases require tools for validation and verification. They also require a commitment to frequent NIEM releases, with limited vetting.
Larger and deeper issues of semantic consistency and modeling will be addressed by tiger teams and small groups of subject matter experts, as determined by the NBAC. The tasks to be undertaken by these cross-domain harmonization teams typically do not require participation from the entire NBAC. The use of such teams will enable parallel harmonization efforts. This will result in greater scalability, as the number of domains increase.
The products of cross-domain harmonization will include:
Periodically, these products will be synchronized with core content, to produce a new major release. A major release will contain a new NIEM core namespace. A major release is the opportunity to change the existing core content by removing or altering core components. At the time of a major release, other major changes to the NIEM release schema document set may be considered by the NBAC, such as changes to
appinfo, which are schema documents that are part of the NIEM infrastructure. For more information on
appinfo, see the [NIEM NDR] and other documents on the NIEM Web site at http://reference.niem.gov/.
NIEM core synchronization will occur every third year. However, a NIEM core synchronization may be held back for a longer period if changes to be released do not meet certain thresholds in terms of volume or severity. The NBAC must balance the need for regular scheduled releases with the set of components that must be harmonized across domains for inclusion into the core.
In between updates to NIEM core, the NBAC may add core content via additional components in additional schema documents in a minor release of NIEM, without updating the NIEM core schema document. These would be additive changes only, and would not modify the original NIEM core schema document in any way.
A NIEM release has the following properties:
There are two types of harmonization/reconciliation:
Domain-synchronized NIEM releases are given minor release version numbers. NIEM core-synchronized NIEM releases are given major release version numbers. Direct releases due to domain updates are given micro release numbers.
When core synchronization occurs, the results are published as a NIEM major release. These releases will be given identifiers such as 2.0, 3.0, and 4.0. These releases will yield a NIEM core namespace that has the same version identifier as the NIEM release.
When domain reconciliation occurs, without update of the NIEM core namespace, the results are published as a NIEM minor release. These releases have identifiers such as 2.1, 2.2, 2.3, 3.1, 3.2, and 3.3. When a domain update process occurs without reconciliation, the domain may request from NBAC a new release that incorporates that update, and the results are published as a NIEM micro release. These releases have identifiers such as 2.1.1, 2.1.2, 2.2.1, and 2.2.2.
For NIEM release identifiers, major releases have two integers (e.g., 2.0). The major integer (2), and the minor integer (.0). The minor release following 2.0 is 2.1. The micro release following 2.1 is 2.1.1. There is no version 2.1.0.
For NIEM release identifiers, the value following 2.9 is 2.10. Each number (major, minor, or micro) is a field storing an integer, not a single digit.
The version identifiers for released domain schema documents (in the release area) and published schema documents (in the publication area) are not described by this HLVA. Constraints on these identifiers have not yet been determined, and will be specified fully in future version of the version architecture specification.
The version architecture defines several areas in which artifacts of NIEM are stored. Each may be implemented using new or existing tools. The goal of this document is to describe the areas, what information they contain, and what functionality is needed to support activities that use these areas.
The specific software and tools that make up these data stores are not specified by this document. Such specifications will be detailed by later documents.
All releases of NIEM are published to the release area.
All schema documents published to the release area are persistent, and are available for immediate use by IEPD developers and other users.
A single schema document may be a part of multiple releases. For example, a single release of the NIEM core namespace will be a part of one or more minor releases. The release area will provide metadata to make clear exactly which schema documents are associated with which releases. This metadata is referred to as the release manifest. The format of this metadata is yet to be determined. The release area is http://release.niem.gov/.
The collaboration area supports cooperative editing of artifacts, as well as discussion by domains and other NIEM working groups. Each domain or working group receives its own partition within the collaboration area.
These partitions are private, as access to each partition is restricted to the members of the appropriate working group.
The precise mechanics and content of the collaboration area are to be determined.
All content of the publication area is persistent. That is, it never goes away once it is published. Also, it is never modified. Revised versions of published content may also be published, however, no artifact is removed or revised. This ensures that all content of the publication area may be freely used by any development effort, without fear of it changing or disappearing. All content of the publication area is available for use by IEPD developers, as well as developers of other schema documents and applications.
Each domain and working group controls a partition of the publication area. This partition is the publication site for products of the working group. The domain may place any number of schema documents into its publication area.
The schema documents in NIEM 2.0 contained schema documents that superseded the schema documents in NIEM 1.0. Schema documents in the domain publication areas are not required to supersede older schema documents in this manner. Instead, schema documents in the publication area may extend schema documents in previous NIEM distributions. This may make domain updates easier to use by IEPDs. For example, suppose domain
JXDM wishes to add an element
ArrestSubject to the type
ArrestType that occurred in JXDM-4.0. It may publish a schema document in its publication area that extends the JXDM 4.0
ArrestType. This extension may then add
ArrestSubject to the
ArrestType. A substitutable element may be made to provide for the new
ArrestType to be used in IEPDs.
Extensions made in the manner above may be easier for IEPDs to use than replacement components. When a domain publishes an update as an extension of the latest release, that update may be easier for an IEPD to use than if it was published as a replacement of the latest release.
The specific method used in a domain update is left for the domain to determine. Some domains may choose to replace components, while others may extend components. It is expected that best practices will be determined over time. Best practices may vary from domain to domain, as some domains may prefer to use common extensions, while others may prefer that each IEPD do its own integration work.
Each schema document that is posted to the publication area will have a namespace that meets several criteria.
Each schema document in the publication area has a target namespace that is distinct from that of all other schema documents. There will not be two different schema documents in the publication area with the same namespace, nor will there be a schema document in the publication area with the same namespace as a schema document in a NIEM release.
Each schema document in the publication area is persistent. Like the schema documents in NIEM releases, once published, the schema documents will not go away. These schema documents will remain available for use by IEPDs.
Schema documents in the publication area will be accompanied by change logs, which give comprehensible descriptions of the changes that were made to schema documents. This is discussed in Section 7.2, Change Log, below.
NIEM currently conducts NIEM issue tracking using the NIEM Configuration Control Tool (NCCT). This is an issue tracking system with forums for the NTAC, NBAC, and domains. This document uses the more general terminology
The purpose of the issue tracking area is to capture and track requirements and problems from end users, developers, domains, and other people and bodies associated with NIEM. Although issues come from users, whether or not users will directly interact with the issue tracking area is yet to be determined. Issues may be entered by a helpdesk, in order to ensure that duplicates are not entered, and that issues are specified fully and clearly, so that additional work is not created downstream.
The issue tracking area may include a conventional issue tracking system as well as forums/bulletin boards for discussing issues. Each domain and working group may be given a partition of the issue tracking area, as needed. These groups will have control over their issues, and may dispatch them and resolve them as desired.
To be determined is whether a domain may also have issue tracking systems and methods outside the NIEM-provided issue tracking area. This will reduce transparency, and may impair cooperation between working groups. It may also increase error when moving issues from one body to another.
An artifact that describes the changes applied to an MPD since its previous version.
A change log is able to express a single big change that is composed of a set of small changes. For example, the renaming of an element may include changes to many types that used that element.
Without a change log, changes made between versions of a schema document would not include an expression of what the changes to the schema document might mean. Although the revised schema document may be fully formed and well defined, it may be unclear what impact the change might have on other schema documents.
For example, upon renaming an element (from an old name to a new name), the change is represented in XML Schema by the original element (with the old name) not appearing in the revised schema document, and a new element (with the new name) appearing in the revised schema document.
A type in another domain may be impacted by this change. If the type used the original element with the old name, it would be unclear what changes should be made to the type to accommodate the renaming.
In order to describe changes to schema documents with enough detail to enable reconciliation, schema document definitions are accompanied by metadata that describe changes. This metadata will include a list of changes, without restating the details that occur in the schema documents that are in the publication area.
The mechanics and format of the change log are to be determined. The format will be in XML, and may include XPath expressions for relating change log entries to updated schema documents. The change log XML file may describe the following about each change made by a domain:
Users will be able to audit change logs against schema document updates to look for
Through the NBAC's domain reconciliation process, it may be determined that some namespaces must be adjusted to accommodate changes to other namespaces. That is, although the domain has no new updates for its namespace, the NBAC must change the domain namespace to accommodate changes in other domains. In this situation, we say that the domain namespace was bumped.
The version architecture does not allow the application of changes directly to a published namespace. A changed schema document must be given a new target namespace URI. So, when a domain namespace is bumped, it must be given a new namespace URI.
An artifact that specifies the new target namespace URI for a new schema document resulting from the need to bump it.
There are several goals for the namespace URI directive:
The namespace URI directive allows the domain to express the structure of its target namespace URIs, and the sequence of version identifiers. The domain will be able to specify how namespace URIs are incremented when the namespace is updated or bumped.
The NIEM version architecture is designed to be agile, accommodate regular change, and respond efficiently to stakeholder requirements. To do so, NIEM maintains the ability to execute predictable, repeatable, and consistent release cycles, while also allowing its domains to publish updates independently (on their own timelines). At a high level, this section describes the timelines, coordination, and options for major and minor release cycles.
NIEM will generally publish an annual release in the same quarter of each year. The normal target is the third quarter of the Government fiscal year (subject to change as determined by NIEM goverance and the PMO). Within each three-year period, the NIEM program will execute two consecutive minor release cycles, followed by a major release cycle.
A release date will be scheduled (internally established by the PMO) for the beginning of the target quarter. The release date may shift later in the quarter if necessary. This adds a degree of flexibility and safety to the schedule to accommodate additional pre-release phases (e.g., Beta2 or beta3) or other unforeseen events, while still maintaining consistency and predictability. NIEM PMO will communicate anticipated scheduling details to the NIEM Community for planning.
If required to meet schedule, a release cycle may be time-boxed or content-scoped (or both).
For each release cycle, the PMO will assign a release coordinator selected from the major stakeholders. The release coordinator will monitor and report progress to PMO, NTAC, NBAC, and domains, resolve issues of schedule and scope, and coordinate participating entities (NIEM governance, domains, release manager, etc.).
Ordinarily NIEM will not issue a minor release for a previous major version series (such as version 2.0). However, a request by a domain (or other entity) to issue a minor release for such (e.g., a request for a Version 2.2) will be jointly considered by PMO, NBAC, and NTAC. If approved, it will be executed between annual release cycles (since the scope of change is expected to be small).
A typical NIEM release cycle is comprised of three basic stages of development, each of which may require several iterations. These are defined as follows:
The initial stage of a release cycle. Primary activities focus on integrating architectural improvements (if any) as well as domain and core content changes previously prepared as domain and core supplements since the last release. Other activities include reconciliation, core synchronization (when appropriate), appropriate types of harmonization, refactoring/refinement of content as needed, application of resolved issues, and iterative NIEM governance reviews and feedback. The most significant types, volume, and scale of changes occur during alpha stage.
The midterm stage of a release cycle. At the beginning of this stage the developing release has stabilized to the degree that remaining changes are minor — major adjustments for architecture have been completed; no significant new content may be integrated; release schemas are in a state that will allow user beta testing (i.e., the release is expected to be NIEM-conformant). Changes are still allowed; however, these are much smaller in magnitude and complexity and are generally only corrections and adjustments. Examples of beta stage changes include adjustments to data component structure; movement of properties; renaming and redefining; addition or refinement of keyword, usage, and example metadata (associated with definitions); addition of a very small number new components (essentially inadvertent omissions or additions needed to adjust structure), and occasionally very minor corrections to architecture. If beta testing, reviews, and feedback discover major flaws that require significant changes, then the release may revert back to the alpha stage.
The final stage of a release cycle. A release candidate should be identical to, and therefore is a potential final production (i.e., operational) release. Only extremely minor corrections to a release candidate are allowed. These include minor corrections to character strings, names, definitions, namespaces, etc. At this stage absolutely NO architectural or significant content changes are allowed. Any such changes will require regenerating the release as a beta product. Activities during this stage are essentially only testing, review, feedback, and possibly very minor refinements. As this is the final review, diligence must ensure quality and conformance before publication. If testing, reviews, and feedback discover flaws that require significant changes, then the release may revert back to the beta, or even alpha stage. Very minor refinements to a release candidate will require regenerating it as a new release candidate.
Any time period during which the NIEM program is NOT executing a release cycle, i.e., the time period after the last release cycle ends to before the next begins. Pre-alpha activities may include (but are not limited to): production of domain updates and core supplements; identification and resolution of issues, identification of new requirements, refactorization of NIEM objects, and essentially any other activity that can be performed in a preparatory manner before a release cycle begins, and recorded into the issue tracking area and subsequently applied in the next appropriate release cycle.
Pre-alpha activities significantly reduce the surge activity often perceived or occurring with a release cycle. The need for a significant spike in resources during a NIEM release cycle is generally a myth; most often it is the result of postponement or procrastination of the regular pre-alpha activities that should always be common practice in NIEM governance.
Based on history, two minor releases and one major release in a three-year period (each release cycle executed annually) will generally accommodate the expected demand for future model changes. So, by default the appropriate release will always be planned each year without the need for prior approvals.
There is no desire to force unnecessary releases. Therefore, as circumstances demand, the NTAC, NBAC, domains, and the PMO may jointly evaluate conditions and elect to adjust the schedule as needed. Special options include:
Figure 8-1, The NIEM Three Year Cycle., below, illustrates a typical NIEM three-year period. The following notes explain the activity tracks within the diagram:
Although face-to-face governance meetings are extremely valuable for release planning, coordination, harmonization, and issue resolution, they are not absolutely necessary. In the event that face-to-face meetings cannot be held, teleconferences, collaboration tools, and other means will be sufficient to execute a release.
Under the NIEM version architecture, domains are free to publish updates on their own timelines, without being required to wait for NIEM governance or other domains to act. The architecture ensures that all such updates are available for use in IEPDs or other uses of NIEM schema documents. The architecture ensures that NIEM releases will be available to developers at regularly scheduled intervals, and that those releases will be easy to use, and free of structural inconsistency.
The version architecture also ensures that domain changes are available in a concrete form that may be incorporated into the next NIEM release. It also ensures that NIEM releases are scheduled such that they may incorporate recent domain changes. NIEM governance has authority to make required modifications in order to ensure consistency between the domains and core.
This document has described the NIEM version architecture at a high level. The high level description will be expanded and refined into a specification. The specification will detail the processes, activities and artifacts that are required to maintain high-quality and transparent change management for NIEM.
|Acronym / Abbreviation||Literal or Definition|
|ESC||Executive Steering Council|
|HLVA||High Level Version Architecture|
|IEP||Information Exchange Package|
|IEPD||Information Exchange Package Documentation|
|MPD||Model Package Description|
|NDR||Naming and Design Rules|
|NIEM||National Information Exchange Model|
|NBAC||NIEM Business Architecture Committee|
|NCCT||NIEM Configuration Control Tool|
|NTAC||NIEM Technical Architecture Committee|
|PMO||Program Management Office|
|SSGT||Schema Subset Generation Tool|
|URI||Uniform Resource Identifier|
|W3C||World Wide Web Consortium|
|XML||Extensible Markup Language|
|XSD||XML Schema Definition|
[NIEM Conformance]: NIEM Conformance, Version 3.0, NIEM Technical Architecture Committee (NTAC), 15 August 2014. Available from http://reference.niem.gov/niem/specification/conformance/3.0/.
[NIEM Conformance Target Attribute Specification]: NIEM Conformance Targets Attribute Specification, Version 3.0, NIEM Technical Architecture Committee (NTAC), 31 July 2014. Available from http://reference.niem.gov/niem/specification/conformance-targets-attribute/3.0/.
[NIEM Domain Update Specification]: NIEM Domain Update Specification, Version 1.0, NIEM Technical Architecture Committee (NTAC), 5 November 2010. Available from http://reference.niem.gov/niem/specification/domain-update/1.0/.
[NIEM High-Level Tool Architecture]: NIEM High-Level Tool Architecture, Version 1.1, NIEM Technical Architecture Committee, 1 December 2008. Available from http://reference.niem.gov/niem/specification/high-level-tool-architecture/1.1/.
[NIEM High-Level Version Architecture v1.0]: NIEM High Level Version Architecture (HLVA), Version 1.0, NIEM Technical Architecture Committee, 31 July 2008. Available from http://reference.niem.gov/niem/specification/high-level-version-architecture/1.0/.
[NIEM High-Level Version Architecture v3.0]: NIEM High Level Version Architecture (HLVA), Version 3.0, NIEM Technical Architecture Committee, 27 April 2015. Available from http://reference.niem.gov/niem/specification/high-level-version-architecture/3.0/.
[NIEM Implementation Guide]:
NIEM Implementation Guide, NIEM Program Management Office. Available from https://www.niem.gov/aboutniem/grant-funding/Pages/implementation-guide.aspx.
[NIEM MPD Specification 3.0.1]: NIEM Model Package Description (MPD) Specification, Version 3.0.1, NIEM Technical Architecture Committee (NTAC), 27 April 2015. Available from http://reference.niem.gov/niem/specification/model-package-description/3.0.1/.
[NIEM MPD Toolkit]:
NIEM Model Package Description Toolkit, Version 3.0, NIEM Technical Architecture Committee (NTAC), 15 August 2014. Available from http://reference.niem.gov/niem/resource/mpd/3.0/.
[NIEM NDR]: NIEM Naming and Design Rules (NDR), Version 3.0, NIEM Technical Architecture Committee (NTAC), 31 July 2014. Available from http://reference.niem.gov/niem/specification/naming-and-design-rules/3.0/.
[NIEM Quality Assurance]: NIEM Quality Assurance Strategy and Plan, Version 1.0, NIEM Technical Architecture Committee (NTAC), 20 May 2008. Available from http://reference.niem.gov/niem/guidance/quality-assurance-strategy-and-plan/1.0/.
[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.
[RFC 2119 Key Words]: Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, IETF RFC 2119, March 1997. Available from http://www.ietf.org/rfc/rfc2119.txt.
[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.
[W3-XML]: 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/.
[W3-XML-InfoSet]: XML Information Set, Second Edition, W3C Recommendation 4 February 2004. Available from http://www.w3.org/TR/2004/REC-xml-infoset-20040204/.
[W3-XML-Namespaces]: Namespaces in XML, Second Edition, World Wide Web Consortium 16 August 2006. Available from http://www.w3.org/TR/2006/REC-xml-names-20060816/.
[W3C XML Schema 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 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/.
Significant changes in version 3.0 (27 August 2015):