Overview
The entity resolution capability is recently implemented at the Cocoon
level. However, this capability is required for all XML Apache projects.
So its base implementation should be moved to Avalon Excalibur.
Everytime that an XML parser is used, it needs to have the resolver
attached via the setEntityResolver() method.
Cocoon and other projects need to be able to configure the resolver to
specify additional catalogs and to set the verbosity level for the log
messages.
For background see the main Cocoon documentation for
Entity Catalogs.
Current implementation with Cocoon
Configuration
-
cocoon.roles defines role for Resolver
-
cocoon.xconf set parameters for Resolver
-
CatalogManager.properties additional config method
Components
-
src/org/apache/cocoon/components/resolver/ResolverImpl.java
implements the Sun "XML Entity and URI Resolvers"
-
Gets a new CatalogResolver() which reads the default
CatalogManager.properties to set some properties for
local site config and load some local catalogs
-
Applies any parameters that may have been specified in cocoon.xconf
(e.g. verbosity)
-
Loads the Cocoon system catalog (which resolves all the DTDs
and entity sets that are used by Cocoon)
-
Loads any additional local catalogs that may have been specified in
cocoon.xconf
-
Allows the application to resolve external entities via resolveEntity().
-
setEntityResolver() for any parser that is used ... JaxpParser, XercesParser, PoolJaxpParser, XSLTProcessorImpl, (are there others?)
-
Default Entities and Catalogs
-
webapp/resources/entities/ holds all of the DTDs and
character entity sets currently used by Cocoon. These would also form a
base for any userland application (they can configure their own additional
entities).
-
There are historical copies of all entities at
documentation/xdocs/dtd/ (this is the default location
declared as systemId in each XML document). An open issue is
whether to leave them there as a belt-and-braces mechanism, or to rely
completely on the entity resolver.
-
The Cocoon system catalog is an OASIS plain-text catalog declaring
all of the necessary entities
webapp/resources/entities/catalog
Moving to Avalon
 | TODO: describe overview of issues. |
Evidently this has
already happened.
We will need to investigate and see what changes need to be made to the
relevant Cocoon docs.
Other Notes
cocoon-dev 2001-11-09 (Identifying Components for Avalon)
... It would be reasonable for there to be an ExcaliburResolver,
and a CocoonResolver that both extend the same interface.
In fact, it would be reasonable for the CocoonResolver to
extend the ExcaliburResolver.
The term "resolver" is used in many different ways by Cocoon.
So perhaps a better name would be CocoonEntityResolver or CocoonCatalogResolver.
Which other Apache projects are using the DTDs that are in Cocoon CVS?
Some will need to move to Excalibur, Cocoon-specific ones will remain.
Some useful discussion threads
|
