deployment description, i.e. validation.xml<br><br><br><div class="gmail_quote">On Tue, Jun 12, 2012 at 3:38 PM, Gunnar Morling <span dir="ltr"><<a href="mailto:gunnar@hibernate.org" target="_blank">gunnar@hibernate.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2012/6/12 Albert Lee <<a href="mailto:allee8285@gmail.com">allee8285@gmail.com</a>>:<br>
<div class="im">> I also prefer to have the version explicitly defined in the description. It<br>
> is up to the implementator to interpret the value and react accordingly.<br>
<br>
</div>What exactly do you mean by "description"?<br>
<div class="im"><br>
><br>
> One scenario (but not necessary often used) is forward "compatibility" where<br>
> an BV 1.1 application run in an BV 1.0 implementation. With the version<br>
> field in place, BV 1.0 implementor can check and handle the incompatibility<br>
> easier and provided a more meaningful error message than taking an exception<br>
> from the parser for any BV 1.1 syntax.<br>
<br>
</div>Hmmm, I think this would work if there was a "version" attribute in<br>
the BV 1.0 schema. But as there isn't, a BV 1.0 provider would stumble<br>
upon the unknown attribute when validating a 1.1 descriptor.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Just a thought.<br>
><br>
> Albert Lee.<br>
><br>
><br>
> On Tue, Jun 12, 2012 at 10:33 AM, Emmanuel Bernard <<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>><br>
> wrote:<br>
>><br>
>> My gut feeling would be to add a version number so that user identify<br>
>> which versant hey expect their app to be compliant with.<br>
>> It's always awkward later on to say that you are fine until version 1.7.<br>
>><br>
>> But I don't have a strong opinion.<br>
>><br>
>> On 10 juin 2012, at 18:16, Gunnar Morling wrote:<br>
>><br>
>> > Hi all,<br>
>> ><br>
>> > I'd be interested in your opinion on BVAL-295 [1].<br>
>> ><br>
>> > The background is that for BV 1.1 there will be some additions to the<br>
>> > BV XML descriptors and thus the corresponding XSD files (e.g. new<br>
>> > element "parameter-name-provider" in validation.xml).<br>
>> ><br>
>> > While implementing method validation within the RI, Hardy and I asked<br>
>> > ourselves whether there should be an explicit version attribute in the<br>
>> > descriptor root element (similar e.g. to JPA's persistence.xml):<br>
>> ><br>
>> > <validation-config<br>
>> > xmlns="<a href="http://jboss.org/xml/ns/javax/validation/configuration" target="_blank">http://jboss.org/xml/ns/javax/validation/configuration</a>"<br>
>> > xmlns:xsi="..."<br>
>> > xsi:schemaLocation="..."<br>
>> > version="1.1"><br>
>> > ...<br>
>> > </validation-config><br>
>> ><br>
>> > This attribute would have a fixed value defined in the schema, which<br>
>> > would allow to unambiguously identify the BV version for which an XML<br>
>> > descriptor was written.<br>
>> ><br>
>> > As long as all schema changes are backwards compatible (meaning any<br>
>> > files written against the 1.0 schemas are also valid against the new<br>
>> > schemas), there is not really the need for such a version attribute,<br>
>> > as always the new schema files could be used for validation. Things<br>
>> > look different, though, in case of incompatible changes. Then the<br>
>> > schema to validate against could be determined using the version<br>
>> > attribute.<br>
>> ><br>
>> > Personally I feel we should add such an attribute once we really have<br>
>> > an incompatible change (maybe in a future BV revision), but maybe<br>
>> > there are other opinions?<br>
>> ><br>
>> > --Gunnar<br>
>> ><br>
>> > [1] <a href="https://hibernate.onjira.com/browse/BVAL-295" target="_blank">https://hibernate.onjira.com/browse/BVAL-295</a><br>
>> > _______________________________________________<br>
>> > beanvalidation-dev mailing list<br>
>> > <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
>> > <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> beanvalidation-dev mailing list<br>
>> <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Albert Lee.<br>
><br>
> _______________________________________________<br>
> beanvalidation-dev mailing list<br>
> <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
><br>
<br>
_______________________________________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Albert Lee.<br>