Use Cases for XML Schema PSVI API

This Version:

Latest Version:

Previous Version: not available


David Ezell, Charles E. Campbell


Validating an XML instance document with an XML Schema suggests the existence of information describing the XML 1.0 Infoset in the context of schema validation. This information, along with the XML 1.0 infoset of the instance, is known collectively as the "post schema validation infoset" of an instance validation, or PSVI. The use cases contained in this project attempt to describe common or beneficial uses of the PSVI. By describing such uses, it is possible to recommend specific methods for gaining access to the information, promoting interoperability. In this document we use the term PSVI API to refer to those methods in the abstract.


Status of this Document

This document is for internal use of the XML Schema Working Group and interested parties. It is not an official W3C publication, and the WG makes no claims about its accuracy or suitability for any purpose.

1.0 Problem Statement

Schema information affects a variety of activities in applications which process XML documents. Some such applications and activities include [Not an exaustive list]:

Allowing applications a consistent view of schema validation information will benefit both XML processors and their client applications, making system software less brittle, and will in general be a good thing [1].

The following terms have specific meanings in this document:

The following diagram illustrates three APIs (see the note above) and their relationship to their respective components in the PSVI. Note that the Schema Component API maps to the schema component infoset, and the IIAPI and IIEAPI map to the instance infoset [2].

View 1

The "instance infoset enhancement" API (IIEAPI) must somehow provide the following information:

  1. which specific schema component serves as the definition for the currently accessed instance information item,
  2. which schema component matches the instance information item in the current validation.

Often the same schema component both matches and defines the same instance information item. But in cases where "xsi:type", substitution groups, or wildcards are in play, it's possible to have one schema component define (or provide a declaration for) an instance information item while a different schema component matches it. More complex situations might require simultaneous changes to schemas and to the instances they constrain. In such situations the schema components would be modified indirectly by changing the schema documents defining them and rebuilding the schema components. While synchronization of the schema components with the schema transfer syntax is an important design goal of the XML Schema WG, a complete "round trip" of such components is out of scope for this effort.

View 2

In this case, editing the schema is essentially the same as editing any XML document validated by a schema. Note that the "schema component infoset" must contain information on the composition of the schema from the schema documents.

Most users of schema information use view 1, with a smaller number needing view 2.
The following kinds of information are representative of what may be required during document handling and editing [3]:

  1. the schema component that defines an instance information item, as well as the schema component that matches that item.
  2. whether the adding or deleting of a specific III at a given point will cause the document to become schema invalid.
  3. the list of valid IIIs which could be added or deleted at a given position in a document.

The goal of this proposal is to establish a set of conventions for accessing schema information; these conventions are hereinafter called "the system".

2.0 Statement of Work

2.1 Scope

2.1.1 In Scope

Defining methods which:

2.1.2 Out of Scope

Reserializing schema documents into schema transfer syntax from schema components.

2.2 Objectives

The system will provide a coherent and extensible way to retrieve schema information, and will support editing of both schemas and instance documents. Only serialization of instance documents (though these may in fact be schema documents) will be supported.

2.3 Application Overview

The system will maintain some model of an instance (may be empty), the schema components against which that instance was validated, and the relationships between the them. The component models defined must be usable by other w3c groups and recommendations.

2.4 User Demography -- User class needs

2.5 Constraints

The schema component API will be read only. Editing will only be allowed through the instance information item API.


2.6 Assumptions



2.7 Deliverables


2.8 Expected Duration

3.0 Candidate Use Case Titles

PSVI Use Cases:

Schema Component Use Cases:



[1] Granted, controlling document processing based on a schema component infoset may occur whether or not the schema information is available in a generic form to processing applications, since applications may be hard-coded to conform to the rules expressed in a given schema.

[2] The two common instances of APIs for the instance infoset (IIAPIs) are DOM and SAX. Commonly used interfaces could be extended to expose the IIEAPI.

[3] The use cases will refine and extend this list.

[4] API should not be construed to mean only the common use of the term (a set of related function calls or object interfaces), since the result of this requirements effort will not be a set of interfaces in a specific programming language, nor will it be a set of IDL definitions. Rather, this effort attempts to identify the things (entities) available after schema validation which are useful to applications and users, to identify the types (or responsibilities) of those things, and to describe their relationships to one another.