Why are constraint schemas used?

The GJXDM and NIEM schemas represent reference models that are intentionally optional and over-inclusive. The purpose of the reference model is to focus structure and semantics through well-defined types and properties, not to dictate which components to use or how to fine-tune their content.

Contraint Schemas do this in two different ways:

Encapsulating Cardinality

Constraint schemas can be used solely to constrain cardinality. This allows for cardinality validation via XSD. In this case, the constraint schema is simply a copy of the subset schema with "minOccurs" and "maxOccurs" attributes set. When validating, it takes the place of the subset schema.

There are utilities to help create constraint schemas from a subset schema. Constrain schemas are optional. Cardinality can also be enforced solely within the subset schema, at the cost of easy reuse

Enforcing Business Rules

Constraint schemas can also let you do non-GJXDM or non-NIEM modifications to subset schemas in order to enforce business rules. Practical exchanges of actual XML instances usually require much tighter constraints on elements and attributes than the schema representing the reference model allows. In a constraint schema, the user can restrict element occurrences and employ facets. An instance must pass both the conformance validation path and the constraint validation path. In other words, a 2-path, parallel validation is required.

Conformance validation ensures proper uses of the GJXDM and NIEM, and constraint validation (more restrictive) confirms that an instance adheres to rules specific to the user’s application. In many cases (though not a requirement), a constraint schema will be a copy of the GJXDM or NIEM schema subset (or full) with appropriate constraints applied.