Table of contents

Appendices

3.15 Schemas as a Whole

A schema consists of a set of schema components.

NOTE: 

<xs:schema
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    targetNamespace="http://www.example.com/example">
  . . .
</xs:schema>

The XML representation of the skeleton of a schema.

The Schema Itself[top]

At the abstract level, the schema itself is just a container for its components.

XML Representations of Schemas[top]

A schema is represented in XML by one or more schema document, that is, one or more [schema] element information items. A schema document contains representations for a collection of schema components, e.g. type definitions and element declarations, which have a common [target namespace]. A schema document which has one or more [import] element information items corresponds to a schema with components with more than one [target namespace], see [Import Constraints and Semantics].

Note that none of the attribute information items displayed above correspond directly to properties of schemas. The blockDefault, finalDefault, attributeFormDefault, elementFormDefaultand targetNamespace attributes are appealed to in the sub-sections above, as they provide global information applicable to many representation/component correspondences. The other attributes (id and version) are for user convenience, and this specification defines no semantics for them.

The definition of the schema abstract data model in [XML Schema Abstract Data Model] makes clear that most components have a [target namespace]. Most components corresponding to representations within a given [schema] element information item will have a [target namespace] which corresponds to the targetNamespace attribute.

Since the empty string is not a legal namespace name, supplying an empty string for targetNamespace is incoherent, and is not the same as not specifying it at all. The appropriate form of schema document corresponding to a XML Schema whose components have no [e-target_namespace] is one which has no targetNamespace attribute specified at all.

NOTE: 

The XML namespaces Recommendation discusses only instance document syntax for elements and attributes; it therefore provides no direct framework for managing the names of type definitions, attribute group definitions, and so on. Nevertheless, the specification applies the target namespace facility uniformly to all schema components, i.e. not only declarations but also definitions have a [target namespace].

Although the example schema at the beginning of this section might be a complete XML document, [schema] need not be the document element, but can appear within other documents. Indeed there is no requirement that a schema correspond to a (text) document at all: it could correspond to an element information item constructed 'by hand', for instance via a DOM-conformant API.

Aside from [include] and [import], which do not correspond directly to any schema component at all, each of the element information items which may appear in the content of [schema] corresponds to a schema component, and all except [annotation] are named. The sections below present each such item in turn, setting out the components to which it may correspond.

References to Schema Components[top]

Reference to schema components from a schema document is managed in a uniform way, whether the component corresponds to an element information item from the same schema document or is imported ([References to schema components across namespaces]) from an external schema (which may, but need not, correspond to an actual schema document). The form of all such references is a QName.

A QName is a name with an optional namespace qualification, as defined in [ref-xml-namespaces]. When used in connection with the XML representation of schema components or references to them, this refers to the simple type QName as defined in [ref-xsp2].

An NCName is a name with no colon, as defined in [ref-xml-namespaces]. When used in connection with the XML representation of schema components in this specification, this refers to the simple type NCName as defined in [ref-xsp2].

In each of the XML representation expositions in the following sections, an attribute is shown as having type QName if and only if it is interpreted as referencing a schema component.

NOTE: 

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
            xmlns:xhtml="http://www.w3.org/1999/xhtml"
            xmlns="http://www.example.com"
            targetNamespace="http://www.example.com">
  . . .

  <xs:element name="elem1" type="Address"/>

  <xs:element name="elem2" type="xhtml:blockquote"/>

  <xs:attribute name="attr1"
                type="xsl:quantity"/>
  . . .
</xs:schema>

The first of these is most probably a local reference, i.e. a reference to a type definition corresponding to a [complexType] element information item located elsewhere in the schema document, the other two refer to type definitions from schemas for other namespaces and assume that their namespaces have been declared for import. See [References to schema components across namespaces] for a discussion of importing.

References to Schema Components from Elsewhere[top]

The names of schema components such as type definitions and element declarations are not of type ID: they are not unique within a schema, just within a symbol space. This means that simple fragment identifiers will not always work to reference schema components from outside the context of schema documents.

There is currently no provision in the definition of the interpretation of fragment identifiers for the text/xml MIME type, which is the MIME type for schemas, for referencing schema components as such. However, [ref-xpointer] provides a mechanism which maps well onto the notion of symbol spaces as it is reflected in the XML representation of schema components. A fragment identifier of the form #xpointer(xs:schema/xs:element[@name="person"]) will uniquely identify the representation of a top-level element declaration with name person, and similar fragment identifiers can obviously be constructed for the other global symbol spaces.

Short-form fragment identifiers may also be used in some cases, that is when a DTD or XML Schema is available for the schema in question, and the provision of an id attribute for the representations of all primary and secondary schema components, which is of type ID, has been exploited.

It is a matter for applications to specify whether they interpret document-level references of either of the above varieties as being to the relevant element information item (i.e. without special recognition of the relation of schema documents to schema components) or as being to the corresponding schema component.

Constraints on XML Representations of Schemas[top]

Where the type of an attribute information item in a document involved in valid is identified as QName, its actual value is composed of a local name and a namespace name. Its actual value is determined based on its normalized value and the containing element information item's [in-scope namespaces] following [ref-xml-namespaces]:

1. ifits normalized value is prefixed

   then

   1. There must be a namespace in the [in-scope namespaces] whose [prefix] matches the prefix.

   2. thenits namespace name is the [namespace name] of that namespace.

   3. Its local name is the portion of its normalized value after the colon (':').

