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
David Ezell David_E3@verifone.com, Charles E. Campbell firstname.lastname@example.org
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.
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.
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 .
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 .
The "instance infoset enhancement" API (IIEAPI) must somehow provide the following information:
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.
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 :
The goal of this proposal is to establish a set of conventions for accessing schema information; these conventions are hereinafter called "the system".
Defining methods which:
Reserializing schema documents into schema transfer syntax from schema
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.
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.
The schema component API will be read only. Editing will only be allowed through the instance information item API.
 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.
 The use cases will refine and extend this list.
 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