Hi Jörg, It seems we have these alternatives:
[ ] 1. Remove attribute dependent-element from element collection and element array and use attribute dependent on element field to describe this.
[ ] 2. Disallow use of attribute dependent on element field for collection and array type fields (throw an exception if the user specifies a value for the attribute dependent).
[ ] 3. Allow use of attribute dependent-element in element collection and element array and allow use of attribute dependent on element field but require that they not both be specified.
[ ] 4. Allow use of attribute dependent-element in element collection and element array and allow use of attribute dependent on element field but require that if they are both specified, they be the same value.
[ ] 5. Ignore use of attribute dependent on element field for collection and array type fields.
If you have a strong preference please vote. My favorite is2. This makes it clear where the dependency needs to be declared. The only issue that I can see is for object databases where the field level dependent actually does refer to the collection itself. But I cannot see that there is a need to allow non-dependent collection instances of dependent references.
Craig On Jan 27, 2006, at 7:30 AM, Jörg von Frantzius wrote:
Please see my comments below on how JPOX will treat dependent vs. element-dependent on collection fields. Please reply if you have objections!Craig L Russell schrieb:JPOX will ignore any "dependent" attribute setting on Collection fields, so only the "element-dependent" attribute will be of meaning for Collection fields.Hi Jörg, On Nov 3, 2005, at 1:49 AM, Jörg von Frantzius wrote:Hello,the specification currently is somewhat confusing where it defines the meta-data attributes "dependent" and "element- dependent". Concerning "dependent" it says:"The dependent attribute indicates that the field contains a reference that is to be deletedThe reference is the object that is referenced by the field. I'll try to clarify this in the spec.from the datastore if the referring instance in which the field isdeclared is deleted, or if the referring field is nullified."Now does that mean that really the *reference* is to be deleted (which seems kinda natural to me), or rather the object being referred to? Probably the latter?Yes.For collection fields, there is the additional "dependent- element" attribute of the "collection" tag. Wouldn't it be enough to have "dependent" on the field level?We try to make the field metadata refer to behavior of the field itself, and put the behavior of multi-valued field types (array, collection, map) in separate metadata to better match the semantics of Collection versus Element.We could make it illegal to specify dependent on field types of array, collection, and map...Or what does it mean if the user specifies 'dependent="false"' with nested 'element-dependent="true"', or vice-versa?See above.Experts, any opinion on this subject? CraigThanks for any explanations, Jörg --__________________________________________________________ Dipl.-Inf. Jörg von Frantzius | artnology GmbH | Milastr. 4 Tel +49 (0)30 4435 099 26 | 10437 Berlin Fax +49 (0)30 4435 099 99 | http://www.artnology.com _______________________________|__________________________Craig RussellArchitect, Sun Java Enterprise System http://java.sun.com/products/ jdo408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!-- __________________________________________________________ Dipl.-Inf. Jörg von Frantzius | artnology GmbH | Milastr. 4 Tel +49 (0)30 4435 099 26 | 10437 Berlin Fax +49 (0)30 4435 099 99 | http://www.artnology.com _______________________________|__________________________
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