2. otherwise(its normalized value is unprefixed)

   1. its local name is its normalized value.

   2. 1. ifthere is a namespace in the [in-scope namespaces] whose [prefix] has no value

         thenits namespace name is the [namespace name] of that namespace.

      2. otherwiseits namespace name is absent.

In the absence of the [in-scope namespaces] property in the infoset for the schema document in question, processors must reconstruct equivalent information as necessary, using the [ namespace attributes] of the containing element information item and its ancestors.

Whenever the word resolve in any form is used in this chapter in connection with a QName in a schema document, the following definition [QName resolution (Schema Document)] should be understood:

For a QName to resolve to a schema component of a specified kind

1. That component is a member of the value of the appropriate property of the schema which corresponds to the schema document within which the QName appears, that is

   1. ifthe kind specified is simple or complex type definition

      thenthe property is the [type_definitions].

   2. ifthe kind specified is attribute declaration

      thenthe property is the [attribute_declarations].

   3. ifthe kind specified is element declaration

      thenthe property is the [element_declarations].

   4. ifthe kind specified is attribute group

      thenthe property is the [attribute_group_definitions].

   5. ifthe kind specified is model group

      thenthe property is the [model_group_definitions].

   6. ifthe kind specified is notation declaration

      thenthe property is the [notation_declarations].

2. its [local name] matches the local name of the QName;

3. its [target namespace] is identical to the namespace name of the QName;

4. its namespace name is either the target namespace of the schema document containing the QName or that schema document contains an [import] element information item the actual value of whose namespace [attribute] is identical to that namespace name.

Validation Rules for Schemas as a Whole[top]

As the discussion above at [Schema Component Details] makes clear, at the level of schema components and valid, reference to components by name is normally not involved. In a few cases, however, qualified names appearing in information items being valid must be resolved to schema components by such lookup. The following constraint is appealed to in these cases.

A pair of a local name and a namespace name (or absent) resolve to a schema component of a specified kind in the context of valid by appeal to the appropriate property of the schema being used for the assessment. Each such property indexes components by name. The property to use is determined by the kind of component specified, that is,

1. ifthe kind specified is simple or complex type definition

   thenthe property is the [type_definitions].

2. ifthe kind specified is attribute declaration

   thenthe property is the [attribute_declarations].

3. ifthe kind specified is element declaration

   thenthe property is the [element_declarations].

4. ifthe kind specified is attribute group

   thenthe property is the [attribute_group_definitions].

5. ifthe kind specified is model group

   thenthe property is the [model_group_definitions].

6. ifthe kind specified is notation declaration

   thenthe property is the [notation_declarations].

Schema Information Set Contributions[top]

Schema components provide a wealth of information about the basis of assessment, which may well be of relevance to subsequent processing. Reflecting component structure into a form suitable for inclusion in the post-schema-validation infoset is the way this specification provides for making this information available.

Accordingly, by an item isomorphic to a component is meant an information item whose type is equivalent to the component's, with one property per property of the component, with the same name, and value either the same atomic value, or an information item corresponding in the same way to its component value, recursively, as necessary.

Processors must add a property in the post-schema-validation infoset to the element information item at which assessment began, as follows:

The [nsi-schema_components] property is provided for processors which wish to provide a single access point to the components of the schema which was used during assessment. Lightweight processors are free to leave it empty, but if it is provided, it must contain at a minimum all the top-level (i.e. named) components which actually figured in the assessment, either directly or (because an anonymous component which figured is contained within) indirectly.

In the post-schema-validation infoset a set of ID/IDREF binding information items is associated with the validation root element information item:

Let the eligible item set be the set of consisting of every attribute or element information item for which

1. its [validation context] is the validation root;

2. it was successfully valid with respect to an attribute declaration as per [Attribute Locally Valid] or element declaration as per [Element Locally Valid (Element)] (as appropriate) whose attribute [a-simple_type_definition] or element [type_definition] (respectively) is the built-in ID, IDREF or IDREFS simple type definition or a type derived from one of them.

Then there is one ID/IDREF binding in the [e-ii_table] for every distinct string which is

1. the actual value of a member of the eligible item set whose type definition is or is derived from ID or IDREF;

2. one of the items in the actual value of a member of the eligible item set whose type definition is or is derived from IDREFS.

Each ID/IDREF binding has properties as follows:

1. its [e-validation_context] is the validation root;

2. it has an attribute information item in its [attributes] or an element information item in its [children] which was valid by the built-in ID simple type definition or a type derived from it whose [schema normalized value] is the [iib-id] of this ID/IDREF binding.

The net effect of the above is to have one entry for every string used as an id, whether by declaration or by reference, associated with those elements, if any, which actually purport to have that id. See [Validation Root Valid (ID/IDREF)] above for the validation rule which actually checks for errors here.

NOTE: 

The ID/IDREF binding information item, unlike most other aspects of this specification, is essentially an internal bookkeeping mechanism. It is introduced to support the definition of [Validation Root Valid (ID/IDREF)] above. Accordingly, conformant processors may, but are not required to, expose it in the post-schema-validation infoset. In other words, the above constraint may be read as saying assessment proceeds as if such an infoset item existed.

Constraints on Schemas as a Whole[top]

All schemas (see [Schemas as a Whole]) must satisfy the following constraint.

1. The values of the properties of a schema must be as described in the property tableau in [The Schema Itself], modulo the impact of [Missing Sub-components];

2. Each of the [type_definitions], [element_declarations], [attribute_group_definitions], [model_group_definitions] and [notation_declarations] must not contain two or more schema components with the same [name] and [target namespace].