The XML Catalogs is an OASIS committee specification, basically an "SGML Catalog
for XML". Simplified, a catalog's function is to map public identifiers to
The specification was developed under the Entity Resolution committee:
The actual specification is at (Aug 6 2001):
Currently there are at least five tools that support this specification ranging
from gnome-xml to Sun's Java Resolver classes and some Perl modules.
Implementing this specification would allow us to easily add support for some
well-known DTDs (based on their public identifiers) by placing the DTDs locally
into dtd or chrome directory (we read external DTDs if they are there). This is
also a performance issue: if a match is found in the XML Catalog and we can load
the DTD from a local file, we do not need to load it from the web.
xpinstall packages should be able to register new catalogs.
Any idea how this could happen?
The spec notes that catalogs are linked with some next-catalog entry, which would
require a new catalog to modify the currently last one. That doesn't sound right.
We have global and user installed packages, too.
I have some additional information
* KDE have an OASIS XML Catalog implementation which perhaps could be used in
Mozilla et al. It's written in C++ with stl-like data/container classes(the
Qt/KDE libraries), synchronous file loading(due to API designs), written
against a referenced counted DOM implementation(small usages of DOM 3 core), is
documented, debugged, and licensed under GNU LGPL. sloccount says it's about
2500 lines of code. I can't tell whether integration work would be more than
writing a stack from scratch, but it's far from impossible. The implementation
can be found in:
* In relation to KDE's implementation, was a test suite brought into the light.
It is quite good, and has currently 42 tests. Licensed under MIT license. It
can be found at:
I'm author and maintainer of the implementation, and co-author and maintainer
of the test suite, so feel free to contact me.