OASIS Project Note

NIEMOpen Publication Process Version 1.0

Project Note 01

02 May 2023


This stage:

https://docs.oasis-open.org/niemopen/niem-pubs/v1.0/pn01/niem-pubs-v1.0-pn01.md (Authoritative)

Previous stage:


Latest stage:

https://docs.oasis-open.org/niemopen/niem-pubs/v1.0/niem-pubs-v1.0.md (Authoritative)

Open Project:

NIEM Technical Architecture Committee (NTAC) of the OASIS NIEMOpen OP

Project Chair:

Katherine Escobar (katherine.b.escobar.civ@mail.mil), Joint Staff J6

NTAC Committee Chairs:

Jim Cabral (jim.cabral@infotrack.com), InfoTrack US
Scott Renner (sar@mitre.org), MITRE


Jim Cabral (jim.cabral@infotrack.com), InfoTrack
Christina Medlin (christina.medlin@gtri.gatech.edu), GTRI

This document is related to:


This document describes the terminology, deliverables, versioning, stages and processes involved in publishing a NIEMOpen version, including the model, specifications and tools.


This is a Non-Standards Track Work Product. The patent provisions of the OASIS IPR Policy do not apply.

This document was last revised or approved by the Project Governing Board of the OASIS NIEMOpen OP on the above date. The level of approval is also listed above. Check the "Latest stage" location noted above for possible later revisions of this document. Any other numbered Versions and other technical work produced by the Open Project (OP) are listed at http://www.niemopen.org/.

Comments on this work can be provided by opening issues in the project repository or by sending email to the project's public comment list: niemopen-comment@lists.oasis-open-projects.org. List information is available at https://lists.oasis-open-projects.org/g/niemopen-comment.

Citation format:

When referencing this document the following citation format should be used:


NIEMOpen Publication Process Version 1.0. Edited by Jim Cabral and Christina Medlin. 02 May 2023. OASIS Project Note 01. https://docs.oasis-open.org/niemopen/niem-pubs/v1.0/pn01/niem-pubs-v1.0-pn01.html. Latest stage: https://docs.oasis-open.org/niemopen/niem-pubs/v1.0/niem-pubs-v1.0.html.


Copyright © OASIS Open 2023. All Rights Reserved.

Distributed under the terms of the OASIS IPR Policy.

For complete copyright information please see the full Notices section in Appendix D.

Table of Contents

1 Introduction

This document describes the means by which the NIEM reference data model and technical specifications are updated and published. It identifies processes, artifacts, and responsibilities for new versions of NIEM. It also establishes a regular cycle for predictable and manageable NIEM updates.

The NBAC manages the content of the NIEM reference data model, which is made up of Core, domains, and other namespaces. The NTAC manages the NIEM technical specifications, which define the architecture of the reference data model and the community-built extension data models and message specifications. Both TSCs work together to manage domain and community needs, maintain coherence between the model and the specifications that govern it, and to update artifacts for new NIEM versions.

1.1 Glossary

1.1.1 Definitions of terms

1.1.2 Acronyms and abbreviations

Note: NIEM is no longer an acronym.

1.2 Assumptions

The NIEM Publication Process MUST comply with OP requirements (see sections 11-14) including:

2 NIEM Versions

NIEM versions are scheduled annually on a 3-year cycle. A NIEM major version one year will be followed by minor versions the next two years. Patch versions will be published as needed. The schedule can be delayed or adjusted, however, by the PGB.

NIEM technical specifications follow semantic versioning practices. They are typically only updated for major versions.

The NIEM data model follows a variation to semantic versioning practices. This versioning strategy attempts to balance stability vs flexibility for the community by treating Core and domain changes separately:

As such, the versioning strategy that the NIEM model employs is that only the Core namespace follows semantic versioning:

Note that:

2.1 Major Versions

Each NIEM major version:

2.2 Minor Versions

Each NIEM minor version:

2.3 Patch Versions

Each NIEM patch version:

2.4 Versioning Strategy

Specification version numbers SHOULD NOT be bumped to stay in sync with a NIEM major or minor version if the specification itself is unchanged.

Namespace version numbers in the model:

3 Project Artifacts

3.1 Artifact identifiers

3.2 NIEM model artifacts

The NIEM model:

3.3 NIEM technical specification artifacts

NIEM technical specifications:

3.4 Comment resolution logs

Comment resolution logs:

3.5 Change comparison documents

Change comparison documents:

4 Project Resources

4.1 Official Publication Site

Approved project work products MUST be published at https://docs.oasis-open.org/niemopen, including:

4.2 GitHub Repositories

NIEMOpen GitHub repositories:

The model specification and technical specification repositories are listed below:

Specification NIEMOpen repository
Model https://github.com/niemopen/niem-model
Code Lists pending
CMF https://github.com/niemopen/common-model-format
Conformance pending
CTAS https://github.com/niemopen/niem-conformance-targets
NDR https://github.com/niemopen/niem-naming-design-rules

4.2.1 Branches

4.2.2 Tags

4.3 Other OASIS Resources

Other OASIS resources may be used to support NIEM, including:

4.4 Legacy content and repositories

Prior to coming an OASIS Open Project, NIEM resources were managed and published at different locations.

5 Process Basics

The following is general information that will apply during the development and publication process of a NIEM version.

5.1 Publication Schedule

For each major or minor version, the NTAC, NBAC, and PGB SHOULD coordinate and prepare a schedule at the beginning of the year to include:

The schedule MAY continue to be adjusted throughout the year as needed.

5.2 Feedback

5.3 Updating model and technical specification artifacts

5.4 Data Stewards

Each domain in NIEM is governed by its own NBAC domain subcommittee, or is governed in conservatorship by the NBAC or an appointed steward. Each domain subcommittee SHOULD nominate a person or persons who are authorized to make domain content decisions and changes on their behalf.

Data stewards SHOULD also be appointed for code set namespaces and any other namespace in the model which has active representation from an authoritative source.

Before becoming approved by the NBAC, data stewards:

5.5 Public Reviews

Public reviews are optional for OASIS Open Projects before the OASIS Standard approval stage.

Requirements for a Public Review of a NIEMOpen PSD include:

The following are the steps for a NIEM PSD Public Review:

5.5.1 Decision to hold a public review

5.5.2 Public review announcement

5.5.3 Feedback

5.5.4 Material changes resulting from a public review

If material changes result from a public review, then:

5.5.5 Only non-material changes resulting from a public review

If only non-material changes results from a public review, then:

5.6 Submitting a Working Draft for approval to the PGB

When submitting a draft to the PGB for approval as a PSD or PS:

5.7 Approving a Project Specification Draft

Once issues targeted for the current version have been resolved or the schedule deadline has been reached and the artifacts have been updated:

5.7.1 Recommendation for approval

5.7.2 Approval process

5.7.3 Follow-up responsibilities

The PSD approval process will iterate until there are no further material changes left to be made to the draft.

5.8 Approving a Project Specification

Once the TSCs have resolved feedback on the PSD and have prepared the necessary artifacts:

5.8.1 Recommendation for approval

5.8.2 Approval process

Note that the date an approved vote closes is considered the specification publication date.

5.8.3 Follow-up responsibilities

5.9 Submitting a Project Specification for approval as an OASIS Standard

6 Publication Processes

NIEM major and minor versions follow a schedule. Patch versions are published on an ad hoc basis.

6.1 Publishing a minor version

This section describes the stages in publishing a minor version and the steps during each stage of this process. As the technical specifications are typically not updated during minor versions, this section focuses on NBAC processes for updating the data model.

Domain subcommittees and their data stewards are responsible for leading the efforts to update their domains. The NBAC Harmonization Subcommittee and maintainers are responsible for managing updates to Core and other namespaces without data stewards, including many code set namespaces.

6.1.1 Domain content updates (breaking)

Domains MAY include breaking changes in a minor version. Submission

Domain data stewards wishing to update their content SHOULD prepare changes in one of two ways, according to the data steward's preference:

  1. Changes can be made directly to the latest draft of the domain XML schema in the model repository's dev branch and submitted as a pull request.
  2. Changes can also be made in a specially-formatted change request spreadsheet submitted to a maintainer. Review

A maintainer SHOULD review the submitted changes and perform quality assurance (QA) checks and other model updates, which include: Submission updates

A domain data steward and maintainer SHOULD collaborate on updating the initial change submission until quality assurance checks have passed.

For approved change requests submitted as updated XML schema in a pull request:

For approved change requests submitted as a change request spreadsheet: Approval

Once changes are accepted, a maintainer SHOULD update the content in any tools needed to build reference schemas, subset schemas, and artifacts for the version.

Domain data stewards MAY repeat the process as needed within the permitted time frame for updates.

6.1.2 Other non-Core namespace content updates (breaking)

Other namespaces besides domains that do not impact Core MAY include breaking changes in a minor version. These other namespaces include code set namespaces, adapters and external standards, and auxiliary content.

Updates to these namespaces SHOULD follow a very similar process to the domain content update process described in Section 6.1.1 Domain content updates (breaking). The major difference is in the roles and responsibilities of the participants:

  1. Some content will be actively managed by a participating authoritative source.

  2. Some content will be managed by the NBAC.

6.1.3 Core content updates (non-breaking)

Core and Core-dependent namespaces (primarily utility schemas) MAY only introduce non-breaking changes in minor versions.

Non-breaking changes include:

Breaking changes, which are not permitted, include:

Maintainers and the Harmonization Subcommittee SHOULD fulfill similar roles defined in 6.1.2 Other non-Core namespace content updates (breaking) for content managed by the NBAC. Both will have the additional responsibility of ensuring that the content changes are non-breaking.

Non-breaking changes MAY be made directly in the Core namespace instead of a new additive-only namespace for Core changes. Note:

6.2 Publishing a major version

The process of publishing a major version of the data model follow many of the same processes as in 6.1 Publishing a NIEM minor versions. Additions or differences to the process include:

6.2.1 Core content changes (breaking)

The NBAC, the Harmonization Subcommittee (HSC), and the NTAC will also need to manage additional issues related to Core:

6.2.2 NTAC specification changes (breaking)

The NTAC will manage updates to technical specifications primarily during major versions, Specification updates:

Major specification changes:

6.3 Publishing a patch version

The NBAC, NTAC, or domain subcommittees MAY choose to issue patches to a major or minor version following the processes above, with the following adjustments:

Appendix A. Informative References

This appendix contains the informative references that are used in this document.

While any hyperlinks included in this appendix were valid at the time of publication, OASIS cannot guarantee their long-term validity.

Appendix B. Acknowledgments

B.1 Special Thanks

Substantial contributions to this document from the following individuals are gratefully acknowledged:

First Name Last Name Company
Jim Cabral InfoTrack US
Tom Carlson GTRI
Christina Medlin GTRI
Scott Renner MITRE
Duncan Sparrell sFractal Consulting

B.2 Participants

The following individuals have participated in the creation of this document and are gratefully acknowledged:

NIEM Technical Architecture Committee (NTAC) TSC Members:

First Name Last Name Company
Aubrey Beach Joint Staff J6
Jim Cabral InfoTrack US
Tom Carlson GTRI
Mike Douklias Joint Staff J6
Katherine Escobar Joint Staff J6
Mike Hulme Unisys
Eric Jahn Alexandria Consulting
Dave Kemp NSA
Vamsikrishna Kondannagari DHS
Peter Madruga GTRI
Christina Medlin GTRI
Joe Mierwa Mission Critical Partners
Scott Renner MITRE
Duncan Sparrell sFractal Consulting
Jennifer Stathakis FBI
Stephen Sullivan BAH

Appendix C. Revision History

Revision Date Editor Changes Made
niem-pubs-v1.0-pn01 2023-03-28 Jim Cabral and Christina Medlin Initial version

Appendix D. Notices

Copyright © OASIS Open 2023. All Rights Reserved.

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document is published under Attribution 4.0 International (CC BY 4.0).

All contributions made to this project have been made under the OASIS Contributor License Agreement (CLA).

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.


The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see https://www.oasis-open.org/policies-guidelines/trademark/ for above guidance.