XML Catalogs

OASIS Entity Resolution Technical Committee

Revision date: 13 Mar 2001

Permission to reproduce parts or all of this information in any form is granted to OASIS members provided that this information by itself is not sold for profit and that OASIS is credited as the author of this information.

Status of this Document

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.

Abstract

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.

However, the interoperability of XML documents has been impeded in several ways by the lack of entity management facilities:

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.
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 ftp: protocol, for example, is not accessible to a tool that does not support that protocol.
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.

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 specification defines an entity catalog that maps an entity's external identifier to a URI.

OASIS Entity Resolution Technical Committee
Working Draft: 13 Mar 2001
Working Draft: 16 Feb 2001
Working Draft: 31 Jan 2001
Working Draft: 08 Jan 2001
Working Draft: 15 Dec 2000

Introduction

In order to make optimal use of the information about an XML external resource, there must be some interoperable way to map the information in an XML external identifier into a URI for the desired resource.

This specification defines an entity catalog that handles two simple cases:

Mapping an external entity's public identifier and/or system identifier to an alternate URI.
Mapping the URI of a resource (a namespace name, stylesheet, image, etc.) to an alternate URI.

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.

An Entity Catalog

This specification defines a format for an application-independent entity catalog that maps external identifiers and URIs to (other) URIs. This catalog is used by an application's entity manager. This specification does not dictate when an entity manager should access this catalog; for example, an application may attempt other mapping algorithms before or (if the catalog fails to produce a successful mapping) after accessing this catalog. The catalog has a standard format. Each application that uses it must provide the user with a mechanism for specifying the catalog to be accessed.

For the purposes of this specification, the term catalog refers to the logical “mapping” information that may be physically contained in one or more catalog entry files. The catalog, therefore, 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 specification uses the term “catalog entry file” 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 referenced by a URL, or some dynamically generated set of catalog entries.)

Each entry in the catalog associates a URI with information about the external entity that appears in the XML document. For example, the following are possible catalog entries that associate a public identifier with a URI:

<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"/>

The complete set of catalog entry types defined by this Specification are: public, system, delegate, uri, and nextCatalog. Two grouping elements, catalog, the top-level element, and group are also defined.

Furthermore, to provide for possible future extensions or other uses of this catalog, its format allows for “other information”—indicated by an elements and attributes from a namespace other than the one defined by this Specification—that is irrelevant to and ignored by this specification. This Specification reserves all elements and attributes from its namespace for current and future use. In addition, unqualified attributes other than the attributes explicitly described in this Specification, are reserved for future use.

The catalog can be used in two different, independent ways: (1) it can be used to lookup the replacement text for an external entity, or (2) it can be used to lookup an alternate URI for a resource. Although these functions are similar in nature, they are distict and exercise two different sets of entries in the catalog.

In either case, these entries in the catalog is interpreted as follows:

The catalog entry is the root of a catalog. All other entries occur within this catalog element.
The group entry is simply a wrapper on which override and xml:base can occur. It has no other effect on the entries that it contains. When examining entries in the catalog sequentially, the presence of a group entry does not effect the order in which they are examined.
The nextCatalog entry indicates that an entity manager should use the associated URI to locate an additional catalog entry file to be processed after the current catalog entry file.

The nextCatalog entry can be used to insert new catalog entry files into the current list of catalog entry files. The catalog attribute on a nextCatalog entry is used to locate another catalog entry file that is processed after the current catalog entry file if the current catalog entry file does not provide a match. Multiple nextCatalog entries are allowed, and the referenced catalog entry files will be inserted into the current catalog list in order. Note that the effect of any nextCatalog entry would occur only after all other entries in this catalog entry file have been considered.

External Identifier Entries

External identifiers ([Production 75] of XML 1.0 Second Edition) identify the external subset, entities, and notations of an XML document. The input to a resolver, such as the SAX entityResolver(), that locates external identifiers is a system identifier and optionally a public identifier.

For the purposes of resolving external identifiers, the following entries are considered:

The public entry indicates that an entity manager should use the associated URI to locate the replacement text for an entity with the specified public identifier.
The system entry indicates that an entity manager should use the associated URI to locate the replacement text for an entity whose external identifier's system identifier is explicitly specified by the system identifier.
The delegate entry indicates that external identifiers with a public identifier that starts with the specified string should be resolved using a catalog specified by the associated URI.

