I also prefer to have the version explicitly defined in the description. It is up to the implementator to interpret the value and react accordingly.

One scenario (but not necessary often used) is forward "compatibility" where an BV 1.1 application run in an BV 1.0 implementation. With the version field in place, BV 1.0 implementor can check and handle the incompatibility easier and provided a more meaningful error message than taking an exception from the parser for any BV 1.1 syntax.

Just a thought.

Albert Lee.

On Tue, Jun 12, 2012 at 10:33 AM, Emmanuel Bernard <emmanuel@hibernate.org> wrote:
My gut feeling would be to add a version number so that user identify which versant hey expect their app to be compliant with.
It's always awkward later on to say that you are fine until version 1.7.

But I don't have a strong opinion.

On 10 juin 2012, at 18:16, Gunnar Morling wrote:

> Hi all,
>
> I'd be interested in your opinion on BVAL-295 [1].
>
> The background is that for BV 1.1 there will be some additions to the
> BV XML descriptors and thus the corresponding XSD files (e.g. new
> element "parameter-name-provider" in validation.xml).
>
> While implementing method validation within the RI, Hardy and I asked
> ourselves whether there should be an explicit version attribute in the
> descriptor root element (similar e.g. to JPA's persistence.xml):
>
> <validation-config
>    xmlns="http://jboss.org/xml/ns/javax/validation/configuration"
>    xmlns:xsi="..."
>    xsi:schemaLocation="..."
>    version="1.1">
>    ...
> </validation-config>
>
> This attribute would have a fixed value defined in the schema, which
> would allow to unambiguously identify the BV version for which an XML
> descriptor was written.
>
> As long as all schema changes are backwards compatible (meaning any
> files written against the 1.0 schemas are also valid against the new
> schemas), there is not really the need for such a version attribute,
> as always the new schema files could be used for validation. Things
> look different, though, in case of incompatible changes. Then the
> schema to validate against could be determined using the version
> attribute.
>
> Personally I feel we should add such an attribute once we really have
> an incompatible change (maybe in a future BV revision), but maybe
> there are other opinions?
>
> --Gunnar
>
> [1] https://hibernate.onjira.com/browse/BVAL-295
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev


_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev



--
Albert Lee.