[infinispan-dev] XML namespaces in configuration files

[Vladimir Blagojevic]

Hey,
On 2010-05-17, at 5:43 AM, Manik Surtani wrote:

>> 
>> Backward compatibility
>> 
>> Maintain minor version configuration file backward compatibility. We have to process any previous version configuration file from the same minor version. For example, Infinispan release 4.2 should process configuration file produced for version 4.1 without any configuration file changes or any other adjustments. For configuration options present in 4.2, but not in 4.1 assume default values. However, Infinispan  version 5.0 is not required to process configuration files from previous major versions, i.e 4.0...4.x. 
> 
> I think we should still support this.  (5.0 processing 4.x config files)

I'd say yes, unless the cost is prohibitively expensive in terms of hours needed to develop support for such backward compatibility (here we would definitely need xyz40, xyz50 beans), code maintenance, support for HTML configuration reference creation, testing etc etc. If you do not mind I'd like to push this to 5.0 if we decide such a feature is a must.


> 
>> Forward compatibility
>> 
>> Not supported. We do not process any forward version configuration file. For example, Infinispan release 4.1, given configuration file input from any succeeding versions (i.e 4.2...4.x, 5.x) would simply fail outright with proper error message.
> 
> Yes.
> 
>> However, that said, even forward compatibility could be supported to an extent - as long as properties and elements from forward versions are not used in configuration file. As soon as at least one element or a property from a forward version file is used - xml schema validation will fail. If schema validation is turned off configuration file can be processed.
> 
> Hmm... I suppose... 
> 
>> Now, if you agree with these requirements we are already good to go! We are allowed to introduce additional elements and attributes between minor version. We cannot remove existing elements and attributes. Finally, there can not be any structural changes in terms of already existing elements. For example, we can not reparent existing element to another node, i.e say locking element instead of being a child of <default> or <namedCache> suddenly becomes a child of transaction element.
> 
> Yes, makes sense.

I'll add a paragraph to XML configuration dev wiki to make sure no one breaks these guidelines.