Although the system identifier is assumed to be “a URI reference…meant to be dereferenced to obtain input for the XML processor to construct the entity's replacement text”, 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 may not be the best identifiers for the replacement text. For this or other reasons, it may be desireable to prefer the public identifier over the system identifier in determining the entity's replacement text. Therefore, this resolution defines two modes for searching the catalog: “prefer system identifier” mode and “prefer public identifier” mode:

If system identifiers are preferred and there is no matching system type entry, then the system identifier is used as the URI regardless of any public identifier. This specification 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 URI, 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.
If public identifiers are preferred and there is no matching system type entry, the system identifier is used as the URI only if no mapping can be found in the catalog entry file for the public identifier (if a public identifier was specified).

The override attribute can be used on catalog and group entry types to indicate for any set of catalog entries whether they should be able to be used in matches that may override an explicit system identifier. Each occurrence of an override attribute specifies the search strategy mode for entries contained within the catalog or group element on which it occurs. A public or delegate entry encountered when override is “yes” (corresponding to the mode where public identifiers are preferred) will be considered for possible matching whether or not the external identifier has an explicit system identifier. A public or delegate entry encountered when override is “no” (corresponding to the mode where system identifiers are preferred) will be ignored during lookups for which the external identifier has an explicit system identifier. No other entry types are affected by the override attribute. The initial search strategy in force at the beginning of each catalog entry file depends on the preference as determined by the application (possibly under user control).

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 override attribute on the catalog entry.

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). A more specific matching entry in one catalog entry file will take priority over a less specific matching entry in the same catalog entry file. For this purpose, the order of specificity of match (most specific first) is:

system type entries;
public type entries;
delegate entries ordered by the length of the start string, longest first;

Within any given category of equal specificity, matches maintain the order of their entries in the catalog entry file so that the first such match will take priority.

URI Entries

Other URI references, for example Namespace names, stylesheets, included files, graphics, and hypertext references, simply identify other resources. The input to a resolver, such as the JAXP URIResolver(), that locates resources is simply the original URI reference.

For the purposes of resolving other URIs, the entries in the catalog are interpreted as follows:

The uri entry indicates that the associated URI should be used to locate the resource whose URI references is explicitly specified by the name given.

As when resolving external identifiers, 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).

If more than one uri entry matches, the first such match will take priority.

The XML Entity Catalog Format

This specification defines an entity catalog in XML. It consists of elements from the OASIS Entity Catalog Namespace, http://www.oasis-open.org/committees/entity/draft. Elements from other namespaces are are allowed, but they are ignored by this specification.

The root element of the catalog, is catalog. There are six other elements: group, public, system, delegate, uri, and nextCatalog. Each of these elements are described in the following sections.

The `catalog` Entry

XML Entity Catalogs begin with the catalog element. This element may set the global override value and global base URI. It is otherwise just a container for the other elements.

The `group` Entry

The group element is a convenience wrapper for specifying an override or base URI for a set of catalog entries.

The `public` Entry

The public element associates a URI with a public identifier.

<public id = id publicId = public-identifier uri = uri-reference xml:base = uri-reference />

A public entry matches a public identifier if the normalized value of the public identifier is lexically identical to the normalized value of the publicId attribute of the entry.

The `system` Element

The system element associates a URI with a system identifier.

<system id = id systemId = uri-reference uri = uri-reference xml:base = uri-reference />

A system entry matches a system identifier if the system identifier is lexically identical to the normalized value of the systemId attribute of the entry.

[What about differently %-escaped escaped characters? Does RFC 2396 cover this?]

The `delegate` Element

The delegate element associates an alternate catalog with a partial public identifier.

<delegate id = id publicIdStartString = public-identifier-prefix catalog = uri-reference xml:base = uri-reference />

A delegate entry matches a public identifier if the normalized value of the public identifier begins precicely with the the normalized value of the publicIdStartString attribute of the entry.

Given the following catalog fragment:

<delegate publicIdStartString="-//OASIS//"
          catalog="http://www.oasis-open.org/catalog"/>
<delegate publicIdStartString="-//OASIS//DTD DocBook "
          catalog="http://www.oasis-open.org/docbook/catalog"/>
