Hi Everyone,
The core spec, at the very end of chapter 3, says:
SDO specifies minimum functionality for implementations. An SDO implementation MAY provide additional functionality so that valid results would be returned where this specification
would produce an error, provided that the functionality is a strict superset and all valid uses of the SDO specification operate correctly. [COR03000001]
I don’t believe this is actually a well formed RFC 2119 compliance statement: MAYs are supposed to be used to define alternative behavior such that you could write 2 tests, one of which would fail and one of which would succeed. Bryan, correct me if
I’m wrong, but I believe the MAY should be a “can”. Adding in Bryan’s proposed wording to this paragraph, gives us:
SDO specifies minimum functionality for implementations. An SDO implementation can provide additional functionality so that valid results would be returned where this specification
would produce an error, provided that the functionality is a strict superset and all valid uses of the SDO specification operate correctly. Specifically, incorrect input data can be detected at various points of processing: at the point when
the data is introduced via an API, when the data causes a subsequent processing error, when the data is serialized and potentially other points. The specification does not define when this sort of validation is done nor how the error notification is to be done.
An implementation is free to use an data validation approach that meets the needs of its users.
We should also remove section 4.1.14 Validation of Facets and Constraints.
The last sentences in the resolution regarding changes to the core spec to support facets also mention that whether or not to do validation is a language specific issue. These sentences should be removed.
Best Regards,
Ron