Schema Evolution publication categorizer

The W3C XML Schema recommendation defines the structure and data types for XML documents.
XML Schema lacks explicit support for time-varying XML documents or for time-varying schemas. An
XML document evolves as it is updated over time or as it accumulates from a streaming data source. A
temporal document records the entire history of a document rather than just its current state or snapshot.
Capturing a document’s evolution is vital to providing the ability to recover past versions, track changes
over time, and evaluate temporal queries. Capturing the evolution of a document’s schema is similarly
important. To date, users have to resort to ad hoc, non-standard mechanisms to create schemas for
time-varying XML documents and to deal with evolving schemas.
This report presents a data model and architecture, called XSchema, for constructing and validating
temporal XML documents through the use of a temporal schema. A temporal schema guides the
construction of a temporal document and is essential to managing, querying, and validating temporal
documents. The temporal schema consists of a non-temporal (conventional) schema, logical annotation(
s), and physical annotation(s). The annotations specify which portion(s) of an XML document can
vary over time, how the document can change, and where timestamps should be placed. These components
can themselves individually evolve over time. The advantage of using annotations to denote
the time-varying aspects is that logical and physical data independence for temporal schemas can be
achieved while remaining fully compatible with both existing XML Schema documents and the XML
Schema recommendation. This report also describes how to construct a temporal document by “gluing”
individual snapshots into an integrated history.
This technical report is divided into three parts: concerning instance versioning, extending to schema
versioning, and reviewing the entire XSchema language. The first two parts have a parallel structure.
Each begins by discussing relevant related work before providing a motivating example that illustrates
the challenges of instance and schema versioning, respectively, then lists design decisions made in
XSchema concerning that challenge. Theoretical considerations (separately for instance and schema
versioning), architectural considerations, and implementation details are discussed in that order in each
of the two parts. Each part ends with full example schema and instance documents. The third part completes
the picture with a discussion of related work and research topics to be considered in the future.