On Tue, Jun 12, 2012 at 3:38 PM, Gunnar Morling <gunnar@hibernate.org> wrote:

2012/6/12 Albert Lee <allee8285@gmail.com>:

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

What exactly do you mean by "description"?

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

Hmmm, I think this would work if there was a "version" attribute in
the BV 1.0 schema. But as there isn't, a BV 1.0 provider would stumble
upon the unknown attribute when validating a 1.1 descriptor.

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