Hi Pete, Yes, unfortunately the C++ 2.1 spec is inconsistent, and references to BigDecimal/BigInteger weren't all renamed to Decimal/Integer.
Sections 9.1 "SDO DataTypes", 10.3.3 "Mapping of XSD Built in Data Types", 11.1 "Mapping of SDO DataTypes to XSD Built in DataTypes", and the initial conversion table in 17 "DataType Converions" all list Integer/Decimal. However, in the SDO Abstract Type tables BigDecimal/BigInteger were overlooked in the renaming. And the enum types were left as BigDecimalType and BigIntegerType. So I believe the current binding of types to C++ enum values should be: commonj.sdo#Int --> Types::IntType commonj.sdo#Integer --> Types::BigIntegerType commonj.sdo#Decimal --> Types::BigDecimalType I don't believe the BigInteger/BigDecimal enums will renamed until the 3.0 spec. This hasn't proved to be as confusing as you might think for customers, as in C++ Integer/Decimal don't see much use, since their C++ language binding is undefined (usually just mapped to a string). Michael -----Original Message----- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Saturday, August 25, 2007 12:53 AM To: [email protected] Subject: Re: FW: [jira] Updated: (TUSCANY-1368) C++ SDO portability: class interface Type off-spec enum values Michael, I'm looking at this and have a question. I'm a little confused with the Int/IInteger/BigDecimal/Decimal changes. For instance, I see we would no longer define a type "commonj.sdo#BigDecimal" as this would be "commonj.sdo#Decimal" ? In the spec I have BigDecimal is still mentioned (actually as I type this I come to the conclusion that the spec is incosistent and the references to the SDO Abstract Type BigDecimal should probably not be there.). We do still have commonj.sdo#Integer as an SDO Type ... but there is no Type enum returned for this???? So if I create one I can't determine it's type using getTypeEnum??? Seems odd. Cheers, On 24/08/07, Michael Yoder <[EMAIL PROTECTED]> wrote: > Hi, > > I updated a patch for TUSCANY-1368. If someone could review and apply > it that would be great. > > Thanks, > > Michael > Rogue Wave Software, Inc. - [EMAIL PROTECTED] Software Developer - > HydraSDO > > -----Original Message----- > From: Michael Yoder (JIRA) [mailto:[EMAIL PROTECTED] > Sent: Friday, August 24, 2007 2:50 PM > To: [email protected] > Subject: [jira] Updated: (TUSCANY-1368) C++ SDO portability: class > interface Type off-spec enum values > > > [ > https://issues.apache.org/jira/browse/TUSCANY-1368?page=com.atlassian. > ji ra.plugin.system.issuetabpanels:all-tabpanel ] > > Michael Yoder updated TUSCANY-1368: > ----------------------------------- > > Attachment: TUSCANY-1368.txt > > This patch updates the Type.h interface to be spec compliant. Enum > values and public members not in the spec are removed from the > interface. Also related/ripple 2.1 spec changes: > - commonj.sdo#Int type added to factory (maps to enum Types::IntType) > - commonj.sdo#BigInteger type rennamed commonj.sdo#Integer (maps to > enum > Types::BigInteger) > - commonj.sdo#BigDecimal type renamed commonj.sdo#Decimal (maps to > enum > Types::BigDecimal) > - set/getInteger accessors renamed to set/getInt (map to > commonj.sdo#Int and xsd:int) > > > > > C++ SDO portability: class interface Type off-spec enum values > > -------------------------------------------------------------- > > > > Key: TUSCANY-1368 > > URL: > https://issues.apache.org/jira/browse/TUSCANY-1368 > > Project: Tuscany > > Issue Type: Improvement > > Components: C++ SDO, C++ Specification > > Affects Versions: Cpp-M3 > > Reporter: Michael Yoder > > Fix For: Cpp-Next > > > > Attachments: TUSCANY-1368.txt > > > > > > C++ SDO specification class interface Type has enum values > ("OpenDataObjectType", "num_type")which are not in the specification, > and are being used externally by SCA. It would seem that for SDO > portability these should be taken internal to SDO or submitted to the > spec committee. > > -----Original Message----- > > From: Pete Robbins [mailto:[EMAIL PROTECTED] > > Sent: Thursday, June 21, 2007 9:21 AM > > To: [email protected] > > Subject: Re: SDO spec compliance/portability: Type enums the > > num_type is just a convenient way to know the extent of an enum and > > is common > practice. I guess the OpenDataObjectType must be a Tuscany specific > extension to handle open types. I'd need to do some research to > determine if this is missing from the spec or can be removed. > > Please raise a Jira for the renaming of IntegerType. > > It may be useful to raise Jiras for all these issues so we can track > them. > > Cheers, > > On 21/06/07, Michael Yoder <[EMAIL PROTECTED]> wrote: > > > > > > Hi, > > > > > > The Tuscany SDO C++ class Type::Types enum has these values which > > > do > > > > not appear in the C++ 2.1 specification: > > > > > > - OpenDataObjectType > > > - num_type > > > > > > Would it be appropriate to file a bug to remove the additional > values? > > > Or alternatively a bug for them to be submitted to the spec > > > committee? > > > > > > In addition the 2.1 spec renamed the enum value "IntegerType" to > > > "IntType". > > > > > > Would it be appropriate to file a bug to have this value renamed? > > > > > > Thanks, > > > > > > Michael Yoder > > > Software Developer > > > Rogue Wave Software > > > > > > ------------------------------------------------------------------ > > > -- > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > > Pete > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Pete --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
