Schema and dtd management

[David Jencks <da...@coredevelopers.net>]

After working with Kristian Koehler on improvements to the 
LocalEntityResolver I'd like to discuss reorganizing the schemas and 
dtds.

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 
classpath.

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)
or
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,

thanks
david jencks

Re: Schema and dtd management

[Jeremy Boynes <je...@coredevelopers.net>]

David Jencks wrote:


> It looks to me as if the service deployer is currently in the kernel 
> module.  I don't see that as a particularly Good Thing, but I'm not sure 
> where to move it to.  Is this changed in the new deployment stuff you 
> (Jeremy) are working on?
> 

Yes.

I have most of the code but need Dain's input on how to map existing 
-service.xml files to the new GBeans (specifically constructors). In the 
mean time I am putting together doco on the new stuff (honest :-P ).

-- 
Jeremy

Re: Schema and dtd management

[David Jencks <da...@coredevelopers.net>]

On Monday, January 5, 2004, at 10:18 AM, Jeremy Boynes wrote:

> Aaron Mulder wrote:
>
>> On Sun, 4 Jan 2004, Jeremy Boynes wrote:
>
>>> -1 as the kernel should not require the XML stuff to run
>>>    The service deployer may rely on this, but that is not a kernel
>>>    component
>> 	Doesn't the kernel read XML configuration files
>> (boot-service.xml)?  If so, shouldn't it be able to use the entity
>> resolver to validate those?
>
> It shouldn't - only the service deployer should need to read those 
> files.

It looks to me as if the service deployer is currently in the kernel 
module.  I don't see that as a particularly Good Thing, but I'm not 
sure where to move it to.  Is this changed in the new deployment stuff 
you (Jeremy) are working on?

david

Re: Schema and dtd management

[Jeremy Boynes <je...@coredevelopers.net>]

Aaron Mulder wrote:

> On Sun, 4 Jan 2004, Jeremy Boynes wrote:
> 

>>-1 as the kernel should not require the XML stuff to run
>>    The service deployer may rely on this, but that is not a kernel
>>    component
> 
> 
> 	Doesn't the kernel read XML configuration files
> (boot-service.xml)?  If so, shouldn't it be able to use the entity
> resolver to validate those?
> 

It shouldn't - only the service deployer should need to read those files.

-- 
Jeremy

Re: Schema and dtd management

[Aaron Mulder <am...@alumni.princeton.edu>]

On Sun, 4 Jan 2004, Jeremy Boynes wrote:
> > 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.
> > 
> 
> -1 as the kernel should not require the XML stuff to run
>     The service deployer may rely on this, but that is not a kernel
>     component

	Doesn't the kernel read XML configuration files
(boot-service.xml)?  If so, shouldn't it be able to use the entity
resolver to validate those?

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

	I prefer to keep them separate, so long as we agree to keep the 
Geronimo content out of the Sun namespace.  If it's all going in the same 
namespace, then I'd like to put the files in one place.  My recollection 
of the schema problems we had before is that Geronimo entities can't 
"extend" Sun entities unless they're in the same namespace, but I still 
prefer to keep the namespaces separate.

Aaron

Re: Schema and dtd management

[Jeremy Boynes <je...@coredevelopers.net>]

David Jencks wrote:

<snip/>

> 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.
> 

-1 as the kernel should not require the XML stuff to run
    The service deployer may rely on this, but that is not a kernel
    component

> 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)
> or
> 2.b We could have the sun grammars in a spec module and the geronimo 
> ones in a modules module. (two catalogs)

I prefer this option

-- 
Jeremy

Re: Schema and dtd management

[Kristian Köhler <Kr...@gmx.de>]

David Jencks wrote:

> -----------
> Reorganization proposal:
> 
> 2.b We could have the sun grammars in a spec module and the geronimo 
> ones in a modules module. (two catalogs)

Two modules in CVS but IMO there should only be one directory in the 
distribution. If the grammars are scattered around the file system some 
tools without a good entity resolving will have problems to handle all 
the grammars (like my XMLSpy ;-)) and it's hard to create a new valid 
xml file. The user will always have to copy the files to one loaction.

> 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,

I think the grammars should be unpacked in a directory (or two 
(SUN/Geronimo) - I prefer one directory). IMO that's more transparent 
for users. They can easily see which grammars Geronimo use. With this 
approach it's also possible to include a graphical representation of the 
grammars a la JBoss. With my original patch I included such a local 
repository (etc/xml). I think this would be a good place for that files. ;-)


Kristian