geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Schema and dtd management
Date Sun, 04 Jan 2004 22:09:51 GMT
After working with Kristian Koehler on improvements to the 
LocalEntityResolver I'd like to discuss reorganizing the schemas and 

Kristian's additions let us use  the standard xml catalog format to 
identify locations looked up by publicId or systemId during xml 
processing.  I think everything possible should be listed in one or 
more catalogs and no reliance placed on a local repository or on the 

Before discussing reorganization, I have a question that I hope an xml 
expert can answer.  The documentation I have been able to find for 
EntityResolver seems to indicate that it is intended only to look up 
entities by publicId or systemId, and mentions nothing about resolving 
namespace locations.  However, xerces appears to resolve schemas 
mentioned in xsi:schemaLocation by looking up publicId=null, 
systemId=URI given as schemaLocation.  I can't find any information as 
to whether this is covered by any standards.  Does anyone know anything 
more about this?

Reorganization proposal:

1. move LocalEntityResolver to kernel module.  IMO it should be used 
for validating/loading mbean configurations.  This will presumably also 
require setting up its mbean in the boot.mlet.

2. move all the grammars (schemas and dtds) to a separate module, 
either in specs or modules.  This includes the schemas included in 
modules/core/schema and several dtds (and schemas?) scattered through 
the spec modules.  Obviously this depends partly on clearing up whether 
we can have the sun grammars in our cvs at all.

2.a. We could put all the grammars in one module, both the sun  ones 
and the geronimo ones. (one cataog)
2.b We could have the sun grammars in a spec module and the geronimo 
ones in a modules module. (two catalogs)

There is also a question about whether the grammars should be in a jar 
file as at present or unpacked in a directory.  A jar file makes 
distribution slightly easier, whereas an unpacked directory makes it 
easier for users to actually find and look at the contents.  There is 
some indication in the catalog code that it may not relate too well 
with jar files: I haven't gotten the catalog to work with jar files yet.

Comments appreciated,

david jencks

View raw message