<delegate publicIdStartString="-//OASIS//DTD XML Catalog //"
          catalog="http://www.oasis-opne.org/committees/entity/catalog"/>

The first two entries match the public identifier “-//OASIS//DTD DocBook V4.1.2//EN”, but the third does not.

The `uri` Element

The uri element associates an alternate URI with a URI.

<uri id = id name = uri-reference uri = uri-reference xml:base = uri-reference />

A uri entry matches a URI if the URI is lexically identical to the normalized value of the name attribute of the entry.

[What about differently %-escaped escaped characters? Does RFC 2396 cover this?]

The `nextCatalog` Element

The nextCatalog element indicates an additional catalog that may be considered during the process of resolution.

<nextCatalog id = id catalog = uri-reference xml:base = uri-reference />

Catalog Resolution Semantics

This section describes how catalog resolution is performed.

Resolution begins with a list of catalog files (possibly only a single file), and either an external identifier or a URI.

External Identifier Resolution

An external identifier will have at least one and perhaps both of the following:

a public identifier
a system identifier

Resolution follows the steps listed below, proceeding to each subsequent step if and only if no other action is indicated.

Resolution begins in the first catalog file in the current catalog list.
If a system identifier is provided, and at least one matching system entry exists, the value of the uri attribute of the first matching system entry is returned.

A matching system entry takes precedence, regardless of whether or not a public identifier or namespace name is also provided.
If a public identifier is provided, and at least one matching public entry exists, the value of the uri attribute of the first matching public entry is returned.

If a system identifier is also provided, only public entries that specify override="yes" are considered for matching, otherwise all public entries are considered.
If a public identifier is provided, and one or more delegate entries match, delegation is performed. If a system identifier is also provided, only delegate entries that specify override="yes" are considered for matching, otherwise all delegate entries are considered.

If delegation is to be performed, a new catalog list is generated from the set of all matching delegate entries. The value of the catalog attribute of each delegate entry is inserted into the new catalog list such that the delegate entry with the longest matching publicIdStartString is first on the list, the entry with the second longest match is second, etc.

These are the only catalogs 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 list used for delegation is distinct and unrelated to the “normal” catalog list.)

Catalog resolution restarts using exclusively the catalogs in this new list as the current catalog list and only the public identifier, regardless of whether or not a system identifier was originally provided: return to step 1.
If a namespace name is provided, and at least one matching namespace entry exists, the value of the uri attribute of the first matching namespace entry is returned.
If the current catalog file contains one or more nextCatalog entries, they are inserted, in the order that they appear in this catalog, onto the current catalog list, immediately after the current catalog.
If there are one or more catalogs remaining on the current catalog list, load the next catalog and continue resolution efforts: return to step 2.
If a system identifier was provided, return that system identifer.
No match was found. Signal failure in some appropriate way.

URI Resolution

Resolution of a generic URI follows the steps listed below, proceeding to each subsequent step if and only if no other action is indicated.

Resolution begins in the first catalog file in the current catalog list.
If at least one matching uri entry exists, the value of the uri attribute of the first matching uri entry is returned.
If the current catalog file contains one or more nextCatalog entries, they are inserted, in the order that they appear in this catalog, onto the current catalog list, immediately after the current catalog.
If there are one or more catalogs remaining on the current catalog list, load the next catalog and continue resolution efforts: return to step 2.
Return the original URI.

Author Control of Catalog Lookup

Authors need the ability to test the effect of catalog changes locally, so that users who share the same catalog-aware application are not affected during testing. However, when processing large collections of documents, it must be possible to ignore any and all test settings and process all documents identically. This leads to the following requirements:

Authors must be able to set the starting catalog on a per-document basis, overriding the default start catalog for their application;
It must be possible to disable the use of per-document starting catalogs as and when required.

XML Catalogs support these requirements through the use of a processing instruction, "oasis-xml-catalog", which allows the starting catalog to be set for a particular document. For example, in

<?xml version="1.0"?>
<?oasis-xml-catalog catalog="test/catalog/draft-catalog.xml"?>
<catalog>
  ...
</catalog>

the URL for the starting catalog is "test/catalog/draft-catalog.xml". The URL can be either (i) absolute or (ii) relative to the document which contains the processing instruction. The "oasis-xml-catalog" processing instruction must appear before the opening <catalog> tag, otherwise it is ignored.

