On 17/12/2014 16:34, Matthew White wrote:
> Hello;
>
> I would vote for the definitive option in all cases; having a specification that has vague or unclear isn't helpful for
> anybody in the long-term.
Thanks. I am in the process in updating my proposals so that they change only the "classic" API (since this is where the
compatibility issues arise) but not the new "simplified API" (which can remain more tightly-defined).
> Even in the cases where there is a implicit conclusion it doesn't help to spell it out - 'For
> the avoidance of doubt'
If there's anywhere in particularly you think this is needed (both now and as we work on JMS 2.1), then please do let me
know.
> On a similar note is there an assumption in the JCP process which of the reference implementation, compliance tests,
> written specification or API JavaDoc has precedence in the case of conflict?
As I understand it, the reference specification doesn't define the spec; it is there to demonstrate that the spec is
capable of being implemented.
The "specification" consists of the pdf together with the javadocs. If the pdf document conflicts with the javadocs, or
if two parts of the pdf conflict with each other, then this is a bug which the maintenance lead needs to look at. How
this would be resolved would depend on exactly what the conflict was, rather than one part of the spec automatically
taking precedence over another. Sometimes the intent is relatively obvious. However significant errors or conflicts in
the spec which cause difficulties for implementers and which can't wait for the next revision of the spec needs to be
resolved with an errata, led by the maintenance lead in conjunction with the community. Obviously, we are discussing
errors like that right now. They are to be expected after such a major revision.
The compliance tests are not themselves part of the spec. They are based on the spec and can only require behaviour that
is defined in the spec. If the spec and compliance tests conflict, the test can be challenged.
Nigel