OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sdo message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: AW: [sdo] ISSUE 22: Proposal for Static SDOs (3).doc


Title: ISSUE 22: Proposal for Static SDOs (3).doc
OK, here is the next revision, with SdoOpenContentProperty as Blaise suggests.  I've also changed @SdoSeeAlso to @SdoSeePackage, which is a little clearer and also @SdoSeePackages sound better than @SdoSeeAlsos.
 
The following changes to the java spec should also be part of the proposal
 
1.  Change the first paragraph of 2.9.1 to
 

Implementations MUST accept interfaces as input to the JavaHelper.define() methods, creating SDO Types and Properties according to derivation rules given in chapter 3.   Implementations MAY allow POJO or generated classes to passed to JavaHelper.define().  The behavior in this case is vendor specific.

 

2.  Remove section 7.1 - this mapping is moved to chapter 3 (the proposal)

 

3.  Remove point 4 from 7.2 - generation is out-of-scope.

 

4.  Remove section 7.2.3 - this is simply a repeat of the proposal.

 

 

Best Regards,

Ron



Von: Blaise Doughan [mailto:blaise.doughan@oracle.com]
Gesendet: Mittwoch, 4. März 2009 15:07
An: Barack, Ron
Cc: sdo@lists.oasis-open.org
Betreff: Re: [sdo] ISSUE 22: Proposal for Static SDOs (3).doc

Hi Ron,

I feel we need to have the ability to have the SDO namespace for open content properties differ from the XML namespace.  How about the following?  The default for the xmlProperty property on the @SdoOpenContentProperty is a completely defaulted @SdoXmlProperty.

    @Retention(RetentionPolicy.RUNTIME)
    @Target({ElementType.TYPE, ElementType.PACKAGE})
    public @interface SdoOpenContentProperty {
        String name();
        String type() default "";
        boolean many() default false;
        boolean containment() default true;
        SdoXmlProperty xmlProperty() default @SdoXmlProperty();
    }

    @Retention(RetentionPolicy.RUNTIME)
    @Target(@Target({ElementType.METHOD,   ElementType.FIELD})             
    public @interface SdoXmlProperty {
        public enum XmlNodeType {ATTRIBUE,ELEMENT,DEFAULT};
        String name() default "";
        String uri() default "";
        XmlNodeType nodeType default XmlNodeType.DEFAULT;
    }

-Blaise

Barack, Ron wrote:
7C3EF93EEBC6EB4A8B4470853DE865667C80CE@dewdfe18.wdf.sap.corp type="cite">

<<Proposal for Static SDOs (3).doc>>
Hi Blaise,

Here is another revision, with most of the changes we talked about.

I considered giving @SdoOpenContentProperty a property of type @SdoXmlProperty, but I again ran into the problem of what the default value should be.

I really think it's the lesser evil to have the XmlNodeType enum as you suggest, and put this directly on @SdoOpenContentProperty.  The approach now loses the ability to give open content property an XML uri-name that does not correspond to the SDO uri-name.  Alternative would be to give OpenContentProperty the additional 2 properties…  I wish someone could explain why annotations don't allow null values as defaults or any sort of extension mechanism, but we won't be finxing that in SDO anyway.

Ron


--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Proposal for Static SDOs (3).doc



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]