Catalog-aware applications must support the "oasis-xml-catalog" processing instruction, and must also provide a facility which allows a user to request that any and all "oasis-xml-catalog" processing instructions are ignored.

Note: Catalog-aware applications must allow the name of this processing instruction to be changed from "oasis-xml-catalog" using an XML notation declaration which references the public ID shown in the following example:

<!NOTATION my-name-for-oasis-xml-catalog
           "-//OASIS::TC::ER//STARTING XML CATALOG//EN//1.0">

Appendix A. An XML Schema for the XML Catalog

This appendix is not normative.

The syntax for a catalog entry file is defined by this XML Schema:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE xsd:schema SYSTEM "http://www.w3.org/2000/10/XMLSchema.dtd" [
<!ENTITY % schemaAttrs "
    xmlns:xsd   CDATA   #IMPLIED
    xmlns:xml   CDATA   #IMPLIED
    xmlns:er    CDATA   #IMPLIED
">
]>
<xsd:schema xmlns:xsd='http://www.w3.org/2000/10/XMLSchema'
            xmlns:er='http://www.oasis-open.org/committees/entity/draft'
            targetNamespace='http://www.oasis-open.org/committees/entity/draft'
            elementFormDefault='qualified'>

  <!-- $Id: spec-2001-03-13.html,v 1.1 2001/03/13 19:20:01 ndw Exp $ -->

  <xsd:simpleType name='pubIdChars'>
    <!-- A string of the characters defined as pubIdChar in production 13
         of the Second Edition of the XML 1.0 Recommendation -->
    <xsd:restriction base='xsd:string'/>
  </xsd:simpleType>

  <xsd:simpleType name='publicIdentifier'>
    <xsd:restriction base='xsd:string'/>
  </xsd:simpleType>

  <xsd:simpleType name='partialPublicIdentifier'>
    <xsd:restriction base='er:pubIdChars'/>
  </xsd:simpleType>

  <xsd:simpleType name='systemIdentifier'>
    <xsd:restriction base='xsd:uriReference'/>
  </xsd:simpleType>

  <xsd:simpleType name='yesOrNo'>
    <xsd:restriction base='xsd:string'>
      <xsd:enumeration value='yes'/>
      <xsd:enumeration value='no'/>
    </xsd:restriction>
  </xsd:simpleType>

  <xsd:complexType name='catalog'>
    <xsd:choice minOccurs='1' maxOccurs='unbounded'>
      <xsd:element ref='er:public'/>
      <xsd:element ref='er:system'/>
      <xsd:element ref='er:uri'/>
      <xsd:element ref='er:delegate'/>
      <xsd:element ref='er:nextCatalog'/>
      <xsd:element ref='er:group'/>
      <xsd:any namespace='##other' processContents='skip'/>
    </xsd:choice>
    <xsd:attribute name='override' type='er:yesOrNo'/>
  </xsd:complexType>

  <xsd:complexType name='public'>
    <xsd:complexContent>
      <xsd:restriction base="xsd:anyType">
        <xsd:attribute name="publicId" type="er:publicIdentifier"
                       use="required"/>
        <xsd:attribute name="uri" type="xsd:uriReference" use="required"/>
      </xsd:restriction>
    </xsd:complexContent>
  </xsd:complexType>

  <xsd:complexType name='system'>
    <xsd:complexContent>
      <xsd:restriction base="xsd:anyType">
        <xsd:attribute name="systemId" type="er:systemIdentifier"
                       use="required"/>
        <xsd:attribute name="uri" type="xsd:uriReference" use="required"/>
      </xsd:restriction>
    </xsd:complexContent>
  </xsd:complexType>

  <xsd:complexType name='uri'>
    <xsd:complexContent>
      <xsd:restriction base="xsd:anyType">
        <xsd:attribute name="name" type="xsd:uriReference"
                       use="required"/>
        <xsd:attribute name="uri" type="xsd:uriReference" use="required"/>
      </xsd:restriction>
    </xsd:complexContent>
  </xsd:complexType>

  <xsd:complexType name='delegate'>
    <xsd:complexContent>
      <xsd:restriction base="xsd:anyType">
        <xsd:attribute name="publicIdStartString"
                       type="er:partialPublicIdentifier"
                       use="required"/>
        <xsd:attribute name="catalog" type="xsd:uriReference" use="required"/>
      </xsd:restriction>
    </xsd:complexContent>
  </xsd:complexType>

  <xsd:complexType name='nextCatalog'>
    <xsd:complexContent>
      <xsd:restriction base="xsd:anyType">
        <xsd:attribute name="catalog" type="xsd:uriReference" use="required"/>
      </xsd:restriction>
    </xsd:complexContent>
  </xsd:complexType>

  <xsd:complexType name='group'>
    <xsd:choice minOccurs='1' maxOccurs='unbounded'>
      <xsd:element ref='er:public'/>
      <xsd:element ref='er:system'/>
      <xsd:element ref='er:uri'/>
      <xsd:element ref='er:delegate'/>
      <xsd:element ref='er:nextCatalog'/>
      <xsd:any namespace='##other' processContents='skip'/>
    </xsd:choice>
    <xsd:attribute name='override' type='er:yesOrNo'/>
  </xsd:complexType>

  <xsd:element name="catalog" type="er:catalog"/>
  <xsd:element name="public" type="er:public"/>
  <xsd:element name="system" type="er:system"/>
  <xsd:element name="uri" type="er:uri"/>
  <xsd:element name="delegate" type="er:delegate"/>
  <xsd:element name="nextCatalog" type="er:nextCatalog"/>
  <xsd:element name="group" type="er:group"/>

