You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
358 lines
15 KiB
358 lines
15 KiB
<!DOCTYPE html PUBLIC '-//W3C//DTD HTML 4.0 Transitional//EN'>
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE>XML Schema Requirements</TITLE>
|
|
<LINK rel="stylesheet" type="text/css" media="screen"
|
|
href="/StyleSheets/TR/W3C-NOTE.css">
|
|
<meta name="RCS-Id" content="$Id: NOTE-xml-schema-req-19990215.html,v 1.3 1999/02/15 22:17:16 renaudb Exp $">
|
|
</HEAD>
|
|
|
|
<BODY>
|
|
<div class="head">
|
|
<p><A HREF="http://www.w3.org/">
|
|
<img style="float: left; border: none"
|
|
border="0"
|
|
align="left"
|
|
height="48"
|
|
width="72"
|
|
src="http://www.w3.org/Icons/WWW/w3c_home"
|
|
alt="W3C"></A></p>
|
|
<p align="right" style="text-align: right">
|
|
<strong>NOTE-xml-schema-req-19990215</strong></p>
|
|
|
|
<div align="center">
|
|
<P class="hide"><br clear=left></P>
|
|
<H1 ALIGN="center">XML Schema Requirements</H1>
|
|
<h2>W3C Note 15 February 1999</h2>
|
|
<P class="hide"><BR clear=left></P>
|
|
</div>
|
|
<table>
|
|
<tr valign="baseline"><td>This version:
|
|
<TD><A class="loc" HREF="http://www.w3.org/TR/1999/NOTE-xml-schema-req-19990215">
|
|
http://www.w3.org/TR/1999/NOTE-xml-schema-req-19990215</A>
|
|
<tr valign="baseline"><td>Latest version:
|
|
<TD><A HREF="http://www.w3.org/TR/NOTE-xml-schema-req"
|
|
class="loc">http://www.w3.org/TR/NOTE-xml-schema-req</A>
|
|
<tr valign="baseline"><TD>Editors:
|
|
<TD><span class="author"><span class="name">Ashok Malhotra</span>
|
|
<i>(<span class="email"><A HREF="mailto:petsa@us.ibm.com">petsa@us.ibm.com</A></span>)</i></span>
|
|
for IBM<BR>
|
|
<span class="author"><span class="name">Murray Maloney</span>
|
|
<i>(<span class="email"><A HREF="mailto:murray@muzmo.com">murray@muzmo.com</A></span>)</i></span>
|
|
for Veo Systems Inc.
|
|
</table>
|
|
</div>
|
|
<p><small><A href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">
|
|
Copyright</A> © 1999 <A href="http://www.w3.org/">W3C</A>
|
|
(<A href="http://www.lcs.mit.edu/">MIT</A>,
|
|
<A href="http://www.inria.fr/">INRIA</A>,
|
|
<A href="http://www.keio.ac.jp/">Keio</A>), All Rights Reserved. W3C
|
|
<A href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</A>,
|
|
<A href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</A>,
|
|
<A href="http://www.w3.org/Consortium/Legal/copyright-documents">document
|
|
use</A> and
|
|
<A href="http://www.w3.org/Consortium/Legal/copyright-software">software
|
|
licensing</A> rules apply.</small></p>
|
|
|
|
|
|
<DIV>
|
|
<H4>Status of this document</H4>
|
|
|
|
<P>This is a W3C Note published on 15 February 1999 as a deliverable of
|
|
the <a href="http://www.w3.org/XML/Activity#schema-wg">XML Schema
|
|
Working Group</a>, which is part of the W3C
|
|
<a href="http://www.w3.org/XML/Activity">XML Activity</a>. It lists a
|
|
base set of agreed requirements for an XML schema language.</P>
|
|
|
|
<P>This document represents a compromise that leaves many design
|
|
questions open, creating opportunity for decision-making in the design
|
|
phase. As the XML Schema work continues, the concrete implications of
|
|
these requirements for the design will be worked out and documented.
|
|
This document is a living document; it will be reviewed regularly by
|
|
the Working Group, and may be revised to reflect changes in the
|
|
Working Group's understanding. The Working Group does not anticipate
|
|
substantial changes, but may decide to refine existing requirements or
|
|
add new ones. </P>
|
|
|
|
<P>Comments about this document should be addressed to the <A
|
|
HREF="http://lists.w3.org/Archives/Public/www-xml-schema-comments">
|
|
XML Schema Requirements
|
|
Comments list</A> at <A
|
|
HREF="mailto:www-xml-schema-comments@w3.org">
|
|
www-xml-schema-comments@w3.org</a>. Comments accumulated by 1 March
|
|
1999 will be reviewed in March 1999. </P>
|
|
|
|
<P>A list of current W3C technical reports and publications, including
|
|
working drafts and notes, can be found at <A
|
|
HREF="http://www.w3.org/TR">http://www.w3.org/TR</A>.</P>
|
|
|
|
</DIV>
|
|
|
|
<DIV>
|
|
<H4>Abstract</H4>
|
|
<P>This document specifies the purpose, basic usage scenarios, design
|
|
principles, and base requirements for an XML schema language.</P></DIV>
|
|
|
|
<DIV>
|
|
<H2>Table of Contents</H2><OL>
|
|
<LI><A HREF="#Overview">Overview</A></LI>
|
|
<LI><A HREF="#Purpose">Purpose</A></LI>
|
|
<LI><A HREF="#Scenarios">Scenarios</A></LI>
|
|
<LI><A HREF="#Principles">Principles</A></LI>
|
|
<LI><A HREF="#Requirements">Requirements</A><UL>
|
|
<LI><A HREF="#Structural">Structural schemas</A></LI>
|
|
<LI><A HREF="#Datatype">Datatypes</A></LI>
|
|
<LI><A HREF="#Conformance">Conformance</A></LI>
|
|
</UL></LI>
|
|
</OL></DIV>
|
|
|
|
<DIV>
|
|
<H2><A NAME="Overview">1. Overview</A> </H2>
|
|
|
|
<P>The XML 1.0 specification defines the concepts of well-formedness and
|
|
validity; it is very simple to check a document for well-formedness, while
|
|
validation requires more work but allows the user to define more powerful
|
|
constraints on document structure. XML validity requires that a document
|
|
follow the constraints expressed in its document type definition, which
|
|
provides the rough equivalent of a context-free grammar for a document
|
|
type.</P>
|
|
|
|
<P>For some uses, applications may need definitions of markup constructs
|
|
more informative, or constraints on document structure tighter than,
|
|
looser than, or simply different from those which can be expressed using
|
|
document type definitions as defined in XML 1.0. There is also a
|
|
widespread desire to allow markup constructs and constraints to be
|
|
specified in an XML-based syntax, in order to allow tools for XML
|
|
documents to be used on the specifications.</P>
|
|
|
|
<P>By charter, the XML Schema Working Group is assigned to address the following
|
|
issues: </P>
|
|
|
|
<DL>
|
|
<DT>structural schemas</DT>
|
|
<DD>a mechanism somewhat analogous to DTDs for constraining document
|
|
structure (order, occurrence of elements, attributes). Specific goals
|
|
beyond DTD functionality are
|
|
<UL>
|
|
<LI>integration with namespaces </LI>
|
|
<LI>definition of incomplete constraints on the content of an element
|
|
type </LI>
|
|
<LI>integration of structural schemas with primitive data types </LI>
|
|
<LI>inheritance: Existing mechanisms use content models to specify
|
|
part-of relations. But they only specify kind-of relations
|
|
implicitly or informally. Making kind-of relations explicit would
|
|
make both understanding and maintenance easier</LI>
|
|
</UL></DD>
|
|
<DT>primitive data typing</DT>
|
|
<DD>integers, dates, and the like, based on experience with SQL, Java
|
|
primitives, etc.; byte sequences ("binary data") also need to
|
|
be considered</DD>
|
|
<DT>conformance </DT>
|
|
<DD>The relation of schemata to XML document instances, and obligations
|
|
on schema-aware processors, must be defined. The Working Group will define a
|
|
process for checking to see that the constraints expressed in a schema
|
|
are obeyed in a document (schema-validation); the relationship between
|
|
schema-validity and validity as defined in XML 1.0 will be defined.</DD>
|
|
</DL>
|
|
|
|
<P>The XML Schema work is interdependent with several other areas of W3C
|
|
activity. These are listed below under <A HREF="#Principles">Design
|
|
Principles</A>.</P>
|
|
</DIV>
|
|
|
|
|
|
<H2><A NAME="Purpose">2. Purpose</A></H2>
|
|
|
|
<P>The purpose of the XML schema language is to provide an inventory of XML
|
|
markup constructs with which to write schemas. </P>
|
|
|
|
<P>The purpose of a schema is to define and describe a class of XML
|
|
documents by using these constructs to constrain and document the meaning,
|
|
usage and relationships of their constituent parts: datatypes, elements
|
|
and their content, attributes and their values, entities and their
|
|
contents and notations. Schema constructs may also provide for the
|
|
specification of implicit information such as default values. Schemas
|
|
document their own meaning, usage, and function.</P>
|
|
|
|
<P>Thus, the XML schema language can be used to define, describe and
|
|
catalogue XML vocabularies for classes of XML documents. </P>
|
|
|
|
<P>Any application of XML can use the Schema formalism to express
|
|
syntactic, structural and value constraints applicable to its document
|
|
instances. The Schema formalism will allow a useful level of constraint
|
|
checking to be described and validated for a wide spectrum of XML
|
|
applications. For applications which require other, arbitrary or
|
|
complicated constraints, the application must perform its own additional
|
|
validations.</P>
|
|
|
|
<H2><A NAME="Scenarios">3. Usage Scenarios</A></H2>
|
|
|
|
<P>The following usage scenarios describe XML applications that should
|
|
benefit from XML schemas. They represent a wide range of activities and
|
|
needs that are representative of the problem space to be addressed. They
|
|
are intended to be used during the development of XML schemas as design
|
|
cases that should be reviewed when critical decisions are made. These
|
|
usage scenarios should also prove useful in helping non-members of the XML
|
|
Schema Working Group understand the intent and goals of the project. </P>
|
|
|
|
<OL>
|
|
<LI>Publishing and syndication
|
|
<P>Distribution of information through publishing and syndication
|
|
services. Involves collections of XML documents with complex relations
|
|
among them. Structural schemas describe the properties of headlines,
|
|
news stories, thumbnail images, cross-references, etc. Document views
|
|
under control of different versions of a schema. </P></LI>
|
|
<LI>Electronic commerce transaction processing.
|
|
<P>Libraries of schemas define business transactions within markets and
|
|
between parties. A schema-aware processor is used to validate a
|
|
business document, and to provide access to its information set. </P></LI>
|
|
<LI>Supervisory control and data acquisition.
|
|
<P>The management and use of network devices involves the exchange of
|
|
data and control messages. Schemas can be used by a server to ensure
|
|
outgoing message validity, or by the client to allow it to determine
|
|
what part of a message it understands. In multi-vendor environment,
|
|
discriminates data governed by different schemas (industry-standard,
|
|
vendor-specific) and know when it is safe to ignore information not
|
|
understood and when an error should be raised instead; provide
|
|
transparency control. Applications include media devices, security
|
|
systems, plant automation, process control. </P></LI>
|
|
<LI>Traditional document authoring/editing governed by schema
|
|
constraints.
|
|
<P>One important class of application uses a schema definition to guide
|
|
an author in the development of documents. A simple example might be a
|
|
memo, whereas a more sophisticated example is the technical service
|
|
manuals for a wide-body intercontinental aircraft. The application can
|
|
ensure that the author always knows whether to enter a date or a
|
|
part-number, and might even ensure that the data entered is valid.</P></LI>
|
|
<LI>Use schema to help query formulation and optimization.
|
|
<P>A query interface inspect XML schemas to guide a user in the
|
|
formulation of queries. Any given database can emit a schema of itself
|
|
to inform other systems what counts as legitimate and useful queries.</P></LI>
|
|
<LI>Open and uniform transfer of data between applications, including
|
|
databases
|
|
<P>XML has become a widely used format for encoding data (including
|
|
metadata and control data) for exchange between loosely coupled
|
|
applications. Such exchange is currently hampered by the difficulty of
|
|
fully describing the exchange data model in terms of XML DTDs;
|
|
exchange data model versioning issues further complicate such
|
|
interactions. When the exchange data model is represented by the more
|
|
expressive XML Schema definitions, the task of mapping the exchange
|
|
data model to and from application internal data models will be
|
|
simplified. </P> </LI>
|
|
<LI>Metadata Interchange
|
|
<P>There is growing interest in the interchange of metadata (especially
|
|
for databases) and in the use of metadata registries to facilitate
|
|
interoperability of database design, DBMS, query, user interface, data
|
|
warehousing, and report generation tools. Examples include ISO 11179
|
|
and ANSI X3.285 data registry standards, and OMG's proposed XMI
|
|
standard. </P></LI>
|
|
</OL>
|
|
|
|
<H2><A NAME="Principles">4. Design Principles</A></H2>
|
|
|
|
<DIV>
|
|
|
|
<P>In the design of any language, trade-offs in the solution space are
|
|
necessary. The following design principles should guide the working group
|
|
in making these trade-offs. Design principles are desirable, but not fully
|
|
measurable, characteristics. </P>
|
|
|
|
<P><B>The XML schema language shall be:</B></P>
|
|
|
|
<OL>
|
|
<LI>more expressive than XML DTDs; </LI>
|
|
<LI>expressed in XML;</LI>
|
|
<LI>self-describing;</LI>
|
|
<LI>usable by a wide variety of applications that employ XML;</LI>
|
|
<LI>straightforwardly usable on the Internet;</LI>
|
|
<LI>optimized for interoperability;</LI>
|
|
<LI>simple enough to implement with modest design and runtime resources;</LI>
|
|
<LI>coordinated with relevant W3C specs (XML Information Set, Links,
|
|
Namespaces, Pointers, Style and Syntax, as well as DOM, HTML, and RDF
|
|
Schema).</LI>
|
|
</OL>
|
|
|
|
</DIV>
|
|
|
|
<DIV>
|
|
<P><B>The XML schema language specification shall:</B></P><OL>
|
|
<LI>be prepared quickly;</LI>
|
|
<LI>be precise, concise, human-readable, and illustrated with examples.</LI>
|
|
</OL>
|
|
</DIV>
|
|
|
|
|
|
<H2><A NAME="Requirements">5. Requirements</A></H2>
|
|
|
|
<DIV>
|
|
|
|
<H3><A NAME="Structural">Structural requirements</A></H3>
|
|
|
|
<P>The XML schema language must define:</P>
|
|
|
|
<OL>
|
|
<LI>mechanisms for constraining document structure (namespaces, elements,
|
|
attributes) and content (datatypes, entities, notations);</LI>
|
|
<LI>mechanisms to enable inheritance for element, attribute, and datatype
|
|
definitions; </LI>
|
|
<LI>mechanism for URI reference to standard semantic understanding of a
|
|
construct;</LI>
|
|
<LI>mechanism for embedded documentation;</LI>
|
|
<LI>mechanism for application-specific constraints and descriptions;</LI>
|
|
<LI>mechanisms for addressing the evolution of schemata;</LI>
|
|
<LI>mechanisms to enable integration of structural schemas with primitive
|
|
data types.</LI>
|
|
</OL>
|
|
|
|
</DIV>
|
|
|
|
<DIV>
|
|
|
|
<H3><A NAME="Datatype">Datatype requirements</A></H3>
|
|
|
|
<P>The XML schema language must:</P>
|
|
|
|
<OL>
|
|
<LI>provide for primitive data typing, including byte, date, integer,
|
|
sequence, SQL & Java primitive data types, etc.;</LI>
|
|
<LI>define a type system that is adequate for import/export from database
|
|
systems (e.g., relational, object,
|
|
<A HREF="http://www.olapcouncil.org/">OLAP</A>); </LI>
|
|
<LI>distinguish requirements relating to lexical data representation vs.
|
|
those governing an underlying information set;</LI>
|
|
<LI> allow creation of user-defined datatypes, such as datatypes that are
|
|
derived from existing datatypes and which may constrain certain of its
|
|
properties (e.g., range, precision, length, mask).</LI>
|
|
</OL>
|
|
|
|
</DIV>
|
|
|
|
<DIV>
|
|
|
|
<H3><A NAME="Conformance">Conformance</A></H3>
|
|
|
|
<P>The XML schema language must:</P>
|
|
|
|
<OL>
|
|
<LI>describe the responsibilities of conforming processors;</LI>
|
|
<LI>define the relationship between schemas and XML documents;</LI>
|
|
<LI>define the relationship between schema validity and XML validity;</LI>
|
|
<LI>define the relationship between schemas and XML DTDs, and their
|
|
information sets;</LI>
|
|
<LI>define the relationship among schemas, namespaces, and validity;
|
|
</LI>
|
|
<LI>define a useful XML schema for XML schemas; </LI>
|
|
</OL>
|
|
|
|
</DIV>
|
|
|
|
</BODY>
|
|
</HTML>
|
|
<!-- Keep this comment at the end of the file
|
|
Local variables:
|
|
mode: sgml
|
|
sgml-default-dtd-file:"~/sgml/html40.ced"
|
|
sgml-omittag:t
|
|
sgml-shorttag:t
|
|
End:
|
|
-->
|