NOTE-xml-schema-req-19990215 14.6 KB

Raw Blame History Permalink

<!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> &copy; 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 (&quot;binary data&quot;) 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 &amp; 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:
-->