Re: [sdo] ISSUES 62 and 159: Proposal

[Bryan Aupperle <aupperle@us.ibm.com>]

Your comment about COR03000001 is correct.
 This should not be a normative statement.  Unless a specification
prohibits a behavior, an implementations are allowed to extend the behavior
mandated by the specification.  I would word your second sentence
as:
An SDO implementation can provide additional
functionality so that valid results would be returned where this specification
would indicate an error, provided raising an error is not specifically
indicated by a normative statement, the additional functionality is a strict
superset and all valid uses of the SDO specification operate correctly.

I.e. we do not want to allow an implementation
to not raise an error when there is a MUST statement that says one is to
be raised.

Bryan Aupperle, Ph.D.
STSM, WebSphere Enterprise Platform Software Solution Architect

Research Triangle Park,  NC 
+1 919-254-7508 (T/L 444-7508)
Internet Address: aupperle@us.ibm.com

From:	"Barack, Ron" <ron.barack@sap.com>
To:	"sdo@lists.oasis-open.org" <sdo@lists.oasis-open.org>
Date:	06/08/2010 01:25 PM
Subject:	[sdo] ISSUES 62 and 159: Proposal

---

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