Hi all,
The EG is wondering if we should add more built-in constraints in the spec. The rational for built-in constraints is that they can be interpreted by non java frameworks via composing constraints and the metadata query API.

We are wondering if adding a string comparison constraint makes sense:
- @Like(value="%test%" case=INSENSITIVE)
Questions: which locale for INSENSITIVE?
=> this can be matched by DDL and JavaScripts

- @Pattern(regexp="")
Questions: which locale for INSENSITIVE?
=> extracting something from a Regexp usable by DDL (and to a certain extend JS) is hard. This might end up being an unusable back box.



Also some people are asking for @Email
While it makes sense and while I expect BV providers to provide such a constraint, should it be standardized?
My main concern is that the email RFC is quite lose. For examples, emails wo domain are valid: "emmanuel", "emmanuel@hibernate.org" are valid emails
In most cases, the former is not very interesting for applications.

What do you think?

Maybe you should ask if is necessary to define all this annotation in JSR 303? For example a kind of @Null or @NotNull annotation is too generic, from my point of view both of them belong to SDK. Now it seems that the same annotations are also defined in JSR 305 (http://jcp.org/en/jsr/detail?id=305). Is there some who coordinates it over various JSRs?

no I discussed to Bill and the @NotNull of 305 is not the @NotNull of 303. Semantically different.

Regexpes are mostly standardised on either Perl or POSIX, we could make this an annotation parameter.



Make this a parameter: allowLocal or however it's called in the RFC. AFAIR there are only local or non-local addresses.

i think it's better to have more annotation including those that are likely to have different definition/specification such as @Email, @CountryCode (just for example), and let the implementation to decide how to implement the default, and provide option to customize the rules. It's better than depend on vendor specific annotation or use regex patterhn.

I think that's a good idea.

Personally, I like the idea of creating annotations that describe the constraint in terms of what the data is, rather than apply generic annotations, such as regular expressions or simple patterns. So maybe 303 could avoid including a pattern type.

In terms of what you could include, I deal a lot with phone numbers and phone number validation and would like to see a validator for them.

But as you know there are hundreds of ways for phone number validation to work. For example, in some countries, certain area codes have different numbers of digits. You might want to validate to this level. And when you're building an application for a specific Locale, you don't want to ask for the country code each time, use some sort of default country of the user or installation.

None of this could really be done through DDL, but I think Javascript could potentially support an equal level of validation as a Java implementation.

When validation is important, though what ultimately is required is a specific data type e.g. com.example.PhoneNumber instead of java.lang.String. For e-mail, you use javax.mail.Address. I still haven't figured out how 303 cooperates well with user types.

You should have more, if and only if, they are well defined:
- @Email
- SEPA (the new european standard to pay): @IBAN & @BIC

I don't think a éTelephone is a good idea because it is not well defined

Hi Guys,

Thanks for all the good work on all this stuff. I'm about to introduce it to a big project I'm working on and reaction so far seems quite positive.

Given @Pattern you don't really need @Email or @Telephone or other similar validations because finding a regex implementing the standard is fairly easy.

I would like to see something like @Unique for collections. Perhaps this could take a comparitor as an argument and default to calling equals() if one isn't provided. @NotEmpty for strings and collections would be convenient, or perhaps this should be called @Required and have a wider scope than @NotNull.

And, although it could get really messy, a way of relating one field to another would be really nice. This might look something like this:

@LessThan("fieldB")
private int fieldA;

@Name("fieldB")
private int fieldB;

The problem here is that you can't do this in a nice way because there is no facility in java for attribute or method references. One solution, as shown here, is to provide an arbitary name for an attribute so that it can be referenced elsewhere -- this would survive refactoring (in Idea refactoring the attribute, fieldB, would also refactor the string references to it, but I don't know if this is true for eclipse).

Using something like this we could provide validation for one field in reference to another, which is, I think, quite a common requirement.

Bryan

Anything easily implemented using a regexp should probably be left to that purpose. Libraries can easily provide patterns, or their own additional annotations, and making them a part of the standard when there's no clear benefit seems questionable.

