From c9e1c03f4c44f25c93b527f9e23fd7c57db4060e Mon Sep 17 00:00:00 2001 From: David Waltermire Date: Tue, 27 Feb 2024 09:30:18 -0500 Subject: [PATCH] Reorganized headings, added cross-links, added syntax table for common data elements. --- .../specification/syntax/constraints.md | 379 +++++++++++------- 1 file changed, 245 insertions(+), 134 deletions(-) diff --git a/website/content/specification/syntax/constraints.md b/website/content/specification/syntax/constraints.md index 62124172..2ef0ccad 100644 --- a/website/content/specification/syntax/constraints.md +++ b/website/content/specification/syntax/constraints.md @@ -6,8 +6,6 @@ weight: 50 # Constraints -**Note: This section of the specification is still a work in progress.** - Metaschema modules can define different kinds of constraints to support data validation within and between document instances. The types of constraints allowed for a given definition @@ -16,10 +14,11 @@ The types of constraints allowed for a given definition The following constraint types are allowed for `` definitions. -- [``](#enumerated-values) -- `` +- [``](#let-expressions) +- [``](#allowed-values-constraints) +- [``](#expect-constraints) - [``](#index-has-key-constraints) -- `` +- [``](#matches-constraints) For each of these constraint types, use of the `@target` attribute is prohibited. This is because a flag constraint may only target the flag, since a flag has no child nodes. @@ -27,30 +26,44 @@ For each of these constraint types, use of the `@target` attribute is prohibited The following constraint types are allowed for `` definitions. -- [``](#enumerated-values) -- `` +- [``](#let-expressions) +- [``](#allowed-values-constraints) +- [``](#expect-constraints) - [``](#index-has-key-constraints) -- `` +- [``](#matches-constraints) ## `` constraints The following constraint types are allowed for `` definitions. -- [``](#enumerated-values) -- `` -- [``](#index-has-key-constraints) -- `` -- [``](#index-constraints) -- `` +- [``](#let-expressions) +- [``](#allowed-values-constraints) +- [``](#expect-constraints) - [``](#has-cardinality-constraints) +- [``](#index-constraints) +- [``](#index-has-key-constraints) +- [``](#is-unique-constraints) +- [``](#matches-constraints) ## Common Constraint Data +All *constraints* share a common syntax composed of the following: + +| Data | Data Type | Use | Default Value | +|:--- |:--- |:--- |:--- | +| [`@id`](#id) | [`token`](/specification/datatypes/#token) | optional | *(no default)* | +| [`@level`](#level) | `DEBUG`,`INFORMATIONAL`, `WARNING`, `ERROR`, or `CRITICAL` | optional | `ERROR` | +| [`@target`](#target) | special | *varies* | `.` | +| [``](#formal-name) | [`string`](/specification/datatypes/#string) | 0 or 1 | *(no default)* | +| [``](#description) | [`markup-line`](/specification/datatypes/#markup-line) | 0 or 1 | *(no default)* | +| [``](#prop) | special | 0 to ∞ | *(no default)* | +| [``](#remarks) | special | 0 or 1 | *(no default)* | + Each individual constraint allows the following data. ### `@id` -A constraint MAY have an OPTIONAL `@id` attribute, which provides an identifier for the constraint. +A constraint MAY have an OPTIONAL `@id` flag, which provides an identifier for the constraint. Metaschema processors MAY use the identifier for processing constraints and/or referencing them in output for later analysis. @@ -60,6 +73,14 @@ A constraint MAY have an OPTIONAL `@level` attribute, which identifies the sever If defined, a `@level` MUST have a value of either: `CRITICAL`, `ERROR`, `WARNING`, `INFORMATIONAL`, or `DEBUG`. +These values have the following definitions: + +- **CRITICAL**: A violation of the constraint represents a serious fault in the content that will prevent typical use of the content. +- **ERROR**: A violation of the constraint represents a fault in the content. This may include issues around compatibility, integrity, consistency, etc. +- **WARNING**: A violation of the constraint represents a potential issue with the content. +- **INFORMATIONAL**: A violation of the constraint represents a point of interest. +- **DEBUG**: A violation of the constraint represents a fault in the content that may warrant review by a developer when performing model or tool development. + Metaschema processors MAY perform conditional processing and/or presentation of constraint violations based on the level value. ### `@target` @@ -74,53 +95,97 @@ If a `@target` value is not defined, a Metaschema processor MUST process the val A *target* can apply to any node(s) in the document instance(s). There is no guarantee the constraint *target* is a child of its respective assembly, field, or flag. Thus, a Metaschema processor MUST resolve the Metapath expression to identify the actual target nodes that the constraint applies to. If no resulting target nodes are identified, then the constraint MUST be ignored. -## Constraint Processing +### `@deprecated` Version -In a Metaschema-based document instance, each node in the document instance is associated with a definition in a Metaschema module. Thus, a given content node has one and only one associated definition. +The optional `@deprecated` attribute communicates that use of the given *information element* implemented by the *definition* is intended to be discontinued, starting with the *information model* revision indicated by the attribute's value. -A constraint is defined relative to an assembly, field, or flag [definition](../definitions/) in a Metaschema module. +This attribute's value MUST be a version [string](/specification/datatypes/#string) that is equal to or comes before the [``](/specification/syntax/module/#schema-version) declared in the *Metaschema module* *header*. -All constraints associated with a definition MUST be evaluated against all associated content nodes. +{{}} +Declaring the `@deprecated` attribute communicates to content creators that all use of the annotated *information element* is to be avoided. This annotation can be used in documentation generation and in Metaschema-aware tools that provide context around use of the definition. +{{}} -Constraints may be declared internally within a definition or as an external set of constraints associated with a definition. To determine the evaluation order, internal and external constraints associated with a definition need to be combined. +The following example illustrates deprecating the flag named `flag-name` starting with the *information model* semantic version `1.1.0`. -Declaration order MUST be determined in the following way. +```xml {linenos=table,hl_lines=[3]} + +``` -1. Internal constraints defined directly in the definition are ordered first according to their original order. -2. External constraints are appended in the order the external constraints were provided to the processor. +### `@name` -Each constraint MUST be evaluated in declaration order. +The `@name` attribute provides the definition's identifier, which can be used in other parts of a module, or in an importing *Metaschema module*, to reference the definition. -For example: +In top-level definitions, this attribute's value MUST be a [token](/specification/datatypes/#token) that is unique among sibling definitions of the same type. -Given the Metaschema module definitions below: +**Note:** The names of flags, fields, and assemblies are expected to be maintained as separate identifier sets. This allows a *flag definition*, a *field definition*, and an *assembly definition* to each have the same name in a given *Metaschema module*. -``` -Assembly(name="asmA") - Field(name="fldX) - Flag(name="flgS") - Assembly(name="asmB") - Flag(name="flgT") -``` +### `@scope` -Constraint evaluation would be handled depth-first as follows: +The optional `@scope` attribute is used to communicate the intended visibility of the definition when accessed by another module through an [``](/specification/syntax/module/#import) element. -- When document node `asmA` is processed, constraints defined on that node's definition will be evaluated. -- When document node `fldX` is processed, constraints defined on that node's definition will be evaluated. -- and so on... +- `global` - Indicates that the definition MUST be made available for reference within importing modules. Definitions in the same and importing modules can reference it. This is the default behavior when `@scope` is not declared. +- `local` - Indicates that the definition MUST NOT be made available for reference within importing modules. Only definitions in the same module can reference it. -Note: The target of the constraint does not affect this evaluation order, but may affect what resulting node the constraint applies to. +Note: References to definitions in the same module are always possible regardless of scope. -When a constraint is evaluated against the associated content node, this node is considered the constraints *evaluation focus*. +The scope of a definition affects how the [definition's name is resolved](/specification/syntax/module/#definition-name-resolution). -### Processing Error Handling +### `` -Processing errors occur when a defect in the constraint definition causes an unintended error to occur during constraint processing. This differs from a validation error that results from not meeting the requirement of a constraint. +The optional `` field provides a human-readable, short string label for the constraint for use in documentation. -- If a processing error occurs while processing a constraint, which can result from evaluating a Metapath expression, the error SHOULD be reported. -- If a processing error occurs while processing a constraint, then the document instance being validated MUST NOT be considered valid. This is due to the inability to make a conclusion around validity, since some constraints were not validated due to errors. +{{}} +The `` label is intended to provide an easy to recognize, meaningful name for the constraint. + +While not required, it is best practice to include a ``. +{{}} + +### `` + +The optional `` field is a [single line of markup](/specification/datatypes/#markup-line) that describes the semantic meaning and use of the constraint. + +{{}} +The description ties the constraint to the related information element concept in the information domain that the constraint is representing. This information is ideal for use in documentation. + +While not required, it is best practice to include a ``. +{{}} + +### `` + +The optional `` assembly provides a structure for declaring arbitrary properties, which consist of a `@namespace`, `@name`, and `@value`. + +| Attribute | Data Type | Use | Default Value | +|:--- |:--- |:--- |:--- | +| `@namespace` | [`uri`](/specification/datatypes/#uri) | optional | `http://csrc.nist.gov/ns/oscal/metaschema/1.0` | +| `@name` | [`token`](/specification/datatypes/#token) | required | *(no default)* | +| `@value` | [`token`](/specification/datatypes/#token) | required | *(no default)* | + +The `@name` and `@namespace` is used in combination to define a semantically unique name, represented by the `@name` attribute, within the managed namespace defined by the `@namespace` attribute. If the `@namespace` attribute is omitted, the `@name` MUST be considered in the `http://csrc.nist.gov/ns/oscal/metaschema/1.0` namespace. + +The `@value` flag represents the lexical value assignment for the semantically unique name represented by the combination of the `@name` and `@namespace`. The lexical values of the `@value` attribute may be restricted for the specific semantically unique name, but such restrictions are not enforced directly in this model. + +{{}} +A property is useful for annotating a constraint with additional information that might describe, in a structured way, the semantics, use, nature, or other significant information related to the constraint. In many cases, a property might be used to tailor generated documentation or to support an experimental, non-standardized feature in Metaschema. +{{}} + +### `` -## Let expressions +The optional `` field provides a place to add notes related to the use of the constraint. Remarks can be used to clarify the semantics of the constraint in specific conditions, or to better describe how the constraint is utilized within a model. + +The `` field is optional and may occur multiple times. + +It supports an optional `@class` flag that can be used to identify format specific remarks, to be handled appropriately (or ignored when not useful) in a downstream application. Valid values for `@class` are: + +- `XML`: The remark applies to the XML format binding. +- `JSON`: The remark applies to the JSON or YAML format bindings. + +## Constraint Types + +The following describes the supported constraint constructs. + +### Let Expressions Using the `let` element, a variable can be defined, which can be used in a Metapath expression in subsequent constraints. @@ -163,93 +228,7 @@ And the following document. The expect constraint would pass for each `sibling` in the `parent` named "p1", and would fail for each `sibling` in the `parent` named "p2". -## `expect` constraints - -The `` constraint is a type of Metaschema constraint that restricts field or flag value(s) based on the evaluation of a `@test` Metapath expression. - -The `@target` attribute of an `` constraint specifies the node(s) in a document instance whose value is restricted by the constraint. - -The `@test` attribute of an `` constraint specifies the logical condition to be evaluated against each value node resulting from evaluating the `@target`. This expression MUST evaluate to [a Metaschema boolean value](/specification/datatypes#boolean) `true` or `false`. - -When the `@test` expression evaluates to `true` for a target value node, then the target value node MUST be considered valid and passing the constraint. - -When the `@test` expression evaluates to `false` for a target value node, then the target value node MUST be considered not valid and failing the constraint. - -A constraint may have an OPTIONAL [`@level`](#level) attribute and/or an OPTIONAL child [``](#message) element to indicate severity and documentation explaining how the target nodes are invalid. - -If defined, the `` value MUST be a [Metaschema string value](/specification/datatypes#string). It MAY contain a Metapath expression templates that starts with `{`, contains a Metapath expression, and ends with `}`. When evaluating a template Metapath expression, the context of the Metapath [evaluation focus](#constraint-processing) MUST be the failing value node. - -##`matches` - -The `` constraint is a type of Metaschema constraint that restricts field or flag value(s) based on node(s) matching the target Metapath expression. Each one of these are discussed below. - -A match can be made by 2 different ways based on `@datatype` and/or based on `@regex`. - -The `@target` flag of an `matches` constraint specifies the node(s) in a document instance whose value matches the `@datatype` and/or the `@regex`. The `matches` constraint MUST define a [`target`](#target) with a Metapath expression. The processor MUST evaluate only the node(s) resulting from evaluating the `@target`. - -If a `@datatype` is provided, each resulting node's value MUST match the syntax of the given `@datatype`. - -If a `@regex` is provided, each resulting node's value MUST match the pattern specified by the given `@regex`. - -When evaluating node(s) matching the `@target`, the node(s) pass the constraint when matching all requirements of `@datatype`, if defined, and `@regex`, if defined. - -If the node(s) do not match any of these requirements, then the node(s) MUST be considered to not pass the constraint. - -## `index` constraints - -The `` constraint is a type of Metaschema constraint that defines an index of document instance nodes addressable by key. - -The `@name` flag of an `` constraint specifies the identity of the index. The constraint MUST define the name. - -The `@target` flag of an `` constraint defines the node(s) in a document instance to index. The index MUST define a [`@target`](#target) with a Metapath expression. The processor MUST index only the node(s) resulting from evaluating the `@target`. - -The `` assembly of an `` constraint defines the flag or field value that is the key for each entry in the index. A `` assembly MUST define at least one [`@target`](#target) flag with a Metapath expression evaluated relative to [the evaluation focus](#constraint-processing) using each node that matches the constraint's `@target`. - -An `index` constraint MAY define more than one `` assembly. The composite key for each entry in the index is the combination of values for the `@target` of every ``. The composite values of the key are the discriminator for the uniqueness of the index entry. - -An `index` constraint requires that each member entry be unique based upon this composite key. - -If the evaluation of the Metapath `@target` of the `` does not result in a value, its value for that key in the index is null. - -If two entries have the same key computed from the `` `@target`s when generating the index, the processor MUST return a processing error. - -## `index-has-key` constraints - -The `index-has-key` constraint is a type of Metaschema constraint that cross-references values an existing `index` constraint` with a separate `@target` and ``. - -The `@name` flag of an `` constraint MUST specify the name of a previously defined `index` constraint. - -The `index-has-key` constraint has the same flags and assemblies as a [`index`](#index-constraints) constraint. - -## `is-unique` constraints - -The `` constraint is a type of Metaschema constraint that checks that a computed key, based on field and flag values, does not occur more than once. Unlike ``, an explicit, named index is not created. Therefore, this constraint MUST NOT define a `@name` flag. - -The [`id`](#id) flag of an `` constraint specifies an identifier for the constraint. - -The `@target` flag of an `` constraint identifies the node(s) in a document instance to check for uniqueness. The `` MUST define a [`@target`](#target) with a Metapath expression. The processor MUST check uniqueness for only the node(s) resulting from evaluating the `@target`. - -A `` assembly of an `` constraint identifies the flag or field value that is the key used to determine the uniqueness of each entry based on a computed key. A `` element MUST define at least one [`@target`](#target) flag with a Metapath expression evaluated relative to [the evaluation focus](#constraint-processing) using each node that matches the constraint's `@target`. - -An `is-unique` constraint MAY define more than one `` assembly. The composite key for each entry in the index is the combination of values for the `@target` of every ``. The composite values of the key are the discriminator for the uniqueness of the index entry. - -When evaluating a given key relative to other computed keys for the same constraint, if the given key has the same computed key value as another node matching the same constraint, then the target node MUST be considered to not pass the constraint. - -## `has-cardinality` constraints - -The `has-cardinality` constraint is a type of Metaschema constraint that defines the cardinality of assemblies, flags, and, fields, i.e. the required minimum count of occurrences, the maximum count of occurrences, or both for applicable document instances. - -The `@target` flag of an `` constraint defines the node(s) in a document instance to count. The constraint MUST define a [`@target`](#target) with a Metapath expression. The processor MUST only count the document instance node(s) resulting from its evaluation. - -A constraint MUST define a value for either the `@min-occurs` or `@max-occurs` flag. It MAY optionally have both flags defined. - -The `@min-occurs` flag MUST be an integer that defines the minimum number of required occurrences for results matching the evaluation of the `@target`. - -The `@max-occurs` flag MUST be an integer that defines the maximum number of required occurrences for results matching the evaluation of the `@target`. - -A constraint passes and document instance(s) valid if the count of results matching the evaluation of the `@target` Metapath is equal or more than the value of `@min-occurs`, if defined, and equal to or less than the value of `@max-occurs`, if defined. If these requirements are not met when defined, the constraint is not passing and the document instance(s) are not valid. - -## Enumerated values +### `allowed-values` Constraints The `allowed-values` constraint is a type of Metaschema constraint that restricts field or flag value(s) based on an enumerated set of permitted values. @@ -260,7 +239,7 @@ Each `allowed-values` constraint has a *source* that will be either: The `@target` of an `` constraint specifies the node(s) in a document instance whose value is restricted by the constraint. -### Enumerated value processing +#### `allowed-values` Processing Metaschema processors MUST process `` constraints. @@ -282,7 +261,7 @@ For each `` in the *applicable set*, the `@allow-other` attribut The following subsections detail the processing requirements for the `@extension` and `@allow-other` attributes. -#### `@extension` +##### `@extension` For each `` constraints the *applicable set*, the `@extension` attribute MUST be one of the following values. @@ -303,7 +282,7 @@ One of the following requirements MUST apply when processing a value's *applicab 1. All `` constraints in the *applicable set* MUST have the `@extension` attribute value `external` and originate from either a *model* or *extension* source. 1. An error MUST be raised indicating the *applicable set* is invalid. -#### `@allow-other` +##### `@allow-other` The *expected value set* can be considered *open* or *closed*. @@ -342,6 +321,138 @@ A Metaschema processor MAY use the text value of the `enum`'s XML element as doc ``` +### `expect` Constraints + +The `` constraint is a type of Metaschema constraint that restricts field or flag value(s) based on the evaluation of a `@test` Metapath expression. + +The `@target` attribute of an `` constraint specifies the node(s) in a document instance whose value is restricted by the constraint. + +The `@test` attribute of an `` constraint specifies the logical condition to be evaluated against each value node resulting from evaluating the `@target`. This expression MUST evaluate to [a Metaschema boolean value](/specification/datatypes#boolean) `true` or `false`. + +When the `@test` expression evaluates to `true` for a target value node, then the target value node MUST be considered valid and passing the constraint. + +When the `@test` expression evaluates to `false` for a target value node, then the target value node MUST be considered not valid and failing the constraint. + +A constraint may have an OPTIONAL [`@level`](#level) attribute and/or an OPTIONAL child [``](#message) element to indicate severity and documentation explaining how the target nodes are invalid. + +If defined, the `` value MUST be a [Metaschema string value](/specification/datatypes#string). It MAY contain a Metapath expression templates that starts with `{`, contains a Metapath expression, and ends with `}`. When evaluating a template Metapath expression, the context of the Metapath [evaluation focus](#constraint-processing) MUST be the failing value node. + +### `has-cardinality` Constraints + +The `has-cardinality` constraint is a type of Metaschema constraint that defines the cardinality of assemblies, flags, and, fields, i.e. the required minimum count of occurrences, the maximum count of occurrences, or both for applicable document instances. + +The `@target` flag of an `` constraint defines the node(s) in a document instance to count. The constraint MUST define a [`@target`](#target) with a Metapath expression. The processor MUST only count the document instance node(s) resulting from its evaluation. + +A constraint MUST define a value for either the `@min-occurs` or `@max-occurs` flag. It MAY optionally have both flags defined. + +The `@min-occurs` flag MUST be an integer that defines the minimum number of required occurrences for results matching the evaluation of the `@target`. + +The `@max-occurs` flag MUST be an integer that defines the maximum number of required occurrences for results matching the evaluation of the `@target`. + +A constraint passes and document instance(s) valid if the count of results matching the evaluation of the `@target` Metapath is equal or more than the value of `@min-occurs`, if defined, and equal to or less than the value of `@max-occurs`, if defined. If these requirements are not met when defined, the constraint is not passing and the document instance(s) are not valid. + +### `index` Constraints + +The `` constraint is a type of Metaschema constraint that defines an index of document instance nodes addressable by key. + +The `@name` flag of an `` constraint specifies the identity of the index. The constraint MUST define the name. + +The `@target` flag of an `` constraint defines the node(s) in a document instance to index. The index MUST define a [`@target`](#target) with a Metapath expression. The processor MUST index only the node(s) resulting from evaluating the `@target`. + +The `` assembly of an `` constraint defines the flag or field value that is the key for each entry in the index. A `` assembly MUST define at least one [`@target`](#target) flag with a Metapath expression evaluated relative to [the evaluation focus](#constraint-processing) using each node that matches the constraint's `@target`. + +An `index` constraint MAY define more than one `` assembly. The composite key for each entry in the index is the combination of values for the `@target` of every ``. The composite values of the key are the discriminator for the uniqueness of the index entry. + +An `index` constraint requires that each member entry be unique based upon this composite key. + +If the evaluation of the Metapath `@target` of the `` does not result in a value, its value for that key in the index is null. + +If two entries have the same key computed from the `` `@target`s when generating the index, the processor MUST return a processing error. + +### `index-has-key` Constraints + +The `index-has-key` constraint is a type of Metaschema constraint that cross-references values an existing `index` constraint` with a separate `@target` and ``. + +The `@name` flag of an `` constraint MUST specify the name of a previously defined `index` constraint. + +The `index-has-key` constraint has the same flags and assemblies as a [`index`](#index-constraints) constraint. + +### `is-unique` Constraints + +The `` constraint is a type of Metaschema constraint that checks that a computed key, based on field and flag values, does not occur more than once. Unlike ``, an explicit, named index is not created. Therefore, this constraint MUST NOT define a `@name` flag. + +The [`id`](#id) flag of an `` constraint specifies an identifier for the constraint. + +The `@target` flag of an `` constraint identifies the node(s) in a document instance to check for uniqueness. The `` MUST define a [`@target`](#target) with a Metapath expression. The processor MUST check uniqueness for only the node(s) resulting from evaluating the `@target`. + +A `` assembly of an `` constraint identifies the flag or field value that is the key used to determine the uniqueness of each entry based on a computed key. A `` element MUST define at least one [`@target`](#target) flag with a Metapath expression evaluated relative to [the evaluation focus](#constraint-processing) using each node that matches the constraint's `@target`. + +An `is-unique` constraint MAY define more than one `` assembly. The composite key for each entry in the index is the combination of values for the `@target` of every ``. The composite values of the key are the discriminator for the uniqueness of the index entry. + +When evaluating a given key relative to other computed keys for the same constraint, if the given key has the same computed key value as another node matching the same constraint, then the target node MUST be considered to not pass the constraint. + +### `matches` Constraints + +The `` constraint is a type of Metaschema constraint that restricts field or flag value(s) based on node(s) matching the target Metapath expression. Each one of these are discussed below. + +A match can be made by 2 different ways based on `@datatype` and/or based on `@regex`. + +The `@target` flag of an `matches` constraint specifies the node(s) in a document instance whose value matches the `@datatype` and/or the `@regex`. The `matches` constraint MUST define a [`target`](#target) with a Metapath expression. The processor MUST evaluate only the node(s) resulting from evaluating the `@target`. + +If a `@datatype` is provided, each resulting node's value MUST match the syntax of the given `@datatype`. + +If a `@regex` is provided, each resulting node's value MUST match the pattern specified by the given `@regex`. + +When evaluating node(s) matching the `@target`, the node(s) pass the constraint when matching all requirements of `@datatype`, if defined, and `@regex`, if defined. + +If the node(s) do not match any of these requirements, then the node(s) MUST be considered to not pass the constraint. + +## Constraint Processing + +In a Metaschema-based document instance, each node in the document instance is associated with a definition in a Metaschema module. Thus, a given content node has one and only one associated definition. + +A constraint is defined relative to an assembly, field, or flag [definition](../definitions/) in a Metaschema module. + +All constraints associated with a definition MUST be evaluated against all associated content nodes. + +Constraints may be declared internally within a definition or as an external set of constraints associated with a definition. To determine the evaluation order, internal and external constraints associated with a definition need to be combined. + +Declaration order MUST be determined in the following way. + +1. Internal constraints defined directly in the definition are ordered first according to their original order. +2. External constraints are appended in the order the external constraints were provided to the processor. + +Each constraint MUST be evaluated in declaration order. + +For example: + +Given the Metaschema module definitions below: + +```text +Assembly(name="asmA") + Field(name="fldX) + Flag(name="flgS") + Assembly(name="asmB") + Flag(name="flgT") +``` + +Constraint evaluation would be handled depth-first as follows: + +- When document node `asmA` is processed, constraints defined on that node's definition will be evaluated. +- When document node `fldX` is processed, constraints defined on that node's definition will be evaluated. +- and so on... + +Note: The target of the constraint does not affect this evaluation order, but may affect what resulting node the constraint applies to. + +When a constraint is evaluated against the associated content node, this node is considered the constraints *evaluation focus*. + +### Processing Error Handling + +Processing errors occur when a defect in the constraint definition causes an unintended error to occur during constraint processing. This differs from a validation error that results from not meeting the requirement of a constraint. + +- If a processing error occurs while processing a constraint, which can result from evaluating a Metapath expression, the error SHOULD be reported. +- If a processing error occurs while processing a constraint, then the document instance being validated MUST NOT be considered valid. This is due to the inability to make a conclusion around validity, since some constraints were not validated due to errors. + ## External Constraints TBD