A few of comments on the current spec:

- The spec says "Message parameters are string literals enclosed in braces." but it doesn't specify valid characters for the parameter. The Hibernate implementation in 4.0.0.Beta1 uses the following pattern "(\\{[\\w\\.]+\\})", which doesn't recognize some valid ResourceBundle keys (e.g. the '-' character). The spec should define what characters are valid and what aren't.
- MessageInterpolator should work on a MessageTemplate object rather than a String. The current form is too error prone and makes Interpolator stacks duplicate work (e.g. every Interpolator needs to parse the message again, trying to find the parameters it should substitute). This interface would work:

public interface MessageTemplate {
public void set(String parameter, String value);
public String getTemplate(); // original template
public String getMessage(); // template with set parameters substituted
public Iterator<String> parameters();
}

- There should be a standard way to access the validated value as a message parameter. IME many validation messages contain the invalid value.

Other than that the spec is great.

The spec does not say anything on permitted characters, so all are permitted, I think the RI has fixed this issue (not sure).

MessageTemplate:
That's an interesting idea but it limits what I initially envisioned. In my mind, an environment could entirely rewrite the interpolation rules including the {} notation to match the "convention" of such environment. Let me think a bit about it.

Providing access to the value
What are you going to do with the value? Remember, that's an Object, not a String or anything else.
Anyway, its available in MessageInterpolator.Context.getValidatedValue()
A custom interpolator can make use of it and burn itself :)

The apps I work on usually have error messages like: "Date yyyy-mm-dd is not a working day". This is useful because the user can see what the app got, instead of what he typed (so if there's some conversion and translation going he can see something weird going on).
I ended up writing a custom interpolator to do this (actually we support arbitrary EL in the message parameter, "this" binds to getValidatedValue()), but IME it's a common requirement, so it's a good candidate to be in the spec.

The ResourceBundleMessageInterpolator has indeed still the limitation to only accept word characters and '.'
I created HV-186 for that.
Maybe a clear definition what characters are permitted would reduce problems/errors with message parsing/interpolation?

--Hardy