One thing I *do* think is so common that it should be included is a check verifying that the integer argument passes a Luhn algorithm test. It's not amenible to regexp-based implementation. A Luhn algorithm check when combined with a length test can verify a CCN as at least potentially valid, but the Luhn algorith is used for all sorts of other things, including all sorts of business registration numbers in various countries. It's not tough to implement and requires little code, but it's something that a one-liner @Luhn annotation would be very handy for. See: http://en.wikipedia.org/wiki/Luhn_algorithm. People are sure to ask for CCN validation, and this lets it be done with code that's also useful for all sorts of other things.

Another that would be useful would be an annotation to check a string against the Luhn algorithm after conversion to long by stripping all non-digit chars (by default) or an argument-specified list of "ignored" chars if one is given. Eg: @LuhnString(ignore="-_ ") .

(Any implementation should avoid string chopping in its implementation. It's easily properly implemented using purely arithmetic operations, though most examples show the string-chopping method. I'll post a simple method shortly.)

By contrast, @Email in particular seems unwise, IMO. There are just too many different addressing rules, and they're sure to continue changing over time. Let people choose how strict they want to be and what set of rules they wish to obey by using an appropriate regexp with pattern validation.

I'd like to see an annotations library that suppliements the standard with a more flexible, but non-standardized, set of commonly used annotations such as various strictness levels of email validation, credit card number validation, ISBNs, Australian Company Number, Australian Business Number, etc etc. Something that can be built and included class file by class file in a modular manner, so apps aren't burdened with shipping huge chunks of unnecessary code as would be the case if all these were part of the JSR.

I've been pretty happy with what Hibernate Validator (as JSR303) provides as shipped. The only validator classes I've had to add are ones for ABNs and ACNs (as the app is mostly for Australian use) and some Luhn-algorithm based checks for some app-specific values where I use the Luhn algorithm to detect typos and miscommunication of ID numbers.

This isn't beautiful, but it's better than string splitting implementations. Feel free to take it and make of it what you will.

I've been reviewing the HTML5 spec and they document validation strategy for Email and URL. They also note that they specifically violate prior definitions with good reason. This seems like the right spec to adhere to as web apps will be using input type="email" and type="url" binding to fields marked @Email and @URL in the validator.

http://www.whatwg.org/specs/web-apps/cu ... mail-state
"A valid e-mail address is a string that matches the ABNF production 1*( atext / "." ) "@" ldh-str 1*( "." ldh-str ) where atext is defined in RFC 5322 section 3.2.3, and ldh-str is defined in RFC 1034 section 3.5. [ABNF] [RFC5322] [RFC1034]

This requirement is a willful violation of RFC 5322, which defines a syntax for e-mail addresses that is simultaneously too strict (before the "@" character), too vague (after the "@" character), and too lax (allowing comments, white space characters, and quoted strings in manners unfamiliar to most users) to be of practical use here."

http://www.whatwg.org/specs/web-apps/cu ... #valid-url
"The term "URL" in this specification is used in a manner distinct from the precise technical meaning it is given in RFC 3986. Readers familiar with that RFC will find it easier to read this specification if they pretend the term "URL" as used herein is really called something else altogether. This is a willful violation of RFC 3986. [RFC3986]"

Hello,

Im a newcomer to Bean Validation, and would be happy to see more built-in annotations ! :-)

A list of ideas that come to mind :

- The date must be today (i tried combining @Past and @Future, ended up with failure, haha)
- With numbers we got the min and max, but i think the comparison is needed also, for example, the quantity for double must be > 0, could be 0.1, 0.001. Cannot use @Min in here.
- @Email, @Url, @Number : The suggestion from one of the replies here on being able to have several implementations (or even perhaps combine it using OR), or provide own's implementation would be cool.
- Reusing available complex annotation rules that's already defined somewhere else to avoid duplication @ValidationRule(type=my.package.MyClass, attribute="myAnnotatedProperty") ?

Thank you for your all hardworks !