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 <[EMAIL PROTECTED]> > > 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. > > www.indexgeo.com.au/work/cocoon/catalog.html > (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. > www.indexgeo.com.au/work/cocoon/catalog-bits.tar.gz > 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: proposal: entity resolution capability
cocoon-dev-return-16217-archive=jab . org Wed, 15 Aug 2001 10:17:35 -0700
- proposal: entity resolution capa... David Crossley
- Re: proposal: entity resolu... cocoon-dev-return-16217-archive=jab . org
- Re: proposal: entity resolu... Craeg K. Strong
- Re: proposal: entity re... David Crossley
- Re: proposal: entity resolu... Davanum Srinivas
- Re: proposal: entity resolu... David Crossley
- Re: proposal: entity resolu... Davanum Srinivas
- Re: proposal: entity resolu... David Crossley
- Re: proposal: entity resolu... Davanum Srinivas
- Re: proposal: entity resolu... Giacomo Pati
- Re: proposal: entity re... Davanum Srinivas