DRAFT

For XML Schema

This is three sections of the XML Schema CR with revised markup.

There is a plain version.

Notes

$Revision: 1.3 $ of $Date: 2001/01/08 05:16:40 $ by $Author: slesch $


2.4 Conformance

This specification describes three levels of conformance for schema aware processors. The first is required of all processors. Support for the other two will depend on the application environments for which the processor is intended.

[Definition:]  Minimally conforming processors must completely and correctly implement the Constraints on Schemas, Validity Rules, and Schema Information Set Contributions contained in this specification.

[Definition:]  Processors which accept schemas in the form of XML documents as described in XML Representation of Schemas and Schema Components (§4) are additionally said to provide conformance to the XML Representation of Schemas. Such processors must, when processing schema documents, completely and correctly implement all Schema Representation Constraints in this specification, and must adhere exactly to the specifications in XML Representation of Schemas and Schema Components (§4) for mapping the contents of such documents to schema components for use in validation and assessment.

NOTE: By separating the conformance requirements relating to the concrete syntax of XML schema documents, this specification admits processors which use schemas stored in optimized binary representations, dynamically created schemas represented as programming language data structures, or implementations in which particular schemas are compiled into executable code such as C or Java. Such processors can be said to be minimally conforming but not necessarily in conformance to the XML Representation of Schemas.

[Definition:]  Fully conforming processors are network-enabled processors which support both levels of conformance described above, and which must additionally be capable of accessing schema documents from the World Wide Web according to Representation of Schemas on the World Wide Web (§2.7) and How schema definitions are located on the Web (§6.3.2).

NOTE: Although this specification provides just these three standard levels of conformance, it is anticipated that other conventions can be established in the future. For example, the World Wide Web Consortium is considering conventions for packaging on the Web a variety of resources relating to individual documents and namespaces. Should such developments lead to new conventions for representing schemas, or for accessing them on the Web, new levels of conformance can be established and named at that time. There is no need to modify or republish this specification to define such additional levels of conformance.

See Schema Access and Composition (§6) for a more detailed explanation of the mechanisms supporting these levels of conformance.


4.1 Datatype definition

Datatype definitions provide for:

The datatype definition schema component has the following properties:

Schema Component: Datatype Definition

[name]
Optional. An NCName as defined by [Namespaces in XML].
[target namespace]
Either null or a namespace URI, as defined in [Namespaces in XML].
[variety]
One of {atomic, list, union}. Depending on the value of {variety}, further properties are defined as follows:
atomic
[primitive type definition]
A built-in primitive datatype definition (or the simple ur-type definition).
list
[itemType definition]
An atomic or union datatype definition.
union
[memberType definitions]
A non-empty sequence of simple type definitions.
[facets]
A possibly empty set of Constraining facets (§4.2).
[fundamental facets]
A set of Fundamental facets (§2.4.1)
[base type definition]
Optional. If the datatype has been derived by restriction then the datatype definition from which it is derived, otherwise absent.
[annotation]
Optional. An annotation.

Datatypes are identified by their {name} and {target namespace}. Except for anonymous datatypes (those with no {name}), datatype definitions must be uniquely identified within an schema.

If {variety} is atomic then the value space of the datatype defined will be a subset of the value space of {base type definition} (which is a subset of the value space of {primitive type definition}). If {variety} is list then the value space of the datatype defined will be the set of finite-length sequence of values from the value space of {itemType definition}. If {variety} is union then the value space of the datatype defined will be the union of the value spaces of each datatype in {memberType definitions}.

If {variety} is atomic then the {variety} of {base type definition} must be atomic. If {variety} is list then the {variety} of {itemType definition} must be either atomic or union. If {variety} is union then {memberType definitions} must be a list of datatype definitions.

The value of {facets} consists of the set of facets specified directly in the datatype definition unioned with the possibly empty set of {facets} of {base type definition}.

The value of {fundamental facets} consists of the set of fundamental facets and their values.

If {variety} is atomic then bounded is true and cardinality is finite if one of minInclusive or minExclusive and one of maxInclusive or maxExclusive are among {facets}, otherwise bounded is false and cardinality is countably infinite, numeric and ordered are inherited from {base type definition}.

If {variety} is list then bounded is true and cardinality is finite if length or both of minLength and maxLength are among {facets}, otherwise bounded is false and cardinality is countably infinite, numeric and ordered are false.

