[bv-dev] Changes in BV XML schemas

[Gunnar Morling]

Hi,

I had a look how the problem is solved in the descriptors of other EE specs.

There is a "version" attribute in the root element of almost all
descriptors (CDI's beans.xml being one exception). The versioning
issue is also shortly discussed in [1]:

"... [An] instance must specify the version of the corresponding
specification by using a version attribute. For example, servlet
Deployment Descriptor instances that must be processed with the
servlet 3.0 version must indicate the version within the version
attribute of the instance document, for example, "3.0". The Deployment
Descriptor processors use the version information to choose the
appropriate version of the schema document(s) to process the
Deployment Descriptor instances."

Based on that, I do think now that we also should add a "version"
attribute to our descriptors for consistency reasons, also if there
are only backwards-compatible changes as of BV 1.1. If there are
future revisions (>= BV 1.2), the attribute would also allow for
better error messages by BV 1.1 providers, as suggested by Albert.

If there are no objections, I'm going to add the attributes to the
descriptor schemas.

--Gunnar

[1] http://java.sun.com/xml/ns/javaee/


2012/6/12 Hardy Ferentschik <hardy at hibernate.org>:
>
> On Jun 12, 2012, at 10:38 PM, Gunnar Morling wrote:
>
>>> 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.
>
> RIght. It would require new releases of the 1.0 implementations to handle this version attribute.
> I doubt existing implementation would be able to handle it.
>
> --Hardy
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev