Under NIEM 2, a NIEM-conformant XML schema document must indicate that it is a NIEM-conformant schema. This is done through the occurrence of an element within xs:appinfo in the schema:

<xs:schema [...]>
  <xs:annotation>
    <xs:documentation>[...]</xs:documentation>
    <xs:appinfo>
      <i:ConformantIndicator>true</i:ConformantIndicator>
    </xs:appinfo>
  </xs:annotation>
  [...]
</xs:schema>

The NIEM 2 conformance indicator is limited:

1. The NIEM 2 conformance indicator does not work in documents other than XML Schema documents. It is defined to only apply within a schema document, when the conformant indicator is an appinfo on the document element (root element) of the schema document.
2. The NIEM 2 conformance indicator only identifies conformance to a single standard, NIEM 2, as indicated by the namespace in which the appinfo:ConformantIndicator element is defined.
3. The NIEM 2 conformance indicator does not explicitly identify a conformance target. It indicates that a schema document claims to be conformant, but does not indicate to which conformance target it conforms.

The construct specified by this specification has the following goals:

1. It supports specifying conformance targets within any XML document, not just XML Schema documents. Any future XML document may be designed to accommodate it.
2. It places a minimum of syntactic requirements on an XML document. It does not require a particular document element. It does not require an attribute directly on the document element.
3. It does not introduce unnecessary content, including wildcards in a content model.
4. It does not introduce dependencies on unnecessary architectural components or schemas.
5. It can express a claim to conform to a conformance target defined by a subsequent specification, without modification to this specification.
6. Subsequent specifications may explicitly leverage it with minimal effort.
7. It does not require any sort of registry or centrally-controlled mechanism.
8. It may be used by validation software to identify the correct validation criteria for an XML document.
9. It can express claims to multiple conformance targets simultaneously.
10. It supports nested documents, each with its own conformance claim, without conflict.
11. It may be validated with XML Schema, but does not require its use.
12. It may be used with XSLT 1.0 ([XSLT1]) and XSLT 2.0 ([XSLT2]) stylesheets.

This specification normatively defines a conformance target attribute. An XML document, for example a NIEM XML Schema document, will contain this attribute to indicate to which conformance targets it claims to conform. The attribute is a claim of conformance, and not a statement that should be trusted by a validating system. A validator would use this claim to identify to which conformance rules a document should be validated.

The attribute's value is a list of internationalized resource identifiers (IRIs). A later specification may define an IRI for its conformance target, and when an XML document has that IRI in its conformance target attribute, the document is claiming to conform to that conformance target.

Note that all examples within this document, unless explicitly labeled otherwise, are not intended to represent any actual standard, version, conformance target, or identifier. All examples are mock-ups, using familiar terms and subjects, but should not be interpreted to actually represent other specifications or activities.

As mocked-up example, a specification, NIEM Business Rules Specification, Version 3.0 may define a conformance target called a conformant schema document. Note that the conformance target is particular to the specification, and the single version of that specification. In this case, an XML document that conforms to that conformance target would be an XML Schema document that follows the set of rules defined by that specification for that conformance target. Another specification may refer to that conformance target using text similar to the following:

... the document must be a conformant schema document, as defined by the NIEM Business Rules Specification, Version 3.0 ...

The NIEM Business Rules Specification, Version 3.0 would define an IRI that uniquely identifies that conformance target, for example:

http://reference.niem.gov/niem/specification/business-rules/3.0/#SchemaDocument

The IRI identifies an authority, a specification, a particular version of that specification, and a particular conformance target within that version of the specification.

A schema document could claim to conform to that conformance target by listing the IRI that is the identifier of the business rules conformant schema document conformance target in its first conformance targets attribute, as follows:

<xs:schema
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:ct="http://release.niem.gov/niem/conformanceTargets/3.0/"
    ct:conformanceTargets="
        http://reference.niem.gov/niem/specification/naming-and-design-rules/3.0/#ReferenceSchemaDocument
        http://reference.niem.gov/niem/specification/business-rules/3.0/#SchemaDocument"
    [...]>
  <xs:annotation>
    <xs:documentation>[...]</xs:documentation>
  </xs:annotation>
  [...]
</xs:schema>

This example shows two conformance targets (again, this should not be read as reflecting actual standards, conformance targets, or identifiers):

• The first conformance target (...#ReferenceSchemaDocument) establishes a claim that the document conforms to the NIEM NDR, version 3.0's reference schema document conformance target.
• The second conformance target (...#SchemaDocument) establishes a claim that the document conforms to a NIEM business rules specification, version 3.0's schema document conformance target.

This conformance target claim is just that, a claim. It does not establish conformance, merely hints at it. The conformance claim may be overridden in many ways, such as a well-known root element, doctype, schema, etc. In the above example, the document element xs:schema indicates that the document should be treated as an XML Schema document. The conformance targets attribute indicates conformance targets beyond what is identified by the xs:schema element.

As another example, a ULEX 1.0 message has a well-known document element, {ulex:message:pd:1.0}doPublish, which indicates a ULEX conformance target and indicates use of ULEX's rules for validation. In addition, a specification that uses ULEX may choose to leverage this conformance targets attribute specification to specify additional conformance targets, by including within a message a ct:conformanceTargets attribute that indicates additional conformance targets.

In addition, an XML document may have an implied semantic that some specific sub-element (e.g., a ULEX StructuredPayload element) may contain an XML element that is meant to represent a separate XML document. In such a case, the XML fragment may be written out as a separate document, and the first conformance targets attribute within that document will establish a claim to conformance. Validation of such nested documents could be performed by a smart validator, without writing out sub-documents, but specification of that is outside the scope of this specification.

In any case, the first occurrence in an XML document of the attribute ct:conformanceTargets (in the namespace http://release.niem.gov/niem/conformanceTargets/3.0/) is termed the document's effective conformance targets attribute (see [Definition: effective conformance targets attribute]). The IRIs carried within that attribute are the document's effective conformance target identifiers (see [Definition: effective conformance target identifier]). Each of these identifiers is an IRI that indicates a conformance target to which the document may conform.

While this mechanism is available to specifications as a means of expressing a document's claim to conform, different specifications and document types may have different ways of specifying conformance. For example, the MPD catalog may use the attribute to express conformance of the catalog itself, while defining a separate mechanism to indicate the conformants of a set of documents, since a set is not itself an XML document.

This specification does not establish a requirement that any document use the conformance attribute to identify its conformance targets. The authors of subsequent specifications should make explicit whether the conformance attribute is a required mechanism for labeling conformance, or if it merely is used as an optional hint.

Within normative content (rules and definitions), the key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [RFC2119].

The following namespaces are used consistently within this document:

• The namespace prefix xs is bound to the namespace URI reference http://www.w3.org/2001/XMLSchema.
• The namespace prefix ct is bound to the namespace URI reference http://release.niem.gov/niem/conformanceTargets/3.0/.

The use of namespace prefixes and prefix-qualified names within this specification does not constitute a requirement for any artifact to use any specific namespace prefix. Namespace prefixes are immaterial to conformance to this specification.

This document uses Clark notation to represent qualified names in normative text. Clark notation is described by [ClarkNS], and provides the information in an XML qualified name (as defined by [XMLNamespaces]) without the need to define a namespace prefix and then reference that namespace prefix. A Clark notation value looks like the following:

{http://www.w3.org/2001/XMLSchema}string

Each Clark notation value consists of a namespace URI surrounded by curly braces, concatenated with a local name. Such a namespace/local name pair may be expressed in XML using a namespace prefix, or a default namespace binding, as specified in the [XMLNamespaces].

This document contains text that is normative, and text that is informative. This section describes the normative forms.

A definition defines a term that is used within rules.

A rule states a specific requirement on a conformance target. The conformance target is explicitly identified in the text of the rule. A rule uses terminology from [RFC2119] to establish requirements. Rules are normative.

This document uses the term conformance target in a normative way:

The above definition of conformance target is adapted from [OASISConformance]. This definition is overly broad for the purposes of this specification, as this specification is concerned only with conformance targets that are XML documents.

The term internationlized resource identifier (IRI) is defined by [RFC3987]. The RFC also defines comparison of IRIs.

This specification defines a single conformance target, normatively referred to within this document as a conformant document.

For an example of the use of this term in another specification, see Section 4.2, Use of this Specification, below.

The term XML document is defined by [XML].

The schema-validity of an attribute is defined by [XMLSchema1]. This specification does not require that the validity of a conformant artifact actually be assesed, only that the occurrences of the attribute satisfy the constraints embodied in the schema document.

This specification does not require any specific system or exchange specification to use this particular schema document. A system or exchange specification may use or incorporate a schema for this namespace that adds or removes annotations or modifies other characteristics of the schema, for example to make the schema document conformant to some specification.

Rule 3-3, Namespace defines only attribute ct:conformanceTargets, above, and Rule 3-4, No reference to types in conformance targets namespace, above, defend against abuse of the conformance targets attribute namespace, ensuring that any document that implies that there are additional schema components defined in the conformance targets attribute namespace is not conformant.

The definition of an absolute IRI reference is defined by [RFC3987].

This specification does not restrict the number of occurrences of the conformance targets attribute. If a document has no occurences of the conformance targets attribute, or if the effective conformance target attribute contains no items, then the document does not claim to conform to any conformance targets via the mechanisms of this specification. If there are multiple occurrences of the conformance targets attribute, only one is effective for the document.

This section includes a non-normative description of the way the constructs defined by this specification are intended to work. This section is not normative.

A validator should use the effective conformance target identifiers of a conformant document as hints indicating possible intended conformance targets for the document.

A validator should not identify claimed conformance targets using occurrences of the conformance targets attribute other than the effective conformance targets attribute. Only the first occurrence of the conformance targets attribute, in document order, establishes a claim to conformance.

A validator should limit validation to known conformance target identifiers. It should ignore unknown identifiers.

A validator should not treat the order the order of conformance target identifiers within the effective conformance targets attribute as significant. The contents of a conformance targets attribute should be treated as a set, rather than an ordered list.

The following should be true for a specification that leverages this specification:

1. The specification defines explicit conformance targets.
2. Normative statements made by the specification are prescriptive requirements on those conformance targets.
3. Each conformance target that is an XML document, and for which the Conformance Targets Attribute Specification will be leveraged, is assigned a conformance target identifier by the specification. Each such identifier is an IRI, and is unique to the specification, version, and conformance target.

4. For the conformance target with the name $conformance-target-name and the conformance target identifier $conformance-target-identifier, the specification includes normative text similar to the following:

   A $conformance-target-name MUST be a conformant document as defined by the NIEM Conformance Targets Attribute Specification Version 3.0, and MUST have an effective conformance target identifer of $conformance-target-identifier.

   A specification that uses the conformance targets attribute as an optional hint would replace the word MUST in the above rule with the word MAY or SHOULD, as appropriate for the level of requirement desired.

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 specification is published under Attribution 4.0 International (CC BY 4.0). Code associated with this specification is provided under Apache License 2.0.

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

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the NIEMOpen IPR Statement page.

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 Open Project (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.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. OASIS AND ITS MEMBERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THIS DOCUMENT OR ANY PART THEREOF.

As stated in the OASIS IPR Policy, the following three paragraphs in brackets apply to OASIS Standards Final Deliverable documents (Project Specifications, OASIS Standards, or Approved Errata).

[OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Standards Final Deliverable, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Open Project that produced this deliverable.]

[OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this OASIS Standards Final Deliverable by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Open Project that produced this OASIS Standards Final Deliverable. OASIS may include such claims on its website, but disclaims any obligation to do so.]

[OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this OASIS Standards Final Deliverable or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Open Project can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Standards Final Deliverable, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.]

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.