Need to define "implementation-defined", etc.

We need to be clear in our use of terms the allow "dimensions of variability" in implementations.

Previous standards, e.g., C or C++ programming languages, have made use of three levels:

1) implementation-defined behaviors (sometimes called application-defined). In this case the standard is allowing the implementation to chose the details of how a feature behaves. It might constrain it to a list of fixed choices ("is implementation-defined but shall be one of X, Y or Z") or it might be open-ended. The main requirement is that the implementation's choice must be documented ("defined") by the implementation. So saying something is "implementation-defined" is giving a documentation requirement on the application. Also, some standards (like C/C+) disallow extreme actions, like failing to compile or crashing. For example, in C/C+, sizeof(int) is implementation-defined. But that doesn't mean a C compiler can flag this statement as an error.

2) implementation-dependant (sometimes called unspecified). This is like implementation-defined but without the documentation requirement.

3) undefined. This is like implementation-dependent, but extreme behaviors are allowed. For example, dereferencing a null pointer is undefined C/C++. Why not just define this to be an error? It could be done. Java does that, for example. But generally undefined is used when the implementation cost or runtime cost of detecting the use undefined behaviors is unacceptable.

Some standards also have a concept of "locale-dependent" behaviors, which is really just a species of implementation-dependent.
I would recommend for ODF, that we adopt these definitions adapted from those used in ISO C++.