Table of contents

Appendices

5.2 Assessing Schema-Validity

With a schema which satisfies the conditions expressed in [Errors in Schema Construction and Structure] above, the schema-validity of an element information item can be assessed. Three primary approaches to this are possible:

1. The user or application identifies a complex type definition from among the [type_definitions] of the schema, and appeals to [Schema-Validity Assessment (Element)] ([c-td]);

2. The user or application identifies a element declaration from among the [element_declarations] of the schema, checks that its [e-name] and [e-target_namespace] match the [local name] and [namespace name] of the item, and appeals to [Schema-Validity Assessment (Element)] ([c-ed]);

3. The processor starts from [Schema-Validity Assessment (Element)] with no stipulated declaration or definition, and either strictly assessed or laxly assessed assessment ensues, depending on whether or not the element information and the schema determine either an element declaration (by name) or a type definition (via xsi:type) or not.

The outcome of this effort, in any case, will be manifest in the [validation attempted] and [validity] properties on the element information item and its [attributes] and [children], recursively, as defined by [Assessment Outcome (Element)] and [Assessment Outcome (Attribute)]. It is up to applications to decide what constitutes a successful outcome.

Note that every element and attribute information item participating in the assessment will also have a [validation context] property which refers back to the element information item at which assessment began. This item, that is the element information item at which assessment began, is called the validation root.

NOTE: 

This specification does not reconstruct the XML 1.0 notion of root in either schemas or instances. Equivalent functionality is provided for at assessment invocation, via [c-res] above.

NOTE: 

This specification has nothing normative to say about multiple assessment episodes. It should however be clear from the above that if a processor restarts assessment with respect to a post-schema-validation infoset some post-schema-validation infoset contributions from the previous assessment may be overwritten. Restarting nonetheless may be useful, particularly at a node whose [validation attempted] property is none, in which case there are three obvious cases in which additional useful information may result:

• assessment was not attempted because of a valid failure, but declarations and/or definitions are available for at least some of the [children] or [attributes];

• assessment was not attempted because a named definition or declaration was missing, but after further effort the processor has retrieved it.

• assessment was not attempted because it was skipped, but the processor has at least some declarations and/or definitions available for at least some of the [children] or [attributes].