Hi Craig, >It sounds like you are thinking that you would like two different >attributes, one for "element-type" and another for "implementation- >type". Can you explain what the difference is? I only see the need >for one value here: the type that can be stored in the field, >element, key, or value.
Lets take the example of Collection. The element-type will be java.lang.Object (or the interface type when using interfaces). The element-implementation-type will be the actual PC types stored there. Notice that I said types (plural). The user wants to store more than one PC type in the same collection, so they declare it with element-type as Object. The point of then defining which PC types are valid is to allow the JDO impl to manage the persistence of this collection. The same applies to a field of type java.lang.Object (or an interface). The user wants to store some PC type there. In one object it may be a PC type A. In another object it may be a PC type B. The implementation-type (or field-type in your case) will be the possible types that can be stored. In the case of interfaces, we clearly have the "implements" information to provide this implementation definition, but the benefit of adding an attribute to each field/collection/array etc is that the user can then restrict each field to a subset of the possible implementations. The TCK, as you currently have it, only typically has one "implementation type". The real world has many implementation types and the user needs the flexibility to select from them. Now that I've mentioned that I have in mind plurals, maybe it would be better to use XML properly and add a subelement to store the names of these PC implementation types. It would work with an attribute, storing a comma-separated list of names, but then XML allows it to be done better than that. Hope thats clearer. -- Andy
