It's OK with me so long as we have a converter to change the attribute
into an element on any schemas that had the old one and will now have
the new one.

I think we must also put in a header comment with a change log in each
schema we change.  Perhaps under the license, something like:

<!--  CHANGE LOG FOR THIS SCHEMA
1/26/2006 -- changed inverseClassLoading attribute to an element
imported from the geronimo-deployment-1.0.xsd schema.  Code updated in
Geronimo 1.0.1 and 1.1 to silently convert the attribute to the
element so old documents will still work as expected.
-->

The reason for this is that I would prefer to avoid incrementing the
overall Schema version number for relatively minor changes (really,
for anything between major product versions), but as a developer I
*hate* it when a schema just silently changes without any kind of
acknowledgement, and I don't feel that the SVN logs are sufficient for
end-users to refer to.

Thanks,
    Aaron


On 1/26/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
>
>
> David Jencks wrote:
> >
> > On Jan 26, 2006, at 7:53 AM, Jeff Genender wrote:
> >
> >> Ping!  Anybody out there?
> >>
> >> Jeff Genender wrote:
> >>> Hi,
> >>>
> >>> I was going through the generic, tomcat and jetty web xsds and I saw a
> >>> number of issues I wanted to chat about and see if I can personally be
> >>> cleared up, or if I am seeing some anomolies.
> >>>
> >>> I notice a couple of differences that weren't making a lot of sense
> >>> to me.
> >>>
> >>> First the geronimo-jetty-1.0 appears to still have the
> >>> container-configType in the XSD.  Am I correct in assuming that this
> >>> should only be in the generic?
> >
> > yes
> >>>
> >>> Second, I noticed both the geronimo-jetty-1.0 and geronimo-tomcat-1.0
> >>> schemas have the inverseClassLoading attribute in them, but the generic
> >>> does not.  Is there a reason the generic does not?
> >
> > my stupidity? forgetfulness?? :-)
> >
> > I think a better question is whether we should turn inverseClassLoading
> > into an empty element in the class loading info group.
> >
> > I would support this, any other comments?
>
> I would agree, that from a consistency perspective, the
> inverseClassLoading would probably better as an element.
>
> >
> > thanks for checking up on this.
> >
> > david jencks
> >
> >>>
> >>> Jeff
>

Reply via email to