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: Re: [sdo] Summarizing the SDO 3 changes


Thanks Blaise.

I think this means:

SDO-50 - No action/change.
SDO-101 - No Core or Java spec changes, which is all I'm concerning myself with at this point.
SDO-116 - I remember it this way as well. I wonder, however, if the spec needs to be (or has been) updated anywhere for this issue. Does anybody know?

Thanks,
Frank.

Inactive hide details for Blaise Doughan ---03/22/2010 10:45:53 AM---Hi Frank The following is what I remember out those three Blaise Doughan ---03/22/2010 10:45:53 AM---Hi Frank The following is what I remember out those three issues:


From:

Blaise Doughan <blaise.doughan@oracle.com>

To:

Frank Budinsky/Toronto/IBM@IBMCA

Cc:

sdo@lists.oasis-open.org

Date:

03/22/2010 10:45 AM

Subject:

Re: [sdo] Summarizing the SDO 3 changes





Hi Frank

The following is what I remember out those three issues:

SDO-50 - Specification does not explain behavior of createDataObject methods that have Type argument

I believe it was decided that there was enough description of what this operation means. At the very least in the java doc we have the following:

     /**
      * Returns a new {@link DataObject data object} contained by this object using the specified property,
      * which must be of {@link Property#isContainment containment type}.
      * The type of the created object is specified by the type argument,
      * which must be a compatible target for the specified property.
      * @param property a containment property of this object.
      * @param type the type of object to be created.
      * @return the created data object.
      * @see #createDataObject(int)
      */
     DataObject createDataObject(Property property, Type type);


SDO-101- ChangedDataObjectList needs to be defined

Can't remember the resolution to this one, it is categorized as "other languages", so probably a C++ or .Net issue?

SDO-116 - SDO types should have SDO DataObject Type as base

Didn't we decide that DataObject type would be a virtual super class? In that if you called the dataObject.Type.isInstance(...) on any DataObject the method would return true, but the DataObject type would not show up as a base type?


-Blaise


Frank Budinsky wrote:
      Hi Guys,

      As I mentioned during last weeks call, I'm starting to put together a summary of the changes in SDO 3. I'm starting by going through the list of "Closed" JIRA issues. In doing so, I noticed a few that say that they were "Fixed", but there is no indication of the resolution. These are the ones in that category:

      SDO-50
      SDO-101
      SDO-116

      Are these just cases where the resolution is incorrectly marked "Fixed"? That is, it should be "No Action"?

      Also there are a few issues, for example SDO-33, that are closed as duplicates of another issue which is still "Open". I suppose I can ignore them, unless the duplicate issue gets resolved, which would presumably describe the corresponding change, if it happens.

      Ron, you mentioned that the issues that we've been resolving since CD2 are being put into Resolved state (instead of Closed). Does that mean that I am guaranteed that there won't be any new issues added to the closed list, from now on? I'm hoping that I am safe to assume that the only issues that I will still need to look at after I'm finished with the Closed list are in (or going to be in) the "Resolved" list. Is that true?

      Thanks,
      Frank.



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