cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: proposal: entity resolution capability
Date Wed, 15 Aug 2001 16:16:35 GMT
I posted this proposal last week, but there was no reply.
Here is a very brief overview. However, please see the URL
listed below for the full explanation, solution, patches,
examples, background references, and pointers to past
discussion on this topic.

SGML/XML has a standards-based mechanism to resolve the
location of any external entities (e.g. DTDs, sets of
characters entities such as symbols, xml sub-documents).
This mechanism is called "catalog" and uses a simple
plain-text file to map Public Identifiers and System
Identifiers to other System Identifiers. For example, if
your XML instance document declares a remote DTD using
a URL as the system identifier, then you can map that
resource to a local copy of the DTD.

Apache Cocoon does not yet have the ability to utilise
entity catalogs. However, support can easily be added.
This proposal explains the issues and shows how to do it.

Catalogs are a very powerful feature, which all XML tools
need to provide. Unfortunately, many tools are crippled
because they do not provide catalog support. Therefore,
they cannot be used for serious XML processing.

The issue has been raised on a few occasions by various
people. However, discussions did not go far. There were
also quite a lot of user complaints about their entities
not being resolved. Here are the two main dev posts ...
 Re: DTD PUBLIC ID resolution - 2000-08-05
 [Fwd: Re: C2: Sitemaps and DTD's] - 2001-05-03

We now provide a complete explanation and a working
solution. Please consider this feature for Cocoon 2.

regards, David Crossley

> Date: Fri, 10 Aug 2001 16:04:27 +1000
> From: David Crossley <>
> We now have the capability for resolution of external XML
> entities working in our local Apache Cocoon 2.1-dev
> Rather than trying to explain it in email, i have taken the
> approach of preparing a documentation page. This is the
> clearest way to explain it. Also, the documentation can
> then evolve to become the user documentation.
> There is a complete documentation page at the following URL,
> which provides some background, explains all of the bits,
> provides the code diffs, and the configuration pieces. The
> page also records a few outstanding development issues.
> A demonstration application as an Apache Cocoon sample is
> also provided.
> (That page and the sample are not being served by cocoon, it
> is just a static printer-docs copy from our local system.)
> The page has a link to a tar file of all the various pieces.
> It is not difficult to add the support, if you would like
> to start to use it in your local development systems.
> Hopefully this provides a good basis for further discussion
> on the cocoon-dev list. I know that you need more reading like
> a hole-in-the-head, but it is worth it. This capability adds
> phenomenal power to an already phenomenal system.
> cheers, David Crossley

To unsubscribe, e-mail:
For additional commands, email:

View raw message