Use Cases for XML Schema PSVI API

This Version: http://www.w3.org/XML/2002/05/psvi-use-cases-20020624

Latest Version: http://www.w3.org/XML/2002/05/psvi-use-cases

Previous Version: not available

Editors:

David Ezell David_E3@verifone.com, Charles E. Campbell chuckc@us.ibm.com

Abstract

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]:

• Document Instance Editors
• RPC Servers
• Forms Generators and Agents
• Stylesheet Editors and Processors.

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:

• Application Programming Interface (API). A predefined and cohesive set of methods which work together for some purpose in a computer system [4]. In this project, we use API to mean methods for using information in the post schema validation infoset.
  
  
• "schema component infoset" refers to the composite of the infosets of the schema documents parsed to create the "effective schema". These infosets are not the same as the XML1.0 infosets for the schema documents themselves: they reflect the schema components described in the recommendation.
• "instance information item" (III) refers to things described in the XML1.0 infoset from the instance, usually element or attribute information items.
• "post schema validation infoset" (PSVI) means the information resulting from an XML document having been schema validated. The resulting information has three parts:
  • the "instance infoset" (the XML1.0 infoset from the instance)
  • the "schema component infoset", and
  • "instance infoset enhancement", or information that describes the
    relationship between items in the instance infoset and in the schema component
    infoset.

   

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:

• support controlled modification of instance documents based on schema constraints (instance documents may be schemas).
• reveal information about schema components.
• allow changes to schema components.
• reveal information regarding instance information items in their schema valid context.
• reveal information about composition, including "import", "include", named model groups, and attribute groups.

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

• tools authors view 2
• tools / application authors view 2
• applications / instance authors view 1
• schema authors view 2

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:

• Determine the definition of an instance information item.

  UseCase Model -- Schema

  Stylesheet

  UseCase XML Document

• Determine the supertype(s) of an instance information item.
• Determine the validity of a proposed change to an instance information item.
• Determine possible valid information items which could be inserted at a given point in an instance.
• Generate a schema from an instance document.
• Find all information items in an instance which can match a given schema component.
• Find all schema components which will match a given instance information item.

Schema Component Use Cases:

• Generate a schema from an instance document.
• Generate an example instance document from a schema infoset.
• Generate an instance document from a schema infoset and a set of name/value pairs (Forms).
• Browse schema components in a schema infoset.
• Generate a 'form agent' from a schema component infoset.
• Create a data dictionary from a schema component infoset.
• Create program classes from a schema component infoset.
• Reverse engineer potential XPath expressions from schema component matching information.
  

Notes:

[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.