Re: [sdo] SDO Java Spec Comments

[Blaise Doughan <blaise.doughan@oracle.com>]

As promised here are my comments on the annotation section of the SDO Java spec:

Section 3.4 Default Mapping between SDO Types and Static SDOs

• For this table (and others in section 3) shouldn't "Java" be on the left and "SDO" be on the right, since we are talking about deriving SDO metadata from Java metadata?
  

Section 3.5 Generation of SDO Types from Static SDOs

• For Java interfaces the SDO uri is derived as uri = “urn:java:”+[packageName], but for Java enums the uri is derived as uri = [packageName], shouldn't these be the same? 
• Strictly I supposed: "If a property has a get method but no set method, it generates an SDO property with readOnly = true." , should be "If a property has a get/is method but no set method, it generates an SDO property with readOnly = true."
• The relationship between javaType/propType is not discussed when javaType is not a static SDO type
• Should "If [javaType] is a static SDO, then [propType] is the SDO type returned from JavaHelper.define([javaType]).", be "If [javaType] is a static SDO, then [propType] is the SDO type returned from JavaHelper.getType[javaType])."

Section 3.6.1 @SdoType

• abstractType and aliasNames are missing from the table

Section 3.6.2 @SdoOpenContentProperty

• When SdoOpenContentProperty is specified on the package level how do you specify the type?
  

Section 3.6.3 @SdoProperty

• Should there be an option to specify the property type as a class?  Especially for List properties this would be a nice option instead of having to create that special string that combines type uri and name.

Section 3.6.7 @SdoXmlType

• What is the format of the xsdType parameter?  Is it a QName for local name for the type?
  

3.8 Example of Static SDO interfaces

• We should probably avoid any specific vendor package names com.sap.xml.datatype.GregorianCalendar getOrderDate();

-Blaise

Blaise Doughan wrote:

4AD8B95B.6000402@oracle.com" type="cite">Below are some initial comments on the SDO Java spec.

General

• We should use generics when the return type is List.  I believe we can change "List /*DataObject*/ getChangedDataObjects();" to "List<DataObject> getChangedDataObjects();" without any consequence.
  

Section 2.1.2 - Open Content DataObject Properties

• "the property type is derived from the Java class of the value, or List of values, being set. If the value is an instance of DataObject, a Java Implementation of SDO MUST create the property using the type of the DataObject (returned by DataObject.getType()). [JAV02010201]."
  The above compliance point does not cover what happens if the List of values contains objects from the same inheritance hierarchy.  Is the type based on DataObject.getType() from the first item in the list, or the lowest super class common to all DataObjects in the list.

Section 2.1.4 - DataObject Accessor Exceptions

• DataObject accessor exceptions are all standard Java runtime exceptions so programs do not need try/catch blocks to program with the DataObject interface. The content of the exception SHOULD BE a String that describes the problem.
  Why do the exceptions need to be standard runtime exceptions, why is any subclass of RuntimeException not acceptible?

Section 2.9.1 - JavaHelper Interface

• "Implementation complience is based on the the ability to define types from any interface meeting the requirements set out in Chapter 3"
• "the" occurs twice in a row

Section 2.19.4 Implementation Specific HelperContextFactory

• SDO.getHelperContextFactory(“org,example.vendor.HCFImpl”);
  There is a comma that should be a period

-Blaise