</xsd:schema>

Appendix B. A TREX Grammar for the XML Catalog

This appendix is not normative.

<?xml version="1.0"?>
<grammar xmlns="http://www.thaiopensource.com/trex"
         ns="http://www.oasis-open.org/committees/entity/draft">

  <!-- $Id: spec-2001-03-13.html,v 1.1 2001/03/13 19:20:01 ndw Exp $ -->

  <start>
    <choice>
      <ref name="Catalog"/>
    </choice>
  </start>

  <define name="AnyOtherElement">
    <element>
      <not>
        <choice>
          <nsName/>
          <nsName ns=""/>
        </choice>
      </not>
      <zeroOrMore>
        <choice>
          <attribute>
            <not>
              <choice>
                <nsName/>
                <nsName ns=""/>
              </choice>
            </not>
          </attribute>
          <ref name="AnyOtherElement"/>
        </choice>
      </zeroOrMore>
    </element>
  </define>

  <define name="OptionalAttributes">
    <optional>
      <attribute name="xml:base"/>
    </optional>
    <optional>
      <attribute name="id"/>
    </optional>
  </define>

  <define name="OverrideAttribute">
    <attribute name="override">
      <choice>
        <string>no</string>
        <string>yes</string>
      </choice>
    </attribute>
  </define>

  <define name="Catalog">
    <element name="catalog">
      <ref name="OptionalAttributes"/>
      <optional>
        <ref name="OverrideAttribute"/>
      </optional>
      <oneOrMore>
        <choice>
          <ref name="Group"/>
          <ref name="Public"/>
          <ref name="System"/>
          <ref name="Uri"/>
          <ref name="Delegate"/>
          <ref name="NextCatalog"/>
          <ref name="AnyOtherElement"/>
        </choice>
      </oneOrMore>
    </element>
  </define>

  <define name="Group">
    <element name="group">
      <ref name="OptionalAttributes"/>
      <optional>
        <ref name="OverrideAttribute"/>
      </optional>
      <oneOrMore>
        <choice>
          <ref name="Public"/>
          <ref name="System"/>
          <ref name="Uri"/>
          <ref name="Delegate"/>
          <ref name="NextCatalog"/>
          <ref name="AnyOtherElement"/>
        </choice>
      </oneOrMore>
    </element>
  </define>

  <define name="Public">
    <element name="public">
      <attribute name="publicId"/>
      <attribute name="uri"/>
      <ref name="OptionalAttributes"/>
      <empty/>
    </element>
  </define>

  <define name="System">
    <element name="system">
      <attribute name="systemId"/>
      <attribute name="uri"/>
      <ref name="OptionalAttributes"/>
      <empty/>
    </element>
  </define>

  <define name="Uri">
    <element name="uri">
      <attribute name="name"/>
      <attribute name="uri"/>
      <ref name="OptionalAttributes"/>
      <empty/>
    </element>
  </define>

  <define name="Delegate">
    <element name="delegate">
      <attribute name="publicIdStartString"/>
      <attribute name="catalog"/>
      <ref name="OptionalAttributes"/>
      <empty/>
    </element>
  </define>

  <define name="NextCatalog">
    <element name="nextCatalog">
      <attribute name="catalog"/>
      <ref name="OptionalAttributes"/>
      <empty/>
    </element>
  </define>
