Table of Contents
In a nutshell, it rewrites URIs. Hence, it is part of a redirecting mechanism, where it is inputted with one URI, and by its user supplied rules returns a new URI, which then is dereferenced. These rules can be described in an XML catalog file, or a catalog can be directly constructed via the implementation's API.
This is an example of an XML Catalog file:
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
<!-- An URI identical to "http://www.example.com/1999/files/readme.txt"
will be replaced with "http://www.example.com/2005/files/readme.txt" -->
<uri name="http://www.example.com/1999/files/readme.txt"
uri="http://www.example.com/2005/files/readme.txt"/>
<!-- Makes DTD validation use a local DTD, instead of the one on the W3C site. -->
<public publicId="-//W3C//DTD XHTML 1.0 Transitional//EN" uri="myDTDs/"xhtml1-transitional.dtd"/>
<rewriteURI rewritePrefix="http://www.kde.org/css/"
foo="kde-www-testing/css/" />
</catalog>
Let's say Konqueror had support for OASIS XML Catalogs and that the above catalog was loaded, then would a request such as http://www.kde.org/css/base.css result in an attempt to load the local file kde-www-testing/css/base.css.
While the example was as trivial it could be, the usefulness of catalogs becomes more apparent when identifiers such as URNs, which are abstract identifiers instead of physical locators, and XML's Public Identifers are used. Typical uses for catalogs are XML applications, catalogs are almost indispensable in large documentation projects, or to simply map Internet resources to local ones. For example, KDE uses catalogs for its documentation system, and some web development IDEs uses catalogs for organizing website projects.
The typical use for OASIS Catalogs is in XML applications. As soon as the toolchain is to load a file, a stylesheet, DTD, XML file or similar, it simply do a lookup in the catalog to see what the user actually wants to be loaded. What should be remembered, is that OASIS XML Catalogs isn't bound to XML, but simply is a mechanism for changing URIs.
What makes KDE's technologies strong in my opinion, is that they're frameworks which individual applications easily gains from. When not constraining an entity resolver mechanism, such as OASIS XML Catalog, to XML, but takes it to the same level of genericness and transparency which KIO and similar sits at, it opens up for interesting possibilities.
A common problem is that when files are deleted or moved, it results in the desktop environment not being aware of the change. For example, mechanisms such as “recent files” breaks, and applications gives loading errors because the user's files do not exists where they were expected to be.
Let's say that as soon a set of files is moved or deleted, it is to an internal catalog added the appropriate entry which maps the old location to the new. This catalog entry could have additional meta-data, such as expiration-date and semantical information(whether it was a deletion or move, for example). Any code which then needs to reference a file simply feeds its URIs through the entity resolver to catch up with the user's changes. As an end result; move a couple of files, start a random application, view the menu and it have adapted to the new locations. The desktop environment understood what the user did, and adapted accordingly.
As soon one starts to think about implementation and possible catches it quickly becomes a complicated discussion. This matter should also be seen from the broad idea it is part of — desktop meta-data, file search and so forth, although that shouldn't hinder incremental development and adapting optimized solutions for particular problems.
Nevertheless, food for thought.