If {variety} is union then bounded is true if every member of {memberType definitions} is bounded and all members of {memberType definitions} share a common ancestor and is false otherwise, cardinality is finite if the cardinality of every member of {memberType definitions} is finite and is countably infinite otherwise, ordered is true if every member of {memberType definitions} is ordered and all members of {memberType definitions} share a common ancestor and is false otherwise, numeric are true if every member of {memberType definitions} is numeric and is false otherwise.

Constraint on Schemas: applicable facets

The constraining facets which are allowed to be members of {facets} are dependent on {base type definition} as specified in the following table:

  {base type definition} applicable {facets}
If {variety} is list, then
  All datatypes length, minLength, maxLength, enumeration, whiteSpace
If {variety} is union, then
  All datatypes pattern, enumeration
else if {variety} is atomic, then
primitive string length, minLength, maxLength, pattern, enumeration, whiteSpace
boolean pattern, whiteSpace
float pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
double
decimal precision, scale, pattern, whiteSpace, enumeration, maxInclusive, maxExclusive, minInclusive, minExclusive
timeDuration pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
recurringDuration duration, period, pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
binary encoding, length, minLength, maxLength, pattern, enumeration, whiteSpace
uriReference length, minLength, maxLength, pattern, enumeration, whiteSpace
ID length, minLength, maxLength, pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
IDREF
ENTITY
QName
derived CDATA length, minLength, maxLength, pattern, enumeration, whiteSpace
token
language
NMTOKEN
Name
NCName
NOTATION length, minLength, maxLength, pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
integer precision, scale, pattern, whiteSpace, enumeration, maxInclusive, maxExclusive, minInclusive, minExclusive
nonPositiveInteger
negativeInteger
long
int
short
byte
nonNegativeInteger
unsignedLong
unsignedInt
unsignedShort
unsignedByte
positiveInteger
timeInstant duration, period, pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
time
timePeriod
date
month
year
century
recurringDate
recurringDay

Constraint on Schemas: list of atomic

If {variety} is list, then the {variety} of {itemType definition} must be atomic or union.

Validation Rule: Datatype Valid

A string is datatype-valid with respect to a datatype definition if:

  1. it matches a literal in the lexical space of the datatype, determined as follows:
    1. if {variety} is atomic then the string must match a literal in the lexical space of {base type definition}
    2. if {variety} is list then the string must be a sequence of white space separated tokens, each of which matches a literal in the lexical space of {itemType definition}
    3. if {variety} is union then the string must match a literal in the lexical space of at least one member of {memberType definitions}
  2. the value denoted by the literal matched in the previous step is a member of the value space of the datatype, as determined by it being Facet Valid (§4.2) with respect to each member of {facets}.

5.2.5 enumeration

The XML representation for an enumeration schema component is an enumeration element information item. The correspondences between the properties of the information item and properties of the component are as follows:

XML Representation Summary

enumeration Element Information Item
<enumeration
  id = ID
  value = string
  fixed = boolean : false
  {any attributes with non-schema namespace. . .}>
  Content: (annotation?)
</enumeration>
{value} must be a valid value of the {base type definition}.
enumeration Schema Component
Property Representation
{value} The value of the value  [attribute]
{annotation} The annotation corresponding to the annotation element information item in the [children], if present, otherwise null

Schema Representation Constraint: Multiple enumerations

If multiple enumeration element information items appear as  [children] of a simpleType the {value} of the enumeration component should be the set of all such  [value]s.

The following example is a datatype definition for a user-derived datatype which limits the values of dates to the three US holidays enumerated. This datatype definition would appear in a schema authored by an "end-user" and shows how to define a datatype by enumerating the values in its value space. The enumerated values must be type-valid literals for the base type.

<simpleType name='holidays'>
    <annotation>
        <documentation>some US holidays</documentation>
    </annotation>
    <restriction base='recurringDate'>
      <enumeration value='--01-01'>
        <annotation>
            <documentation>New Year's day</documentation>
        </annotation>
      </enumeration>
      <enumeration value='--07-04'>
        <annotation>
            <documentation>4th of July</documentation>
        </annotation>
      </enumeration>
      <enumeration value='--12-25'>
        <annotation>
            <documentation>Christmas</documentation>
        </annotation>
      </enumeration>
    </restriction>  
</simpleType>