You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Grzegorz Kossakowski <gr...@tuffmail.com> on 2007/07/01 15:46:11 UTC
Versioning XML Schemas
Hi,
I would like to add some more documentation to cocoon-configurator-1.0.1.xsd[1] but I'm not sure what is our policy for versioning XML
schemas. AFAIK, 1.0.1 version has not been released yet so I can modify it freely, right? When it will be officially released? When
cocoon-spring-configurator is released?
What is more confusing we already have schema published at [2] without any mark that this is a snapshot version that is likely to be changed.
Do we have any policy on versioning xml schemas? Shouldn't we have a cocoon-configurator-1.0.1-SNAPSHOT.xsd published and rename it just
before we release cocoon-spring-cofigurator? This way we would always know when the version is locked down.
[1]
http://svn.apache.org/viewvc/cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/resources/org/apache/cocoon/spring/configurator/schema/cocoon-configurator-1.0.1.xsd?view=markup
[2] http://cocoon.apache.org/schema/configurator/cocoon-configurator-1.0.1.xsd
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Versioning XML Schemas
Posted by Reinhard Poetz <re...@apache.org>.
Joerg Heinicke wrote:
> You need to have the following in mind: Somebody wants to upgrade from
> Cocoon 2.2.3 to 2.2.4. In that step to one of the schemas an additional
> and optional attribute was added (like that case in Spring's AOP
> schema). In theory the jars would be a drop-in replacement. With
> increasing the version number of the schema you have to adapt all your
> references to the new version just to get your app working again. Or
> you'd need to hold all versions probably in use in your local XML
> catalogue or access them remotely. Since Spring has the schemas on the
> class path, they are just replaced with the jars. Despite the vagueness
> nobody actually needs to care about the schema version. For that reason
> I'd probably go with a constant number as long as it is backwards
> compatible. And it should be for on particular minor level.
I agree with Jörg.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Versioning XML Schemas
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Joerg Heinicke pisze:
> Grzegorz Kossakowski <gkossakowski <at> apache.org> writes:
>
>> I wonder what will be broken if someone sticks to 2.2.3 version of schema?
>
> It's actually not so easy to stick to a particular version.
> Quoting myself from the last mail:
>
>>> With increasing the version number of the schema you have to adapt all your
>>> references to the new version just to get your app working again. Or you'd
>>> need to hold all versions probably in use in your local XML catalogue or
>>> access them remotely.
>
> Since this approach does not scale the problem increases with each new schema
> version. I'd have no problem with somebody being forced to update the reference
> if he wants to use a new feature (the additional attribute). But the approach
> breaks drop-in replacement. You would at least need to update the XML catalogue.
> I don't consider remote access a serious alternative.
Thanks for repeating your message. Now I understand it completely and agree with your view.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Versioning XML Schemas
Posted by Joerg Heinicke <jo...@gmx.de>.
Grzegorz Kossakowski <gkossakowski <at> apache.org> writes:
> I wonder what will be broken if someone sticks to 2.2.3 version of schema?
It's actually not so easy to stick to a particular version.
Quoting myself from the last mail:
> > With increasing the version number of the schema you have to adapt all your
> > references to the new version just to get your app working again. Or you'd
> > need to hold all versions probably in use in your local XML catalogue or
> > access them remotely.
Since this approach does not scale the problem increases with each new schema
version. I'd have no problem with somebody being forced to update the reference
if he wants to use a new feature (the additional attribute). But the approach
breaks drop-in replacement. You would at least need to update the XML catalogue.
I don't consider remote access a serious alternative.
Joerg
Re: Versioning XML Schemas
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Joerg Heinicke pisze:
> No, they should be released and published - if it would only be for
> documentation. I would only not care so much about the cases when people
> retrieve the schema from remote, i.e. our web site. If they retrieve it
> locally it should be clear whether a particular version of a schema is
> released or not.
Ok.
> You need to have the following in mind: Somebody wants to upgrade from
> Cocoon 2.2.3 to 2.2.4. In that step to one of the schemas an additional
> and optional attribute was added (like that case in Spring's AOP
> schema). In theory the jars would be a drop-in replacement. With
> increasing the version number of the schema you have to adapt all your
> references to the new version just to get your app working again. Or
> you'd need to hold all versions probably in use in your local XML
> catalogue or access them remotely. Since Spring has the schemas on the
> class path, they are just replaced with the jars. Despite the vagueness
> nobody actually needs to care about the schema version. For that reason
> I'd probably go with a constant number as long as it is backwards
> compatible. And it should be for on particular minor level.
I wonder what will be broken if someone sticks to 2.2.3 version of schema? He will not be able to use new attribute but what will be rally
broken in that case?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Versioning XML Schemas
Posted by Joerg Heinicke <jo...@gmx.de>.
On 01.07.2007 17:18, Grzegorz Kossakowski wrote:
> I agree that renaming would involve too much tinkering but I don't get
> XML catalog solution fully. Do you want to say that publishing schema is
> useless because we should always use XML catalogs for receiving schemas?
No, they should be released and published - if it would only be for
documentation. I would only not care so much about the cases when people
retrieve the schema from remote, i.e. our web site. If they retrieve
it locally it should be clear whether a particular version of a schema
is released or not.
>> Spring handles it the same way [1]. They did not even increase the
>> version number on changes [2]. Important is probably the backwards
>> compatibility. In that particular case: An XML written against Spring
>> 2.0.2's AOP schema works in 2.0.3 as well despite the additional
>> attribute. No idea yet when it is better to force the user to update
>> his references.
>
> I really don't like such a solution. I really like to know that
> something released as x.y.z is never going to change. Otherwise, whole
> versioning seems vague for me.
You need to have the following in mind: Somebody wants to upgrade from
Cocoon 2.2.3 to 2.2.4. In that step to one of the schemas an additional
and optional attribute was added (like that case in Spring's AOP
schema). In theory the jars would be a drop-in replacement. With
increasing the version number of the schema you have to adapt all your
references to the new version just to get your app working again. Or
you'd need to hold all versions probably in use in your local XML
catalogue or access them remotely. Since Spring has the schemas on the
class path, they are just replaced with the jars. Despite the vagueness
nobody actually needs to care about the schema version. For that reason
I'd probably go with a constant number as long as it is backwards
compatible. And it should be for on particular minor level.
Joerg
Re: Versioning XML Schemas
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Joerg Heinicke pisze:
> Yes, I think it should be released with the block it contains it. I
> don't know if its versioning needs to follow its containing block
> though. Not every release of the block makes changes in the schema
> necessary. Despite steps in the versioning it will probably be easier
> though to follow the block's versioning.
Agreed.
> I'm against the SNAPSHOT suffix. A DTD or schema should never be
> retrieved from remote, but always from a local version (via xml
> catalogue or whatever). For somebody doing the latter it should be
> obvious whether it's released or not since he works with the released or
> the snapshot block. IMO it's just too much work to change all the
> references from the snapshot version to the release version if they
> differ in name.
I agree that renaming would involve too much tinkering but I don't get XML catalog solution fully. Do you want to say that publishing schema
is useless because we should always use XML catalogs for receiving schemas?
> Spring handles it the same way [1]. They did not even increase the
> version number on changes [2]. Important is probably the backwards
> compatibility. In that particular case: An XML written against Spring
> 2.0.2's AOP schema works in 2.0.3 as well despite the additional
> attribute. No idea yet when it is better to force the user to update his
> references.
I really don't like such a solution. I really like to know that something released as x.y.z is never going to change. Otherwise, whole
versioning seems vague for me.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Versioning XML Schemas
Posted by Joerg Heinicke <jo...@gmx.de>.
On 01.07.2007 15:46, Grzegorz Kossakowski wrote:
> I would like to add some more documentation to
> cocoon-configurator-1.0.1.xsd[1] but I'm not sure what is our policy for
> versioning XML schemas. AFAIK, 1.0.1 version has not been released yet
> so I can modify it freely, right? When it will be officially released?
> When cocoon-spring-configurator is released?
Yes, I think it should be released with the block it contains it. I
don't know if its versioning needs to follow its containing block
though. Not every release of the block makes changes in the schema
necessary. Despite steps in the versioning it will probably be easier
though to follow the block's versioning.
> What is more confusing we already have schema published at [2] without
> any mark that this is a snapshot version that is likely to be changed.
IMO that's no problem. See below ...
> Do we have any policy on versioning xml schemas? Shouldn't we have a
> cocoon-configurator-1.0.1-SNAPSHOT.xsd published and rename it just
> before we release cocoon-spring-cofigurator? This way we would always
> know when the version is locked down.
I'm against the SNAPSHOT suffix. A DTD or schema should never be
retrieved from remote, but always from a local version (via xml
catalogue or whatever). For somebody doing the latter it should be
obvious whether it's released or not since he works with the released or
the snapshot block. IMO it's just too much work to change all the
references from the snapshot version to the release version if they
differ in name.
Spring handles it the same way [1]. They did not even increase the
version number on changes [2]. Important is probably the backwards
compatibility. In that particular case: An XML written against Spring
2.0.2's AOP schema works in 2.0.3 as well despite the additional
attribute. No idea yet when it is better to force the user to update his
references.
Joerg
[1]
http://springframework.cvs.sourceforge.net/springframework/spring/src/org/springframework/beans/factory/xml/spring-beans-2.0.xsd
[2]
http://springframework.cvs.sourceforge.net/springframework/spring/src/org/springframework/aop/config/spring-aop-2.0.xsd?r1=1.5&r2=1.6