<!--
The XML Catalogs Specification from OASIS.
Original documentat at http://www.oasis-open.org/committees/download.php/2600/cs-entity-xml-catalogs-1.0.xml
-->
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
<!ENTITY name "cs-entity-xml-catalogs">
<!ENTITY version "1.0">
<!ENTITY standard "Committee Specification">
<!ENTITY namespaceURI "urn:oasis:names:tc:entity:xmlns:xml:catalog">
<!ENTITY namespaceURItr9401 "urn:oasis:names:tc:entity:xmlns:tr9401:catalog">
<!ENTITY uri "URI">
<!ENTITY uriref "URI reference">
<!ENTITY % local.article.attrib "
xmlns:e CDATA #IMPLIED
">
<!ENTITY % local.synop.class "|e:element-syntax">
<!ELEMENT e:element-syntax
(e:in-category*, e:attribute*, (e:empty|e:text|e:element|e:model|e:sequence|e:choice))
>
<!ATTLIST e:element-syntax
xmlns:e CDATA #FIXED "http://www.w3.org/1999/XSL/Spec/ElementSyntax"
name NMTOKEN #REQUIRED
>
<!ELEMENT e:in-category EMPTY>
<!ATTLIST
e:in-category name NMTOKEN #REQUIRED
xmlns:e CDATA #FIXED "http://www.w3.org/1999/XSL/Spec/ElementSyntax"
>
<!ELEMENT e:attribute (e:attribute-value-template|(e:constant|e:data-type)+)>
<!ATTLIST e:attribute
name NMTOKEN #REQUIRED
required (yes) #IMPLIED
xmlns:e CDATA #FIXED "http://www.w3.org/1999/XSL/Spec/ElementSyntax"
>
<!ELEMENT e:attribute-value-template (e:constant|e:data-type)+>
<!ATTLIST e:attribute-value-template
xmlns:e CDATA #FIXED "http://www.w3.org/1999/XSL/Spec/ElementSyntax"
>
<!ELEMENT e:constant EMPTY>
<!ATTLIST
e:constant value CDATA #REQUIRED
xmlns:e CDATA #FIXED "http://www.w3.org/1999/XSL/Spec/ElementSyntax"
>
<!ELEMENT e:data-type EMPTY>
<!ATTLIST e:data-type
name NMTOKEN #REQUIRED
xmlns:e CDATA #FIXED "http://www.w3.org/1999/XSL/Spec/ElementSyntax"
>
<!ELEMENT e:empty EMPTY>
<!ATTLIST e:empty
xmlns:e CDATA #FIXED "http://www.w3.org/1999/XSL/Spec/ElementSyntax"
>
<!ELEMENT e:text EMPTY>
<!ATTLIST e:text
xmlns:e CDATA #FIXED "http://www.w3.org/1999/XSL/Spec/ElementSyntax"
>
<!ELEMENT e:element EMPTY>
<!ATTLIST e:element
name NMTOKEN #REQUIRED
repeat (zero-or-one|zero-or-more|one-or-more) #IMPLIED
xmlns:e CDATA #FIXED "http://www.w3.org/1999/XSL/Spec/ElementSyntax"
>
<!ELEMENT e:model EMPTY>
<!ATTLIST e:model
name NMTOKEN #REQUIRED
repeat (zero-or-one|zero-or-more|one-or-more) #IMPLIED
xmlns:e CDATA #FIXED "http://www.w3.org/1999/XSL/Spec/ElementSyntax"
>
<!ELEMENT e:sequence (e:element|e:model|e:choice)+>
<!ATTLIST e:sequence
repeat (zero-or-one|zero-or-more|one-or-more) #IMPLIED
xmlns:e CDATA #FIXED "http://www.w3.org/1999/XSL/Spec/ElementSyntax"
>
<!ELEMENT e:choice (e:element|e:model|e:sequence)+>
<!ATTLIST e:choice
repeat (zero-or-one|zero-or-more|one-or-more) #IMPLIED
xmlns:e CDATA #FIXED "http://www.w3.org/1999/XSL/Spec/ElementSyntax"
>
<!ELEMENT e:element-syntax-summary EMPTY>
<!ATTLIST e:element-syntax-summary
xmlns:e CDATA #FIXED "http://www.w3.org/1999/XSL/Spec/ElementSyntax"
>
<!ENTITY mdash "--">
<!ENTITY hellip "...">
]>
<article xmlns:e="http://www.w3.org/1999/XSL/Spec/ElementSyntax"
status="&standard;">
<articleinfo>
<releaseinfo role="cvs">
$Id: xml-catalogs-spec.xml,v 1.1 2006/04/15 18:27:17 stevecheng Exp $
</releaseinfo>
<productname>&name;</productname>
<productnumber>&version;</productnumber>
<releaseinfo role="product"><ulink url="&name;-&version;.xml">XML</ulink></releaseinfo>
<releaseinfo role="product"><ulink url="&name;-&version;.html">HTML</ulink></releaseinfo>
<releaseinfo role="product"><ulink url="&name;-&version;.pdf">PDF</ulink></releaseinfo>
<releaseinfo role="location">http://www.oasis-open.org/committees/entity/specs</releaseinfo>
<title>XML Catalogs</title>
<authorgroup>
<editor>
<firstname>Norman</firstname><surname>Walsh</surname>
<affiliation>
<shortaffil>Sun</shortaffil>
<orgname>Sun Microsystems, Inc.</orgname>
<address><email>Norman.Walsh@Sun.COM</email></address>
</affiliation>
</editor>
</authorgroup>
<pubdate>03 Jun 2003</pubdate>
<copyright><year>2000</year><year>2001</year><year>2002</year><year>2003</year>
<holder>OASIS Open, Inc. All Rights Reserved.</holder></copyright>
<abstract><title>Abstract</title>
<para>The requirement that all external identifiers in XML documents
must provide a system identifier has unquestionably been of tremendous
short-term benefit to the XML community. It has allowed a whole
generation of tools to be developed without the added complexity of
explicit entity management.</para>
<para>However, the interoperability of XML documents has been impeded
in several ways by the lack of entity management facilities:
<orderedlist>
<listitem><para>External identifiers may require resources that are
not always available. For example, a system identifier that points to
a resource on another machine may be inaccessible if a network
connection is not available.</para></listitem>
<listitem><para>External identifiers may require protocols that are
not accessible to all of the vendors' tools on a single computer system.
An external identifier that is addressed with the
<systemitem>ftp:</systemitem> protocol, for
example, is not accessible to a tool that does not support that protocol.
</para></listitem>
<listitem><para>It is often convenient to access resources using system
identifiers that point to local resources. Exchanging documents that refer
to local resources with
other systems is problematic at best and impossible at worst.
</para></listitem>
</orderedlist>
</para>
<para>The problems involved with sharing documents, or packages of
documents, across multiple systems are large and complex.
While there are many important issues involved and a complete
solution is beyond the current scope, the OASIS membership agrees upon
the enclosed set of conventions to address a useful subset of the
complete problem. To address these issues, this &standard; defines an
entity catalog that maps both external identifiers and arbitrary
&uriref;s to &uriref;s.</para>
</abstract>
<legalnotice role="status"><title>Status</title>
<!--
<para>This is a working draft constructed by the editor. It is not
an official committee work product and may not reflect the consensus
opinion of the committee.</para>
-->
<para>This Committee Specification was approved for publication by the
OASIS Entity Resolution Technical Committee. It represents the
consensus of the committee.
</para>
<para>Please send comments on this specification to the
<email>entity-resolution-comment@lists.oasis-open.org</email> list.
To subscribe, send an email message to
<email>entity-resolution-comment-request@lists.oasis-open.org</email> with the word
<quote><literal>subscribe</literal></quote> as the body of the
message.
</para>
<!--
<para>The errata page for this specification is at
<ulink url="http://www.oasis-open.org/committees/entity-resolution/specs/&name;-&version;-errata.html"/>.
</para>
-->
</legalnotice>
<revhistory>
<revision>
<revnumber>Editorial revisions from 22 Apr 2003 telcon</revnumber>
<date>22 Apr 2003</date>
</revision>
<revision>
<revnumber>Editorial revisions; reverted to Working Draft for review</revnumber>
<date>18 Apr 2003</date>
</revision>
<revision>
<revnumber>Editorial revisions</revnumber>
<date>21 Feb 2003</date>
</revision>
<revision>
<revnumber>Committee Specification</revnumber>
<date>24 Oct 2002</date>
</revision>
<revision>
<revnumber>Working Draft</revnumber>
<date>18 Oct 2002</date>
</revision>
<revision>
<revnumber>Committee Specification</revnumber>
<date>06 Aug 2001</date>
</revision>
</revhistory>
</articleinfo>
<section id="s.intro">
<title>Introduction</title>
<para>In order to make optimal use of the information about an XML
external resource, there needs to be some interoperable way to map the
information in an XML external identifier into a &uriref; for the desired
resource.
</para>
<para>This &standard; defines an entity catalog
that handles two simple cases:</para>
<orderedlist>
<listitem><para>Mapping an external entity's public
identifier and/or system identifier to a &uriref;.
</para></listitem>
<listitem><para>Mapping the &uriref; of a resource (a namespace name,
stylesheet, image, etc.) to another &uriref;.</para>
</listitem></orderedlist>
<para>Though it does not handle all issues
that a combination of a complete entity manager and storage manager
addresses, it simplifies both the use of multiple products in a great majority
of cases and the task of processing documents on different systems.
</para>
<para>This entity catalog is designed to be compatible with
<xref linkend="tr9401"/> catalogs as mandated by the
Technical Committee <xref linkend="req"/>.</para>
</section>
<section id="s.terminology"><title>Terminology</title>
<para>The key words <glossterm>must</glossterm>, <glossterm>must
not</glossterm>, <glossterm>required</glossterm>,
<glossterm>shall</glossterm>, <glossterm>shall not</glossterm>,
<glossterm>should</glossterm>, <glossterm>should not</glossterm>,
<glossterm>recommended</glossterm>, <glossterm>may</glossterm>, and
<glossterm>optional</glossterm> in this &standard; are to be
interpreted as described in <xref linkend="rfc2119"/>. Note that for
reasons of style, these words are not capitalized in this
document.</para>
<para>The terms <glossterm>&uri;</glossterm> and
<glossterm>&uriref;</glossterm> are to be interpreted as described
in <xref linkend="rfc2396"/>.</para>
<para>The term <glossterm>external identifier</glossterm> is to be interpreted
as defined in
<ulink url="http://www.w3.org/TR/REC-xml#NT-ExternalID">Production 75</ulink>
of <xref linkend="xml-rec"/>. External identifiers have two parts, an optional
public identifier and a system identifier.
The terms
<glossterm>public identifier</glossterm> and <glossterm>system identifier</glossterm>
in this &standard; always refer to the respective part of an
external identifier.
</para>
<note><para>All <glossterm>system identifiers</glossterm> are &uriref;s, but not
all &uriref;s are system identifiers. A system identifer is always logically
part of an <glossterm>external identifier</glossterm>,
even when the <glossterm>public identifer</glossterm> is not provided.</para>
</note>
<para>The logical <glossterm>input</glossterm> to a catalog processor is
an external identifier (some combination of public and system
identifiers) or a &uriref;. The logical <glossterm>output</glossterm> of
the catalog processor is a &uriref;. (This &standard; does not attempt
to define an API for catalog processors so the logical interfaces and
the practical interfaces may differ.)
</para>
<para>A <glossterm>catalog</glossterm> is a logical structure that
contains <quote>mapping</quote> information. A catalog may be
physically contained in one or more <glossterm>catalog entry
files</glossterm>. A <glossterm>catalog entry file</glossterm> is a
document that contains a set of catalog entries.</para>
</section>
<section id="s.entity.catalog">
<title>An Entity Catalog</title>
<para>This &standard; defines an application-independent entity
catalog that maps external identifiers and &uriref;s to (other)
&uriref;s. It also defines a format for catalog entry files in terms
of <xref linkend="xml-rec"/> and <xref linkend="xml-names"/>.
</para>
<para>The principal task of a catalog processor is to find entries in
the catalog that <emphasis>match</emphasis> the input provided and
return the associated &uriref; as the output. The first such match is
always used, and there is no requirement for the catalog processor to
search for additional matches.</para>
<para>This catalog is used by an application's entity manager. This
&standard; does not dictate when an entity manager should access this
catalog; for example, an application may attempt other mapping
algorithms before or after accessing this catalog.
</para>
<para>The catalog is effectively an ordered list of (one or more)
catalog entry files. It is up to the application to determine the
ordered list of catalog entry files to be used as the logical
catalog. (This &standard; uses the term <quote>catalog entry
file</quote> to refer to one component of a logical catalog even
though a catalog entry file can be any kind of storage object or
entity including—but not limited to—a table in a database,
some object identified by a &uriref;, or some dynamically generated
set of catalog entries.)</para>
<para>Each entry in the catalog associates a &uriref; with information
about an external reference that appears in an XML document. For
example, the following are possible catalog entries that associate a
&uriref; with a public identifier:</para>
<programlisting><![CDATA[<public publicId="ISO 8879:1986//ENTITIES Added Latin 1//EN"
uri="iso-lat1.gml"/>
<public publicId="-//USA/AAP//DTD BK-1//EN"
uri="aapbook.dtd"/>
<public publicId="-//Example, Inc.//DTD Report//EN"
uri="http://www.example.com/dtds/report.dtd"/>]]></programlisting>
<para>This &standard; defines the following catalog entry types:
<link linkend="s.catalog"><sgmltag>catalog</sgmltag></link>,
<link linkend="s.delegatepublic"><sgmltag>delegatePublic</sgmltag></link>,
<link linkend="s.delegatesystem"><sgmltag>delegateSystem</sgmltag></link>,
<link linkend="s.delegateuri"><sgmltag>delegateURI</sgmltag></link>,
<link linkend="s.group"><sgmltag>group</sgmltag></link>,
<link linkend="s.nextcatalog"><sgmltag>nextCatalog</sgmltag></link>
<link linkend="s.public"><sgmltag>public</sgmltag></link>,
<link linkend="s.rewritesystem"><sgmltag>rewriteSystem</sgmltag></link>,
<link linkend="s.rewriteuri"><sgmltag>rewriteURI</sgmltag></link>,
<link linkend="s.system"><sgmltag>system</sgmltag></link>, and
<link linkend="s.uri"><sgmltag>uri</sgmltag></link>. In order to be conformant
with this &standard;, an application must implement all of these entry types with
the semantics described herein.
</para>
<para>The
<ulink url="http://www.w3.org/TR/REC-xml-names/#dt-NSName">namespace
name</ulink> defined by this &standard; is
<quote><literal>&namespaceURI;</literal></quote>.</para>
<para>This &standard; reserves all elements and attributes from its
namespace for current and future use. In addition, unqualified
attributes on elements in its namespace, other than the attributes
explicitly described in this &standard;, are reserved for future
use.</para>
<para>To provide for possible future extension and other
applications of this catalog, its format allows for <quote>other
information</quote> indicated by elements and attributes from
namespaces other than the one defined by this &standard;.</para>
</section>
<section id="s.using.catalogs"><title>Using Catalogs</title>
<para>A catalog can be used in two different, independent ways:
(1) it can be used to locate the replacement text for an external entity,
or (2) it can be used to locate an alternate &uriref; for a resource.
Although these functions are similar in nature, they are distinct and
exercise two different sets of entries in the catalog.</para>
<para>In either case, the following entries in the catalog are interpreted as
follows:</para>
<orderedlist>
<listitem><para>The <sgmltag>catalog</sgmltag> entry is the root of a
catalog entry file. All other entries occur within this
<sgmltag>catalog</sgmltag> element.</para>
</listitem>
<listitem><para>The <sgmltag>group</sgmltag> entry is simply a wrapper
on which <sgmltag class="attribute">prefer</sgmltag>
(<xref linkend="attrib.prefer"/>)
and <sgmltag class="attribute">xml:base</sgmltag>
(<xref linkend="attrib.common"/>)
can occur. It has
no other effect on the entries that it contains. When examining entries
in the catalog sequentially, the presence of a <sgmltag>group</sgmltag>
entry does not effect the order in which they are examined.</para>
</listitem>
<listitem><para>The <sgmltag>nextCatalog</sgmltag> entry indicates that an
entity manager must use the associated &uriref; to locate an additional
catalog entry file to be processed after the current catalog entry
file.</para>
</listitem>
</orderedlist>
<para>The <sgmltag>nextCatalog</sgmltag> entry can be used to insert a
new catalog entry file into the current list of catalog entry
files. The <sgmltag class="attribute">catalog</sgmltag> attribute on a
<sgmltag>nextCatalog</sgmltag> entry is used to locate another catalog
entry file that is inserted into the catalog entry file list after the current
catalog entry file. Multiple <sgmltag>nextCatalog</sgmltag> entries
are allowed, and the referenced catalog entry files are inserted into
the existing working catalog entry file list in the order in which they occur in the
current catalog entry file (document order).</para>
<para>Catalog entry files identified by <sgmltag>nextCatalog</sgmltag>
entries will only be examined after all other entries in the current
catalog entry file have been considered and none of them provide a
match for the current input.</para>
<section id="s.ext.ent"><title>External Identifier Entries</title>
<para><glossterm>External Identifiers</glossterm>, as defined in
[<ulink url="http://www.w3.org/TR/REC-xml#NT-ExternalID">Production 75</ulink>]
of <xref linkend="xml-rec"/>, identify the external subset, entities, and
notations of an XML document. They are <emphasis>not</emphasis> used
to identify other resources such as namespace names and stylesheets;
<link linkend="s.uri.ent">URI entries</link> are used for that purpose.</para>
<para>For the purposes of resolving external identifiers, a catalog-based
resolver considers the following entries:</para>
<itemizedlist>
<listitem><para>The <sgmltag>public</sgmltag> entry indicates that an
entity manager must use the associated &uriref; to locate the replacement
text for an entity with the specified
<glossterm>public identifier</glossterm>.
</para>
</listitem>
<listitem><para>The <sgmltag>system</sgmltag> entry indicates that an
entity manager must use the associated &uriref; to locate the replacement
text for an entity with the specified
<glossterm>system identifier</glossterm>.</para>
</listitem>
<listitem><para>The <sgmltag>rewriteSystem</sgmltag> entry indicates
that an entity manager must rewrite the specified <glossterm>system
identifier</glossterm> by replacing the matching prefix with the
associated rewrite prefix. The resulting string must be used to locate
the replacement text.
</para>
</listitem>
<listitem><para>The <sgmltag>delegatePublic</sgmltag> entry indicates that
external identifiers with a public identifier that starts with the
specified string must be resolved by considering the catalog specified by
the associated &uriref;.</para>
</listitem>
<listitem><para>The <sgmltag>delegateSystem</sgmltag> entry indicates that
external identifiers with a system identifier that starts with the
specified string must be resolved by considering the catalog specified by
the associated &uriref;.</para>
</listitem>
</itemizedlist>
<para>Although system identifiers are assumed to
be <quote><ulink url="http://www.w3.org/TR/REC-xml#dt-sysid">URI
reference[s]…meant to be dereferenced to obtain input for the
XML processor to construct the entity's replacement
text</ulink></quote>, in some circumstances (such as when the document
was generated on another system, when the document was generated in
another location on the same system, or when some files referenced by
system identifiers have moved since the document was generated), the
specified system identifiers are not always the best identifiers for the
replacement text. For this or other reasons, it may be desirable to
prefer the public identifier over the system identifier in determining
the entity's replacement text.
Therefore, this &standard; defines two modes for searching the catalog:
<quote>prefer system identifier</quote> mode and
<quote>prefer public identifier</quote> mode.
</para>
<orderedlist>
<listitem>
<para>If system identifiers are preferred, a system identifier was
provided, and there is no matching <sgmltag>system</sgmltag> or
<sgmltag>rewriteSystem</sgmltag> type
entry, then the system identifier given in the external identifier is
used as the &uriref; to locate the entity's replacement text
regardless of any public identifier given in the external identifier.
</para>
<para>This &standard; does not specify
what happens if a preferred system identifier does not identify an
accessible storage object; an application may look up the public
identifier and/or entity name to find another &uriref;, or it may simply
report an error. An application should at least have the option of
issuing a warning if the system identifier fails in this mode.</para>
</listitem>
<listitem>
<para>If public identifiers are preferred, a public identifier was
specified, and there is no matching <sgmltag>system</sgmltag> or
<sgmltag>rewriteSystem</sgmltag> type
entry, the system identifier given in the external identifier is used
as the &uriref; to locate the entity's replacement text only if no
mapping can be found in the catalog for the public identifier.
</para>
</listitem>
</orderedlist>
<section id="attrib.prefer">
<title>The <sgmltag class="attribute">prefer</sgmltag> attribute</title>
<para>The <sgmltag class="attribute">prefer</sgmltag> attribute can be
used on <sgmltag>catalog</sgmltag> and <sgmltag>group</sgmltag> entry
types to indicate, for the enclosed set of catalog entries, if system
or public entry matches are preferred.</para>
<para>Each occurrence of a
<sgmltag class="attribute">prefer</sgmltag> attribute specifies the
search strategy mode for entries contained within the
<sgmltag>catalog</sgmltag> or <sgmltag>group</sgmltag> element on
which it occurs. A <sgmltag>public</sgmltag> or
<sgmltag>delegatePublic</sgmltag> entry encountered when
<sgmltag class="attribute">prefer</sgmltag> is
<quote><sgmltag class="attvalue">public</sgmltag></quote>
will be considered for possible matching
<anchor id="nosysid"/>whether or not the external
identifier has an explicit system identifier. A
<sgmltag>public</sgmltag> or <sgmltag>delegatePublic</sgmltag>
entry encountered when <sgmltag class="attribute">prefer</sgmltag> is
<quote><sgmltag class="attvalue">system</sgmltag></quote>
will be ignored during lookups for which the external
identifier has an explicit system identifier. No other entry types are
affected by the <sgmltag class="attribute">prefer</sgmltag> attribute.
The initial search strategy in force at the beginning of each catalog
entry file depends on the preference as determined by the application.</para>
<para>An application must provide some way (e.g., a runtime argument,
environment variable, preference switch) that allows the user to
specify which of these modes to use in the absence of any occurrence
of the <sgmltag class="attribute">prefer</sgmltag> attribute on the
<sgmltag>catalog</sgmltag> entry.
</para>
<para>When doing a catalog lookup, an entity manager generally uses
whatever is available from among the entity declaration's system
identifier and public identifier to find catalog entries
that match the given information. A match in one catalog entry file
will take precedence over any match in a later catalog entry file
(and, in fact, the entity manager need not process subsequent catalog
entry files once a match has occurred).</para>
</section>
</section>
<section id="s.uri.ent"><title>URI Entries</title>
<para>URI references that are <emphasis>not</emphasis> part of an
<link linkend="s.ext.ent">external identifier</link>,
such as namespace names, stylesheets, included
files, graphics, and hypertext references, simply identify other
resources. They are resolved using URI entries as described below. The
input to a resolver that locates resources is simply the original
&uriref;.</para>
<para>For the purposes of resolving &uriref;s, a catalog-based
resolver considers the following entries:</para>
<itemizedlist>
<listitem><para>The <sgmltag>uri</sgmltag> entry indicates that an
entity manager must use the associated &uriref; to locate the resource.
</para>
</listitem>
<listitem><para>The <sgmltag>rewriteURI</sgmltag> entry indicates
that an entity manager must rewrite the specified &uriref;
by replacing the matching prefix with the
associated rewrite prefix. The resulting string must be used to locate
the resource.
</para>
</listitem>
<listitem><para>The <sgmltag>delegateURI</sgmltag> entry indicates that
a &uriref; that starts with the
specified string must be resolved by considering the catalog specified by
the associated &uriref;.</para>
</listitem>
</itemizedlist>
<para>As when resolving &uriref;s, a match in one catalog
entry file will take precedence over any match in a later catalog
entry file (and, in fact, the entity manager need not process
subsequent catalog entry files once a match has occurred).</para>
</section>
<section id="s.rewrite"><title>Rewrite Entries</title>
<para>Rewrite entries are provided as a convenience for performing
redirection of a whole set of entities with a single catalog entry.
Typical uses are website mirroring and dealing with fragment identifiers.
</para>
<para>If the entire website at <literal>http://example.com/</literal>
has been mirrored onto your local system in
<literal>file:///share/mirrors/example/</literal>, it is likely that
you want any system identifier reference to the website to be
redirected to your local system.</para>
<para>One way of doing this would be to create a
<sgmltag>system</sgmltag> entry for every relevant identifier.
If there are many entities on the website, this may be
tedious. Instead, a single rewrite entry can be used:
</para>
<programlisting><![CDATA[<rewriteSystem systemIdStartString="http://www.example.com/"
rewritePrefix="file:///share/mirrors/example/"/>]]></programlisting>
<para>Similarly, if you have a large number of references to a single
document using many different fragment identifiers, it may be tedious to
construct <sgmltag>uri</sgmltag> entries for every URI reference if the
base document moves. Again, a single rewrite can be used instead:</para>
<programlisting><![CDATA[<rewriteURI uriStartString="http://www.example.com/old-location/"
rewritePrefix="http://www.example.com/new-location/"/>]]></programlisting>
</section>
<section id="s.example"><title>An XML Catalog Example</title>
<para>The catalog files in <xref linkend="ex.docbook.cat"/> and
<xref linkend="ex.stylesheet.cat"/> are complete examples of XML Catalog
files.
</para>
<example id="ex.docbook.cat">
<title>A DocBook XML Catalog File: <filename>docbook.xml</filename>.</title>
<programlisting><!DOCTYPE catalog
PUBLIC "-//OASIS//DTD XML Catalogs V1.0//EN"
"http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd">
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"
prefer="public">
<group xml:base="http://www.oasis-open.org/docbook/xml/4.1.2/">
<public publicId="-//OASIS//DTD DocBook XML V4.1.2//EN"
uri="docbookx.dtd"/>
<public publicId="-//OASIS//ENTITIES DocBook XML Notations V4.1.2//EN"
uri="dbnotnx.mod"/>
<public publicId="-//OASIS//ENTITIES DocBook XML Character Entities V4.1.2//EN"
uri="dbcentx.mod"/>
<public publicId="-//OASIS//ELEMENTS DocBook XML Information Pool V4.1.2//EN"
uri="dbpoolx.mod"/>
<public publicId="-//OASIS//ELEMENTS DocBook XML Document Hierarchy V4.1.2//EN"
uri="dbhierx.mod"/>
<public publicId="-//OASIS//ENTITIES DocBook XML Additional General Entities V4.1.2//EN"
uri="dbgenent.mod"/>
<public publicId="-//OASIS//DTD DocBook XML CALS Table Model V4.1.2//EN"
uri="calstblx.dtd"/>
</group>
<public publicId="-//OASIS//DTD DocBook MathML Module V1.0//EN"
uri="http://www.oasis-open.org/docbook/xml/mathml/1.0/dbmathml.dtd"/>
<nextCatalog catalog="stylesheets.xml"/>
</catalog></programlisting>
</example>
<example id="ex.stylesheet.cat">
<title>A Stylesheet XML Catalog File: <filename>stylesheet.xml</filename>.</title>
<programlisting><!DOCTYPE catalog
PUBLIC "-//OASIS//DTD XML Catalogs V1.0//EN"
"http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd">
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"
prefer="public">
<!-- Circumvent relative URI in spec.xsl that doesn't work online -->
<uri name="http://www.oasis-open.org/committes/tr.xsl"
uri="http://www.oasis-open.org/committes/entity/stylesheets/base/tr.xsl"/>
</catalog></programlisting>
</example>
<para>Together, these two catalog files provide sufficient resolution
information to parse and format the XML source for this &standard;.
</para>
</section>
</section>
<section id="s.catfiles"><title>Catalog Entry Files</title>
<para>Applications conforming to this &standard; must provide some
(implementation dependent) mechanism that allows the user to establish
the initial list of catalog entry files. This may be a preferences
dialog, an environment variable, an application properties file, or
any other appropriate mechanism.</para>
<para>All conforming processors must accept and process catalog entry files
written in the format described by this specification. They may also accept
and process other formats, but they are not required to do so. If an application
encounters a catalog entry file in a format that it does not understand, it
must treat it as a <link linkend="s.res.fail">resource failure</link>.</para>
<section id="oasis-er-tc-abc">
<title>Document Control of Catalog Entry Files</title>
<para>If a document contains external identifiers or &uriref;s, it may
be useful for the document to identify a catalog that is
likely to aid in the resolution of those references.</para>
<para>For example, XML documents stored on the
<filename>www.example.com</filename> server may wish to indicate
that
<filename>http://www.example.com/catalog</filename> is a useful public
catalog to use when parsing them.</para>
<para>This &standard; defines the processing instruction
<quote><sgmltag class="xmlpi">oasis-xml-catalog</sgmltag></quote> for
this purpose. The
<sgmltag class="xmlpi">oasis-xml-catalog</sgmltag> processing
instruction has a single pseudo-attribute,
<sgmltag class="attribute">catalog</sgmltag>, that identifies a single
catalog entry file.</para>
<para>If a document contains one or more
<sgmltag class="xmlpi">oasis-xml-catalog</sgmltag>
processing instruction(s), the catalog entry file(s) identified must be used
during resolution of external identifiers and &uriref;s within that
document.</para>
<para>Catalog entry files referenced by the processing instruction are added to
the end of any system- or user-defined catalog entry file list.</para>
<para>For example, in</para>
<programlisting><?xml version="1.0"?>
<?oasis-xml-catalog catalog="http://example.com/catalog.xml"?>
<!DOCTYPE doc PUBLIC "-//Example//DTD Document V1.0//EN"
"http://www.example.com/schema/doc.dtd">
...
</programlisting>
<para>The URI
<quote><filename>http://example.com/catalog.xml</filename></quote> is
added to the end of the of the list of catalog entry files used for
resolution within this document.</para>
<para>The following constraints apply:</para>
<itemizedlist>
<listitem><para>The <sgmltag class="xmlpi">oasis-xml-catalog</sgmltag>
processing instruction must appear in the prologue after the XML
declaration and before the start of the document
type declaration.</para>
<para>It is an error for the processing instruction to occur in the internal
subset or after the document type declaration. Processors should recover
from the error by ignoring any processing instructions that occur after
the start of the document type declaration.</para>
<para>Likewise, it is an error for the processing instruction to occur
after other processing instructions that contain &uriref;s, such as
stylesheet processing instructions (<xref linkend="xmlstyle"/>).
Applications should recover by ignoring
catalog entry files mentioned in such
<sgmltag class="xmlpi">oasis-xml-catalog</sgmltag> processing instructions.
</para>
</listitem>
<listitem><para>If more than one catalog processing instruction is present,
each catalog entry file
specified is added to the end of the catalog entry file list.
</para></listitem>
<listitem><para>If the catalog entry file
is specified with a relative URI, it is
relative to the base URI of the document that contains the processing
instruction.
</para></listitem>
<listitem><para>The URI that identifies the catalog entry file is not
subject to catalog resolution.
</para></listitem>
</itemizedlist>
<para>Catalog-aware applications should support
the <sgmltag class="xmlpi">oasis-xml-catalog</sgmltag> processing
instruction. If the processing instruction is supported, they must
provide a facility which allows a user to request that all <sgmltag
class="xmlpi">oasis-xml-catalog</sgmltag> processing instructions be
ignored.
</para>
<para>One common idiom for controlling parser features is the use of a
feature URI. This &standard; defines the following feature URI for this
purpose:</para>
<screen>http://www.oasis-open.org/committees/entity/features/catalog-pi</screen>
<para>If this feature is disabled,
<sgmltag class="xmlpi">oasis-xml-catalog</sgmltag> processing instructions
must be ignored.</para>
</section>
<section id="s.bootstrap"><title><quote>Bootstrapping</quote> Catalog Resolution</title>
<para>XML Catalog files are XML documents and as such may contain
external identifiers and URI references. Conformant processors are not
required to be able to perform resolution of those identifiers through
the XML Catalog.</para>
<para>Implementations are encouraged to provide some sort of
bootstrapping functionality to resolve external identifiers and URIs
that the implementation needs to load catalog entry files.</para>
<para>For example, presented with the following catalog entry file:</para>
<programlisting><!DOCTYPE catalog
PUBLIC "-//OASIS//DTD XML Catalogs V1.0//EN"
"http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd">
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"
prefer="public">
<public publicId="-//OASIS//DTD DocBook XML V4.1.2//EN"
uri="docbookx.dtd"/>
</catalog></programlisting>
<para>an implementation should recognize the standard external
identifier used on the catalog and provide the parser with access to
that DTD in some implementation defined way if it's necessary.</para>
<para>Users can avoid any problems that might arise by limiting the
external identifiers and URIs used to those that do not need
resolution. Note that this <emphasis>only</emphasis> applies to
external identifiers and URIs that must be resolved in order to load the
catalog entry file.</para>
<para>For example, if a local copy of the XML Catalog DTD is available
at <filename>/etc/xml/catalog.dtd</filename>, the problems of
resolution associated with loading this file can be avoided by
pointing directly to that local copy in the catalog entry file:</para>
<programlisting><!DOCTYPE catalog
PUBLIC "-//OASIS//DTD XML Catalogs V1.0//EN"
"/etc/xml/catalog.dtd">
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"
prefer="public">
<public publicId="-//OASIS//DTD DocBook XML V4.1.2//EN"
uri="docbookx.dtd"/>
</catalog></programlisting>
</section>
<section id="s.circularity"><title>Catalog Circularities</title>
<para>The <link linkend="s.semantics">catalog resolution
semantics</link> are not recursive. Once a matching catalog entry has
been found, the value that results from that entry is returned without
further examination of the catalog. In other words, if the catalog
contains the following entries and only these entries:</para>
<programlisting><![CDATA[<uri name="http://example.com/path/resource"
uri="http://example.com/alternate/resource"/>
<uri name="http://example.com/alternate/resource"
uri="http://example.com/final/resource"/>]]></programlisting>
<para>An attempt to resolve
<literal>http://example.com/path/resource</literal> will return
<quote><literal>http://example.com/alternate/resource</literal></quote>.
The fact that the URI returned would be subject to a different
interpretation if <emphasis>it</emphasis> was passed to the resolver
has no effect on the resolver: it stops when a match is found. (This example uses
URI entries, but the semantics hold true for all entry types.)</para>
<para>This avoids an obvious opportunity for circular reference inside
the resolver. However, applications are free to make multiple calls
to the resolver if they wish, in which case it is the responsibility of
the application to handle any circularities that arise.</para>
<para>Even so, catalog circularities may arise, for example, in a
chain of catalogs or delegated catalogs. Implementations should detect
circularity and if a circularity is detected, it must be treated as an
error. Applications may recover from this error by indicating to the
calling application that no match was found.</para>
<para>Given the dynamic nature of resources on the internet, it may
not always be possible for implementations to detect circular
references. Failure to detect circularity of references is not a failure
to conform to this specification.</para>
</section>
</section>
<section id="s.xmlcat">
<title>XML Catalog Entries</title>
<para>Each catalog entry file consists of some number of catalog entries.
Catalog entries can be identified by the namespace name defined by this
&standard;.</para>
<para>Elements and attributes from other namespaces are are allowed,
but they must be ignored for the purposes of resolution defined by
this &standard;. If an element is ignored, all of its descendants must
also be ignored, regardless of their namespace.</para>
<section id="attrib.common"><title>Common Attributes</title>
<para>There are two attributes common to most elements:
<sgmltag class="attribute">id</sgmltag> and
<sgmltag class="attribute">xml:base</sgmltag>. The
<sgmltag class="attribute">id</sgmltag> is provided so that individual
entries can be uniquely identified; it has no impact on the semantics
of the catalog as defined by this &standard;. The
<sgmltag class="attribute">xml:base</sgmltag> attribute changes the
base URI for the entry on which it occurs (and all entries contained
within it, unless further modified by another
<sgmltag class="attribute">xml:base</sgmltag> attribute). The semantics
of <sgmltag class="attribute">xml:base</sgmltag> are normatively defined
in <xref linkend="xmlbase"/>.</para>
<para>All of the attributes defined by this &standard; are in the
per-element-type partition. Use of global attributes, for example,
<literal><cat:group cat:id="groupId"></literal> instead of
<literal><cat:group id="groupId"></literal> is forbidden.</para>
</section>
<section id="pubid-norm"><title>Public Identifier Normalization</title>
<para>In order to accurately and interoperably compare public identifiers,
catalog processors must perform normalization on public identifiers
in <emphasis>both</emphasis> the catalog and the input passed to them.</para>
<para>All strings of white space in public identifiers must be
normalized to single space characters (#x20), and leading and trailing
white space must be removed.</para>
</section>
<section id="sysid-norm"><title>System Identifier and URI Normalization</title>
<para>In order to accurately and interoperably compare system identifiers
and &uriref;s, catalog processors must perform normalization. The
normalization described in this section must be performed on system
identifiers and &uriref;s passed as input to the resolver and on strings
in the catalog that are compared to them.</para>
<para>&uriref;s require encoding and escaping of certain
characters. The disallowed characters include all non-ASCII
characters, plus the excluded characters listed in Section 2.4 of
<xref linkend="rfc2396"/>, except for the number sign (#) and percent
sign (%) characters and the square bracket characters re-allowed in
<xref linkend="rfc2732"/>. These characters are summarized in
<xref linkend="tab.excluded.chars"/>.</para>
<table id="tab.excluded.chars" frame="none">
<?dbfo table-width="4.5in"?>
<title>Excluded US-ASCII Characters</title>
<tgroup cols="6" align="center">
<colspec colwidth="0.75in"/>
<colspec colwidth="0.75in" colsep="1"/>
<colspec colwidth="0.75in"/>
<colspec colwidth="0.75in" colsep="1"/>
<colspec colwidth="0.75in"/>
<colspec colwidth="0.75in"/>
<thead>
<row rowsep="1">
<entry>Hex Value</entry>
<entry>Character</entry>
<entry>Hex Value</entry>
<entry>Character</entry>
<entry>Hex Value</entry>
<entry>Character</entry>
</row>
</thead>
<tbody>
<row>
<entry align="center">00</entry><entry align="center">NUL</entry>
<entry align="center">0F</entry><entry align="center">SI</entry>
<entry align="center">1E</entry><entry align="center">RS</entry>
</row>
<row>
<entry align="center">01</entry><entry align="center">SOH</entry>
<entry align="center">10</entry><entry align="center">DLE</entry>
<entry align="center">1F</entry><entry align="center">US</entry>
</row>
<row>
<entry align="center">02</entry><entry align="center">STX</entry>
<entry align="center">11</entry><entry align="center">DC1</entry>
<entry align="center">20</entry><entry align="center">(space)</entry>
</row>
<row>
<entry align="center">03</entry><entry align="center">ETX</entry>
<entry align="center">12</entry><entry align="center">DC2</entry>
<entry align="center">22</entry><entry align="center">"</entry>
</row>
<row>
<entry align="center">04</entry><entry align="center">EOT</entry>
<entry align="center">13</entry><entry align="center">DC3</entry>
<entry align="center">3C</entry><entry align="center"><</entry>
</row>
<row>
<entry align="center">05</entry><entry align="center">ENQ</entry>
<entry align="center">14</entry><entry align="center">DC4</entry>
<entry align="center">3E</entry><entry align="center">></entry>
</row>
<row>
<entry align="center">06</entry><entry align="center">ACK</entry>
<entry align="center">15</entry><entry align="center">NAK</entry>
<entry align="center">5C</entry><entry align="center">\</entry>
</row>
<row>
<entry align="center">07</entry><entry align="center">BEL</entry>
<entry align="center">16</entry><entry align="center">SYN</entry>
<entry align="center">5E</entry><entry align="center">^</entry>
</row>
<row>
<entry align="center">08</entry><entry align="center">BS</entry>
<entry align="center">17</entry><entry align="center">ETB</entry>
<entry align="center">60</entry><entry align="center">`</entry>
</row>
<row>
<entry align="center">09</entry><entry align="center">HT</entry>
<entry align="center">18</entry><entry align="center">CAN</entry>
<entry align="center">7B</entry><entry align="center">{</entry>
</row>
<row>
<entry align="center">0A</entry><entry align="center">LF</entry>
<entry align="center">19</entry><entry align="center">EM</entry>
<entry align="center">7C</entry><entry align="center">|</entry>
</row>
<row>
<entry align="center">0B</entry><entry align="center">VT</entry>
<entry align="center">1A</entry><entry align="center">SUB</entry>
<entry align="center">7D</entry><entry align="center">}</entry>
</row>
<row>
<entry align="center">0C</entry><entry align="center">FF</entry>
<entry align="center">1B</entry><entry align="center">ESC</entry>
<entry align="center">7F</entry><entry align="center">DEL</entry>
</row>
<row>
<entry align="center">0D</entry><entry align="center">CR</entry>
<entry align="center">1C</entry><entry align="center">FS</entry>
<entry align="center"></entry><entry align="center"></entry>
</row>
<row>
<entry align="center">0E</entry><entry align="center">SO</entry>
<entry align="center">1D</entry><entry align="center">GS</entry>
<entry align="center"></entry><entry align="center"></entry>
</row>
</tbody>
</tgroup>
</table>
<para>Catalog processors must escape disallowed characters as follows:
</para>
<orderedlist>
<listitem>
<para>Each disallowed character is converted to UTF-8
<xref linkend="rfc2279"/> as one or more bytes.
</para>
</listitem>
<listitem>
<para>Any octets corresponding to a disallowed character are escaped
with the URI escaping mechanism (that is, converted to %HH, where
HH is the hexadecimal notation of the octet value). If escaping must be performed,
uppercase hexadecimal characters should be used.
</para>
</listitem>
<listitem>
<para>The original character is replaced by the resulting character sequence.
</para>
</listitem>
</orderedlist>
<para>Note that this normalization process is idempotent: repeated
normalization does not change a normalized &uriref;.</para>
</section>
<section id="urn-unwrap"><title>URN "Unwrapping"</title>
<para>This &standard; requires processors to implement special
treatment of URNs in the <literal>publicid</literal> URN Namespace
(<xref linkend="rfc3151"/>).
</para>
<para>URNs of this form must, in some contexts, be "unwrapped" by the
Catalog processor. This unwrapping translates the URN form of the
public identifier back into the standard ISO 8879 form for the purposes
of subsequent catalog processing.</para>
<para>Unwrapping a <literal>urn:publicid:</literal> URN is accomplished
by transcribing characters in the URN according to the
following table after discarding the leading <literal>urn:publicid:</literal>
string:</para>
<informaltable frame="none">
<?dbfo table-width="4in"?>
<tgroup cols="2" align="center">
<colspec colwidth="1in" colsep="1"/>
<colspec colwidth="1in"/>
<?dbhtml table-summary="URN to Public Identifer transcription table"?>
<thead>
<row rowsep="1">
<entry>URN Characters</entry>
<entry>Public Identifier Characters</entry>
</row>
</thead>
<tbody>
<row>
<entry>+</entry>
<entry>" " (space)</entry>
</row>
<row>
<entry>:</entry>
<entry>//</entry>
</row>
<row>
<entry>;</entry>
<entry>::</entry>
</row>
<row>
<entry>%2B</entry>
<entry>+</entry>
</row>
<row>
<entry>%3A</entry>
<entry>:</entry>
</row>
<row>
<entry>%2F</entry>
<entry>/</entry>
</row>
<row>
<entry>%3B</entry>
<entry>;</entry>
</row>
<row>
<entry>%27</entry>
<entry>'</entry>
</row>
<row>
<entry>%3F</entry>
<entry>?</entry>
</row>
<row>
<entry>%23</entry>
<entry>#</entry>
</row>
<row>
<entry>%25</entry>
<entry>%</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>For example, the following URN in the <literal>publicid</literal>
namespace:</para>
<literallayout
class="monospaced">urn:publicid:-:OASIS:DTD+DocBook+XML+V4.1.2:EN</literallayout>
<para>Represents the public identifier:</para>
<literallayout
class="monospaced">-//OASIS//DTD DocBook XML V4.1.2//EN</literallayout>
<para>URNs in the <literal>publicid</literal> namespace should always
represent normalized public identifiers (<xref linkend="pubid-norm"/>).
In the event that an unwrapped public identifier is not normalized,
the catalog processor must normalize it.</para>
<para>URNs in the <literal>publicid</literal> namespace are intended for use
in documents. Since the resolver is required to unwrap them before searching
the catalog, they should never be used literally in the catalog. (Nothing will
ever match them.)</para>
</section>
<section id="s.elements"><title>Catalog Elements</title>
<para>The root element of a catalog entry file is <sgmltag>catalog</sgmltag>.
There are ten other element types: <sgmltag>group</sgmltag>,
<sgmltag>public</sgmltag>,
<sgmltag>system</sgmltag>,
<sgmltag>rewriteSystem</sgmltag>,
<sgmltag>delegatePublic</sgmltag>,
<sgmltag>delegateSystem</sgmltag>,
<sgmltag>rewriteURI</sgmltag>,
<sgmltag>delegateURI</sgmltag>,
<sgmltag>uri</sgmltag>,
and
<sgmltag>nextCatalog</sgmltag>. Each of these element types is described
in one of the following sections.</para>
<section id="s.catalog"><title>The <sgmltag>catalog</sgmltag> Entry</title>
<para>Each XML Catalog entry file consists of a single
<sgmltag>catalog</sgmltag> element. This element may set the global
<sgmltag class="attribute">prefer</sgmltag> value and global base URI.
It is otherwise just a container for the other elements.</para>
<e:element-syntax name="catalog">
<e:attribute name="id">
<e:data-type name="id"/>
</e:attribute>
<e:attribute name="prefer">
<e:constant value="system"/>
<e:constant value="public"/>
</e:attribute>
<e:attribute name="xml:base">
<e:data-type name="uri-reference"/>
</e:attribute>
<e:choice repeat="one-or-more">
<e:element name="group"/>
<e:element name="public"/>
<e:element name="system"/>
<e:element name="rewriteSystem"/>
<e:element name="delegatePublic"/>
<e:element name="delegateSystem"/>
<e:element name="uri"/>
<e:element name="rewriteURI"/>
<e:element name="delegateURI"/>
<e:element name="nextCatalog"/>
</e:choice>
</e:element-syntax>
</section>
<section id="s.group"><title>The <sgmltag>group</sgmltag> Entry</title>
<para>The <sgmltag>group</sgmltag> element is a convenience wrapper
for specifying a <sgmltag class="attribute">prefer</sgmltag> setting
or base URI for a set of catalog entries. It has no semantics other
than scoping these settings.
</para>
<e:element-syntax name="group">
<e:attribute name="id">
<e:data-type name="id"/>
</e:attribute>
<e:attribute name="prefer">
<e:constant value="system"/>
<e:constant value="public"/>
</e:attribute>
<e:attribute name="xml:base">
<e:data-type name="uri-reference"/>
</e:attribute>
<e:choice repeat="one-or-more">
<e:element name="public"/>
<e:element name="system"/>
<e:element name="rewriteSystem"/>
<e:element name="delegatePublic"/>
<e:element name="delegateSystem"/>
<e:element name="uri"/>
<e:element name="rewriteURI"/>
<e:element name="delegateURI"/>
<e:element name="nextCatalog"/>
</e:choice>
</e:element-syntax>
<note>
<para>The ability to scope the <sgmltag class="attribute">prefer</sgmltag> and
and base URI settings is required in order to reasonably translate existing
<xref linkend="tr9401"/> catalogs into XML Catalogs.</para>
</note>
</section>
<section id="s.public"><title>The <sgmltag>public</sgmltag> Entry</title>
<para>The <sgmltag>public</sgmltag> element associates a &uriref; with
the <glossterm>public identifier</glossterm> portion of an
<glossterm>external identifier</glossterm>.</para>
<e:element-syntax name="public">
<e:attribute name="id">
<e:data-type name="id"/>
</e:attribute>
<e:attribute name="publicId" required="yes">
<e:data-type name="public-identifier"/>
</e:attribute>
<e:attribute name="uri" required="yes">
<e:data-type name="uri-reference"/>
</e:attribute>
<e:attribute name="xml:base">
<e:data-type name="uri-reference"/>
</e:attribute>
<e:empty/>
</e:element-syntax>
<para>A <sgmltag>public</sgmltag> entry matches a public identifier
if the normalized value (<xref linkend="pubid-norm"/>) of the
public identifier is lexically identical
to the normalized value of the
<sgmltag class="attribute">publicId</sgmltag> attribute of the
entry.</para>
<para>If the value of the <sgmltag class="attribute">uri</sgmltag> attribute
is relative, it must be made absolute with respect to the
base &uri; currently in effect. The &uriref; should not include a
fragment identifier.</para>
</section>
<section id="s.system"><title>The <sgmltag>system</sgmltag> Element</title>
<para>The <sgmltag>system</sgmltag> element associates a &uriref; with
the <glossterm>system identifier</glossterm> portion of an
<glossterm>external identifier</glossterm>.</para>
<e:element-syntax name="system">
<e:attribute name="id">
<e:data-type name="id"/>
</e:attribute>
<e:attribute name="systemId" required="yes">
<e:data-type name="string"/>
</e:attribute>
<e:attribute name="uri" required="yes">
<e:data-type name="uri-reference"/>
</e:attribute>
<e:attribute name="xml:base">
<e:data-type name="uri-reference"/>
</e:attribute>
<e:empty/>
</e:element-syntax>
<para>A <sgmltag>system</sgmltag> entry matches a system identifier
if the normalized value (<xref linkend="sysid-norm"/>) of the
system identifier is lexically identical
to the normalized value of the
<sgmltag class="attribute">systemId</sgmltag> attribute of the
entry.</para>
<para>If the value of the <sgmltag class="attribute">uri</sgmltag> attribute
is relative, it must be made absolute with respect to the
base &uri; currently in effect. The &uriref; should not include a
fragment identifier.</para>
</section>
<section id="s.rewritesystem"><title>The <sgmltag>rewriteSystem</sgmltag> Element</title>
<para>The <sgmltag>rewriteSystem</sgmltag> element rewrites the beginning
of a system identifier.</para>
<e:element-syntax name="rewriteSystem">
<e:attribute name="id">
<e:data-type name="id"/>
</e:attribute>
<e:attribute name="systemIdStartString" required="yes">
<e:data-type name="string"/>
</e:attribute>
<e:attribute name="rewritePrefix" required="yes">
<e:data-type name="uri-reference"/>
</e:attribute>
<e:empty/>
</e:element-syntax>
<para>A <sgmltag>rewriteSystem</sgmltag> entry matches a system identifier
if the normalized value (<xref linkend="sysid-norm"/>) of the
system identifier begins precisely with the
normalized value of the
<sgmltag class="attribute">systemIdStartString</sgmltag> attribute of the
entry.</para>
<para>If the value of the
<sgmltag class="attribute">rewritePrefix</sgmltag> attribute is
relative, it must be made absolute with respect to the base &uri;
currently in effect.</para>
<para>Rewriting removes the matching prefix from the supplied system
identifier and replaces it with the value of the
<sgmltag class="attribute">rewritePrefix</sgmltag> attribute, returning
the entire URI with the new prefix.</para>
<para>If more than one <sgmltag>rewriteSystem</sgmltag> entry matches,
the matching entry with the longest normalized
<sgmltag class="attribute">systemIdStartString</sgmltag> value is used.
</para>
<para>Given the following catalog fragment:</para>
<programlisting><![CDATA[<rewriteSystem systemIdStartString="http://www.oasis-open.org/"
rewritePrefix="file:///share/doctypes/oasis/"/>
<rewriteSystem systemIdStartString="http://www.oasis-open.org/docbook/"
rewritePrefix="file:///sourceforge/docbook/docbook/"/>
<rewriteSystem systemIdStartString="http://www.oasis-open.org/committees/"
rewritePrefix="file:///projects/oasis/"/>]]></programlisting>
<para>The first two entries match the system identifier
<quote>http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd</quote>,
but the third does not. The rewritten system identifier in this case
is: <quote>file:///sourceforge/docbook/docbook/xml/4.1.2/docbookx.dtd</quote>.
</para>
</section>
<section id="s.delegatepublic"><title>The <sgmltag>delegatePublic</sgmltag> Element</title>
<para>The <sgmltag>delegatePublic</sgmltag> element associates an alternate
catalog with a partial public identifier.</para>
<e:element-syntax name="delegatePublic">
<e:attribute name="id">
<e:data-type name="id"/>
</e:attribute>
<e:attribute name="publicIdStartString" required="yes">
<e:data-type name="public-identifier-prefix"/>
</e:attribute>
<e:attribute name="catalog" required="yes">
<e:data-type name="uri-reference"/>
</e:attribute>
<e:attribute name="xml:base">
<e:data-type name="uri-reference"/>
</e:attribute>
<e:empty/>
</e:element-syntax>
<para>A <sgmltag>delegatePublic</sgmltag> entry matches a public identifier
if the normalized value (<xref linkend="pubid-norm"/>) of the
public identifier begins precisely with
the normalized value of the
<sgmltag class="attribute">publicIdStartString</sgmltag> attribute of the
entry.</para>
<para>Given the following catalog fragment:</para>
<programlisting><![CDATA[<delegatePublic publicIdStartString="-//OASIS//"
catalog="http://www.oasis-open.org/catalog"/>
<delegatePublic publicIdStartString="-//OASIS//DTD DocBook "
catalog="http://www.oasis-open.org/docbook/catalog"/>
<delegatePublic publicIdStartString="-//OASIS//DTD XML Catalog //"
catalog="http://www.oasis-open.org/committees/entity/catalog"/>]]></programlisting>
<para>The first two entries match the public identifier
<quote>-//OASIS//DTD DocBook V4.1.2//EN</quote>, but the third does not.
</para>
<para>If the value of the <sgmltag class="attribute">catalog</sgmltag>
attribute is relative, it must be made absolute with respect to the
base &uri; currently in
effect.</para>
</section>
<section id="s.delegatesystem"><title>The <sgmltag>delegateSystem</sgmltag> Element</title>
<para>The <sgmltag>delegateSystem</sgmltag> element associates an alternate
catalog with a partial system identifier.</para>
<e:element-syntax name="delegateSystem">
<e:attribute name="id">
<e:data-type name="id"/>
</e:attribute>
<e:attribute name="systemIdStartString" required="yes">
<e:data-type name="string"/>
</e:attribute>
<e:attribute name="catalog" required="yes">
<e:data-type name="uri-reference"/>
</e:attribute>
<e:attribute name="xml:base">
<e:data-type name="uri-reference"/>
</e:attribute>
<e:empty/>
</e:element-syntax>
<para>A <sgmltag>delegateSystem</sgmltag> entry matches a system identifier
if the normalized value (<xref linkend="sysid-norm"/>) of the
system identifier begins precisely with the normalized value of the
<sgmltag class="attribute">systemIdStartString</sgmltag> attribute of the
entry.</para>
<para>Given the following catalog fragment:</para>
<programlisting><![CDATA[<delegateSystem systemIdStartString="http://www.oasis-open.org/"
catalog="http://www.oasis-open.org/catalog"/>
<delegateSystem systemIdStartString="http://www.oasis-open.org/docbook/"
catalog="http://www.oasis-open.org/docbook/catalog"/>
<delegatePublic publicIdStartString="http://www.oasis-open.org/committees/"
catalog="http://www.oasis-open.org/committees/catalog"/>]]></programlisting>
<para>The first two entries match the system identifier
<quote>http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd</quote>,
but the third does not.
</para>
<para>If the value of the <sgmltag class="attribute">catalog</sgmltag>
attribute is relative, it must be made absolute with respect to the
base &uri; currently in
effect.</para>
</section>
<section id="s.uri"><title>The <sgmltag>uri</sgmltag> Element</title>
<para>The <sgmltag>uri</sgmltag> element associates an alternate &uriref; with
a &uriref; that is not part of an <glossterm>external identifier</glossterm>.</para>
<e:element-syntax name="uri">
<e:attribute name="id">
<e:data-type name="id"/>
</e:attribute>
<e:attribute name="name" required="yes">
<e:data-type name="string"/>
</e:attribute>
<e:attribute name="uri" required="yes">
<e:data-type name="uri-reference"/>
</e:attribute>
<e:attribute name="xml:base">
<e:data-type name="uri-reference"/>
</e:attribute>
<e:empty/>
</e:element-syntax>
<para>A <sgmltag>uri</sgmltag> entry matches a &uriref;
if the normalized value (<xref linkend="sysid-norm"/>)
of the &uriref; is lexically identical
to the normalized value of the
<sgmltag class="attribute">name</sgmltag> attribute of the
entry.</para>
<para>Given the following catalog fragment:</para>
<programlisting><![CDATA[<uri name="http://www.oasis-open.org/committees/docbook/#membership"
uri="file:///projects/oasis/docbook/website/#membership"/>
<uri name="http://www.oasis-open.org/committees/docbook/"
uri="file:///projects/oasis/docbook/website/"/>]]></programlisting>
<para>The second entry matches the &uriref;
<quote>http://www.oasis-open.org/committees/docbook/</quote>,
but the first does not.
</para>
<para>If the value of the <sgmltag class="attribute">uri</sgmltag>
attribute is relative, it must be made absolute with respect to the
base &uri; currently in
effect.</para>
</section>
<section id="s.rewriteuri"><title>The <sgmltag>rewriteURI</sgmltag> Element</title>
<para>The <sgmltag>rewriteURI</sgmltag> element rewrites the beginning of
a &uriref; that is not part of an <glossterm>external identifier</glossterm>.</para>
<e:element-syntax name="rewriteURI">
<e:attribute name="id">
<e:data-type name="id"/>
</e:attribute>
<e:attribute name="uriStartString" required="yes">
<e:data-type name="string"/>
</e:attribute>
<e:attribute name="rewritePrefix" required="yes">
<e:data-type name="uri-reference"/>
</e:attribute>
<e:empty/>
</e:element-syntax>
<para>A <sgmltag>rewriteURI</sgmltag> entry matches a &uriref;
if the normalized value (<xref linkend="sysid-norm"/>) of the
&uriref; begins precisely with the normalized value of the
<sgmltag class="attribute">uriStartString</sgmltag> attribute of the
entry.</para>
<para>If the value of the
<sgmltag class="attribute">rewritePrefix</sgmltag> attribute is
relative, it must be made absolute with respect to the base &uri;
currently in effect.</para>
<para>Rewriting removes the matching prefix from the supplied &uriref;
and replaces it with the value of the value of the
<sgmltag class="attribute">rewritePrefix</sgmltag> attribute.</para>
<para>If more than one <sgmltag>rewriteURI</sgmltag> entry matches,
the matching entry with the longest normalized
<sgmltag class="attribute">uriStartString</sgmltag> value is used.</para>
</section>
<section id="s.delegateuri"><title>The <sgmltag>delegateURI</sgmltag> Element</title>
<para>The <sgmltag>delegateURI</sgmltag> element associates an alternate
catalog with a partial &uriref;.</para>
<e:element-syntax name="delegateURI">
<e:attribute name="id">
<e:data-type name="id"/>
</e:attribute>
<e:attribute name="uriStartString" required="yes">
<e:data-type name="string"/>
</e:attribute>
<e:attribute name="catalog" required="yes">
<e:data-type name="uri-reference"/>
</e:attribute>
<e:attribute name="xml:base">
<e:data-type name="uri-reference"/>
</e:attribute>
<e:empty/>
</e:element-syntax>
<para>A <sgmltag>delegateURI</sgmltag> entry matches a &uriref;
if the normalized value (<xref linkend="sysid-norm"/>) of the
&uriref; begins precisely with the normalized value of the
<sgmltag class="attribute">uriStartString</sgmltag> attribute of the
entry.</para>
<para>If the value of the <sgmltag class="attribute">catalog</sgmltag>
attribute is relative, it must be made absolute with respect to the
base &uri; currently in effect.</para>
</section>
<section id="s.nextcatalog"><title>The <sgmltag>nextCatalog</sgmltag> Element</title>
<para>The <sgmltag>nextCatalog</sgmltag> elements indicate additional
catalog entry file(s) to be considered during the process of resolution.
</para>
<e:element-syntax name="nextCatalog">
<e:attribute name="id">
<e:data-type name="id"/>
</e:attribute>
<e:attribute name="catalog" required="yes">
<e:data-type name="uri-reference"/>
</e:attribute>
<e:attribute name="xml:base">
<e:data-type name="uri-reference"/>
</e:attribute>
<e:empty/>
</e:element-syntax>
<para>If the value of the <sgmltag class="attribute">catalog</sgmltag>
attribute is relative, it must be made absolute with respect to the
base &uri; currently in
effect.</para>
<para>Catalogs loaded due to a <sgmltag>nextCatalog</sgmltag>
directive have an initial base URI that is dependent on the location
of the loaded catalog entry file. No <sgmltag
class="attribute">xml:base</sgmltag> information is inherited from the
originating catalog.</para>
</section>
</section>
</section>
<section id="s.semantics"><title>Catalog Resolution Semantics</title>
<para>This section describes how catalog resolution is performed.</para>
<para>Resolution begins with a list of catalog entry files and
<emphasis>either</emphasis> an external identifier
<emphasis>or</emphasis> a &uriref;.
</para>
<section id="s.ext.res"><title>External Identifier Resolution</title>
<para>This section describes how catalog entries are used to resolve
external identifiers.</para>
<section id="s.ext.input"><title>Input to the Resolver</title>
<para>An external identifier will have at least one and perhaps both
of the following:</para>
<orderedlist>
<listitem><para>a public identifier
</para></listitem>
<listitem><para>a system identifier
</para></listitem>
</orderedlist>
<para>Resolvers should respect the system identifiers provided by
authors. If the system part of the external identifier is relative,
resolution should use that relative URI as the system identifier. If
resolution with the relative form fails, it's reasonable for resolvers
to try again using the absolute form.</para>
<para>If the public identifier is a URN in the <literal>publicid</literal>
namespace (<xref linkend="rfc3151"/>),
it is converted into another public identifier by
<quote>unwrapping</quote> the URN (<xref linkend="urn-unwrap"/>).
This may be done, for example, so that a URN can be specified as the
public identifier and a URL as the system identifier, in the absence
of widely deployed URN-resolution facilities.
</para>
<para>If the system identifier is a URN in the <literal>publicid</literal>
namespace, it is converted into a public identifier by
<quote>unwrapping</quote> the URN. In this case, one of the following
must apply:</para>
<orderedlist>
<listitem><para>No public identifier was provided. Resolution continues
as if the public identifier constructed by unwrapping the URN was
supplied as the original public identifier and no system identifier was
provided.</para></listitem>
<listitem><para>The normalized public identifier provided is lexically
identical to the public identifier constructed by unwrapping the URN.
Resolution
continues as if the system identifier had not been supplied.
</para></listitem>
<listitem><para>The normalized public identifier provided is different from
the public identifier constructed by unwrapping the URN. This is an error.
Applications may recover from this error by discarding the system identifier
and proceeding with the original public identifier.
</para></listitem>
</orderedlist>
</section>
<section id="s.ext.resx"><title>Resolution of External Identifiers</title>
<para>Resolution follows
the steps listed below, proceeding to each subsequent step if and only if
no other action is indicated.</para>
<orderedlist>
<listitem>
<para>Resolution begins in the first catalog entry file in the current
catalog entry file list.
</para>
</listitem>
<listitem>
<para>If a system identifier is provided, and at least one
matching <sgmltag>system</sgmltag> entry exists, the (absolutized) value of the
<sgmltag class="attribute">uri</sgmltag> attribute of the first
matching <sgmltag>system</sgmltag> entry is returned.
</para>
</listitem>
<listitem>
<para>If a system identifier is provided, and at least one
matching <sgmltag>rewriteSystem</sgmltag> entry exists, rewriting
is performed.</para>
<para>If more than one <sgmltag>rewriteSystem</sgmltag> entry matches,
the matching entry with the longest normalized
<sgmltag class="attribute">systemIdStartString</sgmltag> value is used.
</para>
<para>Rewriting removes the matching prefix and replaces it with the
rewrite prefix identified by the matching <sgmltag>rewriteSystem</sgmltag>
entry. The rewritten string is returned.</para>
</listitem>
<listitem>
<para>If a system identifier is provided, and one or more
<sgmltag>delegateSystem</sgmltag> entries match, delegation is performed.
</para>
<para>If delegation is to be performed, a new catalog entry file list is generated
from the set of all matching <sgmltag>delegateSystem</sgmltag> entries.
The (absolutized) value of the <sgmltag
class="attribute">catalog</sgmltag> attribute of each matching
<sgmltag>delegateSystem</sgmltag> entry is inserted into the new
catalog entry file list such that the delegate entry with the longest
matching <sgmltag class="attribute">systemIdStartString</sgmltag> is
first on the list, the entry with the second longest match is second,
etc.</para>
<para>These are the only catalog entry files on the list, the current
list is not considered for the purpose of delegation. If delegation
fails to find a match, resolution for this entity does not resume with
the current list. (A subsequent resolution attempt for a different
entity begins with the original list; in other words the catalog entry file list
used for delegation is distinct and unrelated to the
<quote>normal</quote> catalog entry file list.)
</para>
<para>Catalog resolution restarts using exclusively the catalog entry
files in this new list and the given system identifier; any originally
given public identifier is ignored during the remainder of the resolution
of this external identifier: return to step 1.
</para>
</listitem>
<listitem>
<para>If a public identifier is provided, and at least one matching
<sgmltag>public</sgmltag> entry exists, the (absolutized) value of the
<sgmltag class="attribute">uri</sgmltag> attribute of the first
matching <sgmltag>public</sgmltag> entry is returned.
If a system identifier is also provided as part of the input to this
catalog lookup, only <sgmltag>public</sgmltag>
entries that occur where the <sgmltag class="attribute">prefer</sgmltag>
setting is <sgmltag class="attvalue">public</sgmltag>
are considered for matching.
</para>
</listitem>
<listitem>
<para>If a public identifier is provided, and one or more
<sgmltag>delegatePublic</sgmltag> entries match, delegation is performed.
If a system identifier is also provided as part of the input to this
catalog lookup, only <sgmltag>delegatePublic</sgmltag>
entries that occur where the <sgmltag class="attribute">prefer</sgmltag>
setting is <sgmltag class="attvalue">public</sgmltag>
are considered for matching.</para>
<para>If delegation is to be performed, a new catalog entry file list is generated
from the set of all matching <sgmltag>delegatePublic</sgmltag> entries.
The value of the <sgmltag class="attribute">catalog</sgmltag> attribute
of each matching <sgmltag>delegatePublic</sgmltag> entry is inserted
into the new catalog entry file list such that the delegate entry with
the longest matching <sgmltag class="attribute">publicIdStartString</sgmltag>
is first on the list, the entry with the second longest match is
second, etc.</para>
<para>These are the only catalog entry files on the list, the current
list is not considered for the purpose of delegation. If delegation
fails to find a match, resolution for this entity does not resume with
the current list. (A subsequent resolution attempt for a different
entity begins with the original list; in other words the catalog entry file list
used for delegation is distinct and unrelated to the
<quote>normal</quote> catalog entry file list.)
</para>
<para>Catalog resolution restarts using exclusively the catalog entry
files in this new list and the given public identifier; any originally
given system identifier is ignored during the remainder of the resolution
of this external identifier: return to step 1.
</para>
</listitem>
<listitem>
<para>If the current catalog entry file contains one or more
<sgmltag>nextCatalog</sgmltag> entries, the catalog entry files
referenced by each <sgmltag>nextCatalog</sgmltag> entry's
<quote>catalog</quote> attribute are inserted, in the order
that they appear in this catalog entry file, onto the current catalog entry file list,
immediately after the current catalog entry file.
</para>
</listitem>
<listitem>
<para>If there are one or more catalog entry files remaining on the current
catalog entry file list, load the next catalog entry file and continue resolution
efforts: return to step 2.
</para>
</listitem>
<listitem>
<para>Indicate to the calling application that
no match was found.</para>
</listitem>
</orderedlist>
</section>
</section>
<section id="s.uri.res"><title>URI Resolution</title>
<para>This section describes how catalog entries are used to resolve
&uriref;s.</para>
<section id="s.uri.input"><title>Input to the Resolver</title>
<para>&uriref; resolution always begins with a single &uriref;.</para>
<para>Resolvers should respect the &uriref;s provided by authors. If
the URI is relative, resolution should use that relative URI. If
resolution with the relative form fails, it's reasonable for resolvers
to try again using the absolute form.</para>
<para>If the &uriref; is a URN in the <literal>publicid</literal>
namespace (<xref linkend="rfc3151"/>),
it is converted into a public identifier by
<quote>unwrapping</quote> the URN (<xref linkend="urn-unwrap"/>).
Resolution continues by following
the semantics of external identifier resolution (<xref linkend="s.ext.res"/>)
as if the public identifier constructed by unwrapping the URN had
been provided and no system identifier had been provided. Otherwise,
resolution of the &uriref; proceeds according to the steps below.
</para>
</section>
<section id="s.uri.resx"><title>Resolution of &uriref;s</title>
<para>Resolution of a generic &uriref; follows
the steps listed below, proceeding to each subsequent step if and only if
no other action is indicated.</para>
<orderedlist>
<listitem>
<para>Resolution begins in the first catalog entry file in the current catalog
list.
</para>
</listitem>
<listitem>
<para>If at least one
matching <sgmltag>uri</sgmltag> entry exists, the (absolutized) value of the
<sgmltag class="attribute">uri</sgmltag> attribute of the first
matching <sgmltag>uri</sgmltag> entry is returned.
</para>
</listitem>
<listitem>
<para>If at least one matching <sgmltag>rewriteURI</sgmltag> entry
exists, rewriting is performed.</para>
<para>If more than one <sgmltag>rewriteURI</sgmltag> entry matches,
the matching entry with the longest normalized
<sgmltag class="attribute">uriStartString</sgmltag> value is used.
</para>
<para>Rewriting removes the matching prefix and replaces it with the
rewrite prefix identified by the matching
<sgmltag>rewriteURI</sgmltag> entry. The rewritten string is
returned.</para>
</listitem>
<listitem>
<para>If one or more
<sgmltag>delegateURI</sgmltag> entries match, delegation is performed.
</para>
<para>If delegation is to be performed, a new catalog entry file list is generated
from the set of all matching <sgmltag>delegateURI</sgmltag> entries.
The (absolutized) value of the <sgmltag class="attribute">catalog</sgmltag> attribute
of each matching <sgmltag>delegateURI</sgmltag> entry is inserted into
the new catalog entry file list such that the delegate entry with the
longest matching <sgmltag class="attribute">uriStartString</sgmltag>
is first on the list, the entry with the second longest match is
second, etc.</para>
<para>These are the only catalog entry files on the list, the current
list is not considered for the purpose of delegation. If delegation
fails to find a match, resolution for this entity does not resume with
the current list. (A subsequent resolution attempt for a different
entity begins with the original list; in other words the catalog entry file list
used for delegation is distinct and unrelated to the
<quote>normal</quote> catalog entry file list.)
</para>
<para>Catalog resolution restarts using exclusively the catalog entry
files in this new list and the given &uriref;: return to step 1.
</para>
</listitem>
<listitem>
<para>If the current catalog entry file contains one or more
<sgmltag>nextCatalog</sgmltag> entries, the catalog entry files
referenced by each <sgmltag>nextCatalog</sgmltag> entry's
<quote>catalog</quote> attribute are inserted, in the order
that they appear in this catalog entry file, onto the current catalog entry file list,
immediately after the current catalog entry file.
</para>
</listitem>
<listitem>
<para>If there are one or more catalog entry files remaining on the current
catalog entry file list, load the next catalog entry file and continue resolution
efforts: return to step 2.
</para>
</listitem>
<listitem>
<para>Indicate to the calling application that no match was found.
</para>
</listitem>
</orderedlist>
</section>
</section>
</section>
<section id="s.res.fail"><title>Resource Failures</title>
<para>The catalog processor is sometimes required to load a catalog
entry file. This may occur at the beginning of processing, when
dealing with the initial list of catalog entry files, or during subsequent
processing of a <sgmltag>nextCatalog</sgmltag> entry or one of the
delegate entries.
</para>
<para>If the processor attempts to load a resource and fails (because
the resource does not exist or is not reachable, for example), it
must recover by ignoring the catalog entry file that failed and
proceeding.</para>
<para>Similarly, if the resource retrieved is not an understandable
catalog (because it is not in a format that the processor recognizes,
or it purports to be XML but is not well-formed, or for any other
reason), the processor must recover by responding as if the resource
could not be loaded.</para>
<para>In order for a resource to be considered an XML Catalog, the following
conditions must hold:</para>
<orderedlist>
<listitem><para>The resource retrieved must be well-formed <xref
linkend="xml-rec"/> consistent with <xref linkend="xml-names"/>.
</para></listitem>
<listitem><para>The root element must be <sgmltag>catalog</sgmltag>.
</para></listitem>
<listitem><para>The namespace name of the root element must be
<literal>&namespaceURI;</literal>.
</para></listitem>
</orderedlist>
<para>It is not an error for catalog processors to accept other forms
of catalog documents, but their identification and specification is
outside the scope of this &standard;.
</para>
</section>
<appendix id="a.w3cxmlschema" role="non-normative"><title>A W3C XML Schema for the XML Catalog</title>
<para>This <xref linkend="xmlschema"/> grammar defines the syntax for OASIS XML Catalog
&standard; entry files.</para>
<para>This grammar has the following identifier:
<itemizedlist>
<listitem><para>System identifier:
<literal>http://www.oasis-open.org/committees/entity/release/1.0/catalog.xsd</literal>
</para>
</listitem>
</itemizedlist>
</para>
<programlisting><inlinemediaobject>
<imageobject>
<imagedata fileref="catalog.xsd" format="linespecific"/>
</imageobject>
</inlinemediaobject></programlisting>
</appendix>
<appendix id="a.relaxng" role="non-normative"><title>A RELAX NG Grammar for the XML Catalog</title>
<para>This <xref linkend="relaxng"/> grammar defines the syntax for OASIS XML Catalog
&standard; entry files.</para>
<para>This grammar has the following identifier:
<itemizedlist>
<listitem><para>System identifier:
<literal>http://www.oasis-open.org/committees/entity/release/1.0/catalog.rng</literal>
</para>
</listitem>
</itemizedlist>
</para>
<programlisting><inlinemediaobject>
<imageobject>
<imagedata fileref="catalog.rng" format="linespecific"/>
</imageobject>
</inlinemediaobject></programlisting>
</appendix>
<appendix id="a.dtd" role="non-normative"><title>A DTD for the XML Catalog</title>
<para>This <xref linkend="xml-rec"/> DTD grammar
partially<footnote><para>Any catalog file
which is valid according to this DTD is valid according to this
&standard;. However, catalog files which make use of extension
elements or attributes may be valid according to this &standard;
but invalid according to this DTD, due to the limits of DTD validation
with respect to namespaces.</para></footnote> defines the syntax for
OASIS XML Catalog &standard; entry files.</para>
<para>This DTD has the following identifiers:</para>
<itemizedlist>
<listitem><para>Public identifier:
<literal>-//OASIS//DTD XML Catalogs V1.0//EN</literal>
</para>
</listitem>
<listitem><para>System identifier:
<literal>http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd</literal>
</para>
</listitem>
</itemizedlist>
<programlisting><inlinemediaobject>
<imageobject>
<imagedata fileref="catalog.dtd" format="linespecific"/>
</imageobject>
</inlinemediaobject></programlisting>
</appendix>
<appendix id="a.tr9401" role="non-normative">
<title>Support for TR9401 Catalog Semantics</title>
<para>This &standard; defines a subset of the catalog entry types
described in <xref linkend="tr9401"/> that are applicable to XML.
For implementors wishing to provide full TR9401 support, this appendix
defines the elements that should be used for the remaining
TR9401 catalog entry types.</para>
<para>The elements described in this appendix provide full TR9401
semantics in the XML Catalog format. These are implemented as
extension elements in the namespace:
<quote><literal>&namespaceURItr9401;</literal></quote>.</para>
<para>For a complete description of the semantics of these elements
see <xref linkend="tr9401"/>.</para>
<section id="s.doctype"><title>The <sgmltag>doctype</sgmltag> Element</title>
<para>The <sgmltag>doctype</sgmltag> element associates a DTD with
a document element.</para>
<e:element-syntax name="doctype">
<e:attribute name="id">
<e:data-type name="id"/>
</e:attribute>
<e:attribute name="name" required="yes">
<e:data-type name="name"/>
</e:attribute>
<e:attribute name="uri" required="yes">
<e:data-type name="uri-reference"/>
</e:attribute>
<e:attribute name="xml:base">
<e:data-type name="uri-reference"/>
</e:attribute>
<e:empty/>
</e:element-syntax>
</section>
<section id="s.document"><title>The <sgmltag>document</sgmltag> Element</title>
<para>The <sgmltag>document</sgmltag> element identifies a default
document.</para>
<e:element-syntax name="document">
<e:attribute name="id">
<e:data-type name="id"/>
</e:attribute>
<e:attribute name="uri" required="yes">
<e:data-type name="uri-reference"/>
</e:attribute>
<e:attribute name="xml:base">
<e:data-type name="uri-reference"/>
</e:attribute>
<e:empty/>
</e:element-syntax>
</section>
<section id="s.dtddecl"><title>The <sgmltag>dtddecl</sgmltag> Element</title>
<para>The <sgmltag>dtddecl</sgmltag> element associates an SGML declaration
with a public identifier.</para>
<e:element-syntax name="dtddecl">
<e:attribute name="id">
<e:data-type name="id"/>
</e:attribute>
<e:attribute name="publicId" required="yes">
<e:data-type name="public-identifier"/>
</e:attribute>
<e:attribute name="uri" required="yes">
<e:data-type name="uri-reference"/>
</e:attribute>
<e:attribute name="xml:base">
<e:data-type name="uri-reference"/>
</e:attribute>
<e:empty/>
</e:element-syntax>
</section>
<section id="s.entity"><title>The <sgmltag>entity</sgmltag> Element</title>
<para>The <sgmltag>entity</sgmltag> element associates a document with
an entity name.</para>
<e:element-syntax name="entity">
<e:attribute name="id">
<e:data-type name="id"/>
</e:attribute>
<e:attribute name="name" required="yes">
<e:data-type name="name"/>
</e:attribute>
<e:attribute name="uri" required="yes">
<e:data-type name="uri-reference"/>
</e:attribute>
<e:attribute name="xml:base">
<e:data-type name="uri-reference"/>
</e:attribute>
<e:empty/>
</e:element-syntax>
</section>
<section id="s.linktype"><title>The <sgmltag>linktype</sgmltag> Element</title>
<para>The <sgmltag>linktype</sgmltag> element associates an external
subset with a linktype declaration name.</para>
<e:element-syntax name="linktype">
<e:attribute name="id">
<e:data-type name="id"/>
</e:attribute>
<e:attribute name="name" required="yes">
<e:data-type name="name"/>
</e:attribute>
<e:attribute name="uri" required="yes">
<e:data-type name="uri-reference"/>
</e:attribute>
<e:attribute name="xml:base">
<e:data-type name="uri-reference"/>
</e:attribute>
<e:empty/>
</e:element-syntax>
</section>
<section id="s.notation"><title>The <sgmltag>notation</sgmltag> Element</title>
<para>The <sgmltag>notation</sgmltag> element associates a &uriref; with
a notation name.</para>
<e:element-syntax name="notation">
<e:attribute name="id">
<e:data-type name="id"/>
</e:attribute>
<e:attribute name="name" required="yes">
<e:data-type name="name"/>
</e:attribute>
<e:attribute name="uri" required="yes">
<e:data-type name="uri-reference"/>
</e:attribute>
<e:attribute name="xml:base">
<e:data-type name="uri-reference"/>
</e:attribute>
<e:empty/>
</e:element-syntax>
</section>
<section id="s.sgmldecl"><title>The <sgmltag>sgmldecl</sgmltag> Element</title>
<para>The <sgmltag>sgmldecl</sgmltag> element provides the location of
a default SGML declaration.</para>
<e:element-syntax name="sgmldecl">
<e:attribute name="id">
<e:data-type name="id"/>
</e:attribute>
<e:attribute name="uri" required="yes">
<e:data-type name="uri-reference"/>
</e:attribute>
<e:attribute name="xml:base">
<e:data-type name="uri-reference"/>
</e:attribute>
<e:empty/>
</e:element-syntax>
</section>
</appendix>
<appendix id="a.committee" role="non-normative">
<title>OASIS Entity Resolution Committee</title>
<para>The following individuals are members of the committee that developed
this &standard;:</para>
<simplelist type="vert">
<member>Paul Grosso, Arbortext</member>
<member>David Leland, Elsevier Science London</member>
<member>Normand Montour, IBM</member>
<member>Norman Walsh, Sun Microsystems (Editor)</member>
<member>Lauren Wood, Individual Member (Chair)</member>
</simplelist>
<para>The following additional individuals were members of the committee
during the development of previous versions:</para>
<simplelist type="vert">
<member>Tony Coates, Reuters</member>
<member>John Cowan, Reuters Health</member>
</simplelist>
</appendix>
<appendix id="a.notices">
<title>Notices</title>
<para>Copyright © 2000, 2001, 2002 OASIS Open, Inc. All Rights Reserved.
</para>
<para>OASIS takes no position regarding the validity
or scope of any intellectual property or other rights
that might be claimed to pertain to the implementation
or use of the technology described in this document
or the extent to which any license under such rights
might or might not be available; neither does it represent
that it has made any effort to identify any such rights.
Information on OASIS's procedures with respect to rights
in OASIS specifications can be found at the OASIS website.
Copies of claims of rights made available for publication
and any assurances of licenses to be made available,
or the result of an attempt made to obtain a general
license or permission for the use of such proprietary
rights by implementors or users of this specification,
can be obtained from the OASIS Executive Director.</para>
<para>OASIS invites any interested party to bring to
its attention any copyrights, patents or patent applications,
or other proprietary rights which may cover technology
that may be required to implement this specification.
Please address the information to the OASIS Executive
Director.</para>
<para>This document and translations of it may be copied
and furnished to others, and derivative works that comment
on or otherwise explain it or assist in its implementation
may be prepared, copied, published and distributed,
in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph
are included on all such copies and derivative works.
However, this document itself may not be modified in
any way, such as by removing the copyright notice or
references to OASIS, except as needed for the purpose
of developing OASIS specifications, in which case the
procedures for copyrights defined in the OASIS Intellectual
Property Rights document must be followed, or as required
to translate it into languages other than English.</para>
<para>The limited permissions granted above are perpetual
and will not be revoked by OASIS or its successors or
assigns.</para>
<para>This document and the information contained herein
is provided on an <quote>AS IS</quote> basis and OASIS DISCLAIMS
ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.</para>
<para>OASIS has been notified of intellectual property
rights claimed in regard to some or all of the contents
of this specification. For more information consult
the online list of claimed rights.</para>
</appendix>
<appendix id="a.ipr">
<title>Intellectual Property Rights</title>
<para>For information on whether any patents have been disclosed that may be
essential to implementing this specification, and any offers of patent
licensing terms, please refer to the Intellectual Property Rights section
of the Entity Resolution web page
(<ulink url="http://www.oasis-open.org/committees/entity/"/>)
</para>
</appendix>
<bibliography id="bibl"><title>References</title>
<bibliodiv><title>Normative</title>
<bibliomixed id="xml-rec"><abbrev>XML</abbrev>Tim Bray,
Jean Paoli, and
C. M. Sperberg-McQueen, Eve Maler, editors.
<citetitle><ulink url="http://www.w3.org/TR/REC-xml">Extensible Markup
Language (XML) 1.0 Second Edition</ulink></citetitle>.
World Wide Web Consortium, 2000.
</bibliomixed>
<bibliomixed id="xml-names"><abbrev>XML Namespaces</abbrev>Tim Bray,
Dave Hollander,
and Andrew Layman, editors.
<citetitle><ulink url="http://www.w3.org/TR/REC-xml-names/">Namespaces in
XML</ulink></citetitle>.
World Wide Web Consortium, 1999.
</bibliomixed>
<bibliomixed id="rfc2119"><abbrev>RFC 2119</abbrev>IETF
(Internet Engineering Task Force).
<citetitle><ulink url="http://www.ietf.org/rfc/rfc2119.txt">RFC 2119:
Key words for use in RFCs to Indicate Requirement Levels</ulink></citetitle>.
S. Bradner. 1997.</bibliomixed>
<bibliomixed id="rfc3151"><abbrev>RFC 3151</abbrev>IETF
(Internet Engineering Task Force).
<citetitle><ulink url="http://www.ietf.org/rfc/rfc3151.txt">RFC 3151: A URN Namespace for Public Identifiers</ulink></citetitle>.
N. Walsh, J. Cowan, P. Grosso, 2001.</bibliomixed>
<bibliomixed id="xmlbase"><abbrev>XML Base</abbrev>Jonathan Marsh, editor.
<citetitle><ulink url="http://www.w3.org/TR/xmlbase">XML Base</ulink></citetitle>.
World Wide Web Consortium, 2000.
</bibliomixed>
</bibliodiv>
<bibliodiv><title>Non-Normative</title>
<bibliomixed id="xmlschema-2"><abbrev>XML Schema Datatypes</abbrev>Paul V. Biron
and Ashok Malhotra, editors.
<citetitle><ulink url="http://www.w3.org/TR/xmlschema-1/">XML Schema Part 2: Datatypes</ulink></citetitle>.
World Wide Web Consortium, 2000.
</bibliomixed>
<bibliomixed id="relaxng"><abbrev>RELAX NG</abbrev>James Clark and MURATA Makoto, editors.
<citetitle><ulink url="http://www.oasis-open.org/committees/relax-ng/">RELAX NG
Specification</ulink></citetitle>. OASIS. 2001.
</bibliomixed>
<bibliomixed id="xmlstyle"><abbrev>XML Stylesheets</abbrev>James Clark, editor.
<citetitle><ulink url="http://www.w3.org/TR/xml-stylesheet/">Associating
Style Sheets with XML Documents Version 1.0</ulink></citetitle>.
World Wide Web Consortium. 1999.
</bibliomixed>
<bibliomixed id="tr9401"><abbrev>TR 9401</abbrev>Paul Grosso, editor.
<citetitle><ulink url="http://www.oasis-open.org/html/tr9401.html">OASIS
Technical Resolution 9401:1997 (Amendment 2 to TR 9401)</ulink></citetitle>.
OASIS. 1997.
</bibliomixed>
<bibliomixed id="rfc2279"><abbrev>RFC 2279</abbrev>IETF (Internet Engineering Task Force).
<citetitle><ulink url="http://www.ietf.org/rfc/rfc2279.txt">RFC 2279: UTF-8, a transformation format of ISO 10646</ulink></citetitle>.
F. Yergeau. 1998.
</bibliomixed>
<bibliomixed id="rfc2396"><abbrev>RFC 2396</abbrev>IETF (Internet Engineering Task Force).
<citetitle><ulink url="http://www.ietf.org/rfc/rfc2396.txt">RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax</ulink></citetitle>.
T. Berners-Lee, R. Fielding, L. Masinter. 1998.
</bibliomixed>
<bibliomixed id="rfc2732"><abbrev>RFC 2732</abbrev>IETF (Internet Engineering Task Force).
<citetitle><ulink url="http://www.ietf.org/rfc/rfc2732.txt">RFC 2732: Format for Literal IPv6 Addresses in URL's</ulink></citetitle>.
R. Hinden, B. Carpenter, L. Masinter. 1999.
</bibliomixed>
<!--
<bibliomixed id="relax"><abbrev>RELAX</abbrev>
<citetitle>ISO/IEC DTR 22250-1, Document Description and
Processing Languages -- Regular Language Description for
XML (<ulink url="http://www.xml.gr.jp/relax/">RELAX</ulink>) -- Part 1:
RELAX Core</citetitle>, ISO/IEC, 2000.
</bibliomixed>
-->
<bibliomixed id="xmlschema"><abbrev>W3C XML Schema</abbrev>Henry S. Thompson,
David Beech, Murray Maloney, et al. editors.
<citetitle><ulink url="http://www.w3.org/TR/xmlschema-1/">XML Schema Part 1: Structures</ulink></citetitle>.
World Wide Web Consortium, 2000.
</bibliomixed>
<bibliomixed id="req"><abbrev>Requirements</abbrev>Norman Walsh, editor.
<citetitle><ulink url="http://www.oasis-open.org/committees/entity/background/req.html">OASIS Entity Resolution Technical Committee Requirements
Document</ulink></citetitle>. OASIS. 2000.
</bibliomixed>
</bibliodiv>
</bibliography>
</article>