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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

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

2012/6/12 Albert Lee <allee8285(a)gmail.com&gt;: > 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(a)hibernate.org&gt; > 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(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev >> >> >> _______________________________________________ >> beanvalidation-dev mailing list >> beanvalidation-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > > > > > -- > Albert Lee. > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev