...
2.2 XSD Abstract Data Model
This specification builds on [XML 1.1] and
[XML-Namespaces 1.1]. The concepts and definitions used
herein regarding XML are framed at the abstract level of
information
items as defined in [XML-Infoset]. By
definition, this use of the infoset provides a
priori guarantees of well-formedness
(as defined in [XML 1.1]) and namespace
conformance (as defined in [XML-Namespaces 1.1]) for all candidates for ·assessment· and for all
·schema documents·.
Just as [XML 1.1] and
[XML-Namespaces 1.1] can be described in terms of
information items, XSD schemas can be described in terms of
an abstract data model. In defining schemas in terms of
an abstract data model, this specification rigorously specifies
the information which must be available to a conforming
XSD processor. The abstract model for schemas is
conceptual only, and does not mandate any particular
implementation or representation of this information. To
facilitate interoperation and sharing of schema information, a
normative XML interchange format for schemas is provided.
[Definition:] Schema
component is the generic term for the building blocks
that make up the abstract data model
of the schema. [Definition:] An XSD schema is a set of ·schema components·. There are
several kinds of schema component, falling
into three groups. The primary schema components, which may (type
definitions) or must (element and attribute declarations) have
names, are as follows:
Simple type definitions
Complex type definitions
Attribute declarations
Element declarations
The secondary schema components, are as
follows:
Finally, the "helper" schema components provide small
parts of other schema components; they are dependent on their context:
Annotations
Model groups
Particles
Wildcards
Attribute Uses
The
name [Definition:] Component covers all the different kinds of
schema component defined in this specification.
During ·validation·, [Definition:] declaration
components are associated by (qualified) name to information items
being ·validated·.
On the other hand, [Definition:] definition components define internal
schema components that can be used in other schema
components.
[Definition:] Declarations
and definitions may and in
some cases must have and be identified by
names, which are
NCNames as defined by [XML-Namespaces 1.1].
[Definition:] Several
kinds of component have a target namespace, which
is either ·absent· or a
namespace name, also as defined by [XML-Namespaces 1.1]. The ·target namespace· serves to identify
the namespace within which the association between the component
and its name exists.
An expanded name, as defined in
[XML-Namespaces 1.1], is a pair consisting
of a namespace name, which may be ·absent·, and a local
name. The expanded name of any component with both a
·target namespace· property and a
·component name· property is the pair
consisting of the values of those two properties.
The expanded name of a declaration is used to help
determine which information items will be
·governed· by
the declaration.
Note: At the abstract level, there is no requirement that the
components of a schema share a
·target namespace·. Any schema for
use in
·assessment· of documents
containing names from more than one namespace will of necessity
include components with different
·target namespaces·. This contrasts
with the situation at the level of the XML representation of
components, in which each schema document contributes
definitions and declarations to a single target namespace.
·Validation·, defined in detail
in Schema Component Details (§3), is a relation between information
items and schema components. For example, an attribute
information item is ·validated·
with respect to an attribute declaration, a list of element
information items with respect to a
content model, and so on. The following sections briefly
introduce the kinds of components in the schema abstract data
model, other major features of the abstract model, and how they
contribute to ·validation·.
...
...
...
2.2.4 Constraint Components
↑
XSD has three forms of constraint which
allow convenient expression of certain rules which would be
inconvenient, or impossible, to express otherwise. Identity-constraint
definitions are associated with element declarations;
assertions are associated with type definitions;
conditional type assignment using type alternatives allows
the type of an element instance to be chosen based on properties of
the element instance (in particular, based on the values of its
attributes).
↑
2.2.4.1 Identity-constraint Definition
An identity-constraint definition is an association between a name
and one of several varieties of identity-constraint related to
uniqueness and reference. All the varieties use [XPath 2.0] expressions to pick out sets of information
items relative to particular target element information items
which are unique, or a key, or a ·valid· reference, within a specified
scope. An element information item is only ·valid· with respect to an element
declaration with identity-constraint definitions if those definitions
are all satisfied for all the descendants of that element
information item which they pick out.
For detailed information on identity-constraint definitions, see
Identity-constraint Definitions (§3.11).
2.2.4.2 Type Alternative
A type-alternative
component
(type alternative for short)
associates a type definition with a predicate.
Type alternatives are used in conditional
type assignment, in which the choice of ·governing type definition·
for elements governed by a particular element declaration
depends on properties of the document instance. An element
declaration may have a {type table} which contains a
sequence of type alternatives; the predicates on the alternatives
are tested, and when a predicate is satisfied, the type
definition paired with it is chosen as the element instance's
·governing type definition·.
Note: The provisions for conditional type assignment are inspired by,
but not identical to, those of
[SchemaPath].
For detailed information on Type Alternatives, see
Type Alternatives (§3.12).
2.2.4.3 Assertion
An assertion is a predicate associated with a type, which is
checked for each instance of the type. If an element or attribute information item
fails to satisfy an assertion associated with a given type,
then that information item is not locally ·valid·
with respect to that type.
For detailed information on Assertions, see Assertions (§3.13).
↑
2.2.4.4 Overlapping Functionality of Constraint Components
Many rules that can be enforced by identity constraints
and conditional type assignment can also be formulated
in terms of assertions. That is, the various constructs have
overlapping functionality.
The three forms of constraint differ from each other in various
ways which may affect the schema author's choice of formulation.
Most obviously, the ·post-schema-validation infoset· will differ somewhat, depending
on which form of constraint is chosen.
Less obviously, identity constraints are associated with
element declarations, while assertions are associated with
type definitions. If it is desired to enforce a particular
property of uniqueness or referential integrity associated
with a particular element declaration E, of type T,
the schema author may often choose either an identity constraint
associated with E, or an assertion associated with T.
One obvious difference is that
elements substitutable for E
are required to have types derived from T, but
are not required to enforce the identity constraints (or
the nillability) of E. If the constraint applicable to E
should be enforced by elements substitutable for E, it
is often most convenient to formulate the constraint as
an assertion on T; conversely, if only some elements of
type T are intended to be subject to the constraint, or if
elements substitutable for E need not enforce the constraint, then it
will be more convenient to formulate the rule as an
identity constraint on E.
Similar considerations sometimes apply to the choice between
assertions and conditional type assignment.
Because identity constraints and conditional type assignment are
simpler and less variable than assertions, it may be easier
for software to exploit or optimize them. Assertions have
greater expressive power, which means they are often
convenient. The "rule of least power" applies here;
it is often preferable to use a less expressive notation in
preference to a more expressive one, when either will suffice.
See [Rule of Least Power].
↑
...
...
...
...
...
...
...