</grammar>

Appendix C. A RELAX Grammar for the XML Catalog

This appendix is not normative.

<?xml version='1.0'?>
<!DOCTYPE module SYSTEM "/share/doctypes/RELAX/relaxCore.dtd">

<module moduleVersion="0.1"
    relaxCoreVersion="1.0"
    targetNamespace="http://www.oasis-open.org/committees/entity/draft"
    xmlns="http://www.xml.gr.jp/xmlns/relaxCore">

  <!-- $Id: spec-2001-03-13.html,v 1.1 2001/03/13 19:20:01 ndw Exp $ -->

  <interface>
    <export label="catalog"/>
  </interface>

  <attPool role='optional.attributes'>
    <attribute name='id' type='ID'/>
    <attribute name='xml:base' type='string'/>
  </attPool>

  <attPool role='override.attribute'>
    <attribute name='override' type='NMTOKEN'>
      <enumeration value='no'/>
      <enumeration value='yes'/>
    </attribute>
  </attPool>

  <elementRule role="catalog">
    <choice occurs="+">
      <ref label="public"/>
      <ref label="system"/>
      <ref label="uri"/>
      <ref label="delegate"/>
      <ref label="nextCatalog"/>
      <ref label="group"/>
    </choice>
  </elementRule>

  <elementRule role="public">
    <empty/>
  </elementRule>

  <elementRule role="system">
    <empty/>
  </elementRule>

  <elementRule role="uri">
    <empty/>
  </elementRule>

  <elementRule role="delegate">
    <empty/>
  </elementRule>

  <elementRule role="nextCatalog">
    <empty/>
  </elementRule>

  <elementRule role="group">
    <choice occurs="+">
      <ref label="public"/>
      <ref label="system"/>
      <ref label="uri"/>
      <ref label="delegate"/>
      <ref label="nextCatalog"/>
    </choice>
  </elementRule>

  <tag name="catalog">
    <ref role="optional.attributes"/>
    <ref role="override.attribute"/>
  </tag>

  <tag name="group">
    <ref role="optional.attributes"/>
    <ref role="override.attribute"/>
  </tag>

  <tag name="public">
    <ref role="optional.attributes"/>
    <attribute name="publicId" type='string' required='true'/>
    <attribute name="uri" type='string' required='true'/>
  </tag>

  <tag name="system">
    <ref role="optional.attributes"/>
    <attribute name="systemId" type='string' required='true'/>
    <attribute name="uri" type='string' required='true'/>
  </tag>

  <tag name="uri">
    <ref role="optional.attributes"/>
    <attribute name="name" type='string' required='true'/>
    <attribute name="uri" type='string' required='true'/>
  </tag>

  <tag name="delegate">
    <ref role="optional.attributes"/>
    <attribute name="publicIdStartString" type='string' required='true'/>
    <attribute name="catalog" type='string' required='true'/>
  </tag>

  <tag name="nextCatalog">
    <ref role="optional.attributes"/>
    <attribute name="catalog" type='string' required='true'/>
  </tag>

</module>

Appendix D. A DTD for the XML Catalog

This appendix is not normative.

The syntax for a catalog entry file is partially^[1] defined by this Document Type Definition:

<!-- $Id: spec-2001-03-13.html,v 1.1 2001/03/13 19:20:01 ndw Exp $ -->

<!ENTITY % pubIdChars "CDATA">
<!ENTITY % publicIdentifier "CDATA">
<!ENTITY % partialPublicIdentifier "%pubIdChars;">
<!ENTITY % uriReference "CDATA">
<!ENTITY % systemIdentifier "%uriReference;">
<!ENTITY % yesOrNo "(yes|no)">

<!ENTITY % p "">
<!ENTITY % s "">
<!ENTITY % nsdecl "xmlns%s;">

<!ENTITY % catalog "%p;catalog">
<!ENTITY % public "%p;public">
<!ENTITY % system "%p;system">
<!ENTITY % uri "%p;uri">
<!ENTITY % delegate "%p;delegate">
<!ENTITY % nextCatalog "%p;nextCatalog">
<!ENTITY % group "%p;group">

