AW: [sdo] SDO Facets and Java Spec as Word Document

I want to send out a mail with explict questions for consideration in next week's call.

To summarize Tuesday's discussion: it seems we need an @SdoFacets annotation in addition to the standard JSR-303 annotations. This is necessary because we need a single, concrete annotation that can be used as the value of a member in the @SdoDataType annotation. Having @SdoFacets has the additional advantage of creating an easy and 1:1 mapping with the facets that are proposed for the SDO core spec, and, by extension, with Schema.

Question 1: should we allow @SdoFacets to be used on properties as well as on @SdoDataType?

Pro: @SdoFacets will be very convenient when generating static SDOs from XSDs, in the representation of anonymous types. It is also much richer than the currently defined JSR-303 annotations. For instance, JSR-303 cannot specify min and max values for dates (only past or future). So there's XML fidelity for generated static SDOs.

Con: It introduces redundency into the API. For example, users can specify the min value for an integer using @Min or @SdoFacets(minInclusive).

If we answer "no" to question 1, then we are sort of done. If we answer "yes" then the next question is:

Question 2: should @SdoFacets be a JSR-303 complient annotation?

Pro: This would allow static SDOs that use this annotation to be validated using a JSR-303 complient engine. It also opens the door to having an SDO-aware JSR-303 engine that could include the restrictions on the registered simple type, if any. I could even image using such an SDO aware engine on dynamic DataObjects. This is a very appealing direction to go wrt validation: it brings us in line with other emerging standards, and allows us to delegate the problem rather than solving it ourselves.

Con: We would have to be very sure that the validation matches the validation of the corresponding XML document. To achieve this 100% could get tricky. Relying on JSR-303 to solve validation is also not 100% secure, as JSR-303 isn't (yet?) very widely accepted.

Question 3: if @SdoFacets is a JSR-303 annotation, who should implement the constraint validators? To be clear here, a JSR-303 annotation looks like this

@Constraint(validatedBy={Validator1.class, Validator2.class})

public @interface MyFacet {}

In order for this to compile, Validator1 and Validator2 must be on the build's classpath. If @SdoFacets is delivered in the API, and the API is going to compile on it's own, then Validator1 and Validator2 must also be delivered in the API.

JSR-303 also allows an annotation's validators to be overridden using an XML deployment descriptor. The validation engine reads the DD from META-INF.

Option 1: We provide validator classes as part of the API.

Pro: Validation logic is clear and standard. No configuration for the user. There is actually very little here that is implementation dependent or optimizable from an implementation. The validator API is really only for very low level validation, the method takes only the primitive value and the annotation as parameters. I don't expect the implementations will vary very much in the way the implement, eg, a minInclusive test.

Con: This may be too much implementation to try to push through the standardization process.

Option 2: We do not provide a validator. The implementation can provide a deployment descriptor, and this could be overridden by the user.

Pro: Nothing to do in the spec. Implementations are free to implement this functionality however they want.

Con: I'm not sure how it's resolved when both the user and the implementation (and who else?) provides a JSR-303 deployment descriptor. If the code in the validator *is* vendor specific, then this will lead to problems in multivendor scenarios... and of course we'll have the usual OSGi problems regarding resource visibility.

Best Regards,

Ron

sdo message