<!ELEMENT %catalog; (%public;|%system;|%uri|%delegate;|%nextCatalog;|%group;)+>
<!ATTLIST %catalog;
    %nsdecl;    %uriReference;      #FIXED
        'http://www.oasis-open.org/committees/entity/draft'
    override    %yesOrNo;       #IMPLIED
    xml:base    %uriReference;      #IMPLIED
>

<!ELEMENT %public; EMPTY>
<!ATTLIST %public;
    id      ID          #IMPLIED
    publicId    %publicIdentifier;  #REQUIRED
    uri     %uriReference;      #REQUIRED
    xml:base    %uriReference;      #IMPLIED
>

<!ELEMENT %system; EMPTY>
<!ATTLIST %system;
    id      ID          #IMPLIED
    systemId    %systemIdentifier;  #REQUIRED
    uri     %uriReference;      #REQUIRED
    xml:base    %uriReference;      #IMPLIED
>

<!ELEMENT %uri; EMPTY>
<!ATTLIST %uri;
    id      ID          #IMPLIED
    name        %uriReference;      #REQUIRED
    uri     %uriReference;      #REQUIRED
    xml:base    %uriReference;      #IMPLIED
>

<!ELEMENT %delegate; EMPTY>
<!ATTLIST %delegate;
    id      ID          #IMPLIED
    publicIdStartString %partialPublicIdentifier;   #REQUIRED
    catalog     %uriReference;      #REQUIRED
    xml:base    %uriReference;      #IMPLIED
>

<!ELEMENT %nextCatalog; EMPTY>
<!ATTLIST %nextCatalog;
    id      ID          #IMPLIED
    catalog     %uriReference;      #REQUIRED
    xml:base    %uriReference;      #IMPLIED
>

<!ELEMENT %group; (%public;|%system;|%uri;|%delegate;|%nextCatalog;)+>
<!ATTLIST %group;
    id      ID          #IMPLIED
    override    %yesOrNo;       #IMPLIED
    xml:base    %uriReference;      #IMPLIED
>

References

Normative

Tim Bray, Jean Paoli, and C. M. Sperberg-McQueen, Eve Maler, editors. Extensible Markup Language (XML) 1.0 Second Edition. World Wide Web Consortium, 2000.

Tim Bray, Dave Hollander, and Andrew Layman, editors. Namespaces in XML. World Wide Web Consortium, 1999.

Jonathan Marsh, editor. XML Base. World Wide Web Consortium, 2000.

Non-Normative

Paul Grosso, editor. OASIS Technical Resolution 9401:1997 (Amendment 2 to TR 9401). OASIS. 1997.

IETF (Internet Engineering Task Force). RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax. T. Berners-Lee, R. Fielding, L. Masinter. 1998.

Henry S. Thompson, David Beech, Murray Maloney, et. al. editors. XML Schema Part 1: Structures. World Wide Web Consortium, 2000.

Paul V. Biron and Ashok Malhotra, editors. XML Schema Part 2: Datatypes. World Wide Web Consortium, 2000.

Norman Walsh, editor. OASIS Entity Resolution Technical Committee Requirements Document. OASIS. 2000.

^[1] Any catalog file which is valid according to this DTD is valid according to this Specification. However, catalog files which make use of extension elements or attributes may be valid according to this Specification but invalid according to this DTD, due to the limits of DTD validation with respect to namespaces.

entity-resolution message

XML Catalogs

OASIS Entity Resolution Technical Committee

Introduction

An Entity Catalog

External Identifier Entries

URI Entries

The XML Entity Catalog Format

The catalog Entry

The group Entry

The public Entry

The system Element

The delegate Element

The uri Element

The nextCatalog Element

Catalog Resolution Semantics

External Identifier Resolution

URI Resolution

Author Control of Catalog Lookup

Appendix A. An XML Schema for the XML Catalog

Appendix B. A TREX Grammar for the XML Catalog

Appendix C. A RELAX Grammar for the XML Catalog

Appendix D. A DTD for the XML Catalog

References

Normative

Non-Normative

The `catalog` Entry

The `group` Entry

The `public` Entry

The `system` Element

The `delegate` Element

The `uri` Element

The `nextCatalog` Element