Issues for Currency Revision Task Force mailing list

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 2265: clarification on how the "#" is used in the money formatter
Issue 2266: Clairfy comparisons of two CBO::Ddecimal values on equality
Issue 2267: Clarify on comparison methods of the calculato
Issue 2268: Change text description of behavior of ROUND_FLOOR and ROUND_CEILING
Issue 2269: Add text for formatter that the format string will be used for parsing
Issue 2270: Add idl and text to describe the getAllExchangeRates method
Issue 2271: Change double to short for internal precision
Issue 2272: The idl for CBO::DTime needs the method: long getYear()
Issue 2273: Add text for DTime and DDecimal from CBO submission into Currency spec.
Issue 2363: StateID Exception
Issue 2365: Description of Exception handling semantics
Issue 2366: Extend ExceptionType enumerations
Issue 2367: Text indicating that vendors shall provide default values
Issue 2368: Clearer information describing different rounding types is needed
Issue 2369: Exchange rates need to be date based.
Issue 2379: vendor implementations can implement only parts and interoperate-Statement
Issue 2380: describe how the individual components should be accessed
Issue 2381: Propose modification to the init method of CurrencyValue
Issue 2382: missing description on the init method for CurrencyValue
Issue 2383: Missing details on preconditions on the Currency interface as a whole
Issue 2384: More clarification on the semantics of string arguements for CurrencyValue
Issue 2385: Legal value ranges for numerics in CurrencyValue init should be discussed
Issue 2386: Typos in CurrencyValue section
Issue 2387: Add description of isCurrency Active
Issue 2388: Add mechanism to create Money instances for moneyValue
Issue 2389: MoneyValue init interface need information
Issue 2390: exception semantics for MoneyValue
Issue 2391: IDL Changes to support date ranges on ExchangeRateValue
Issue 2392: ExchangeRateValue init interface need information
Issue 2393: Missing details on preconditions on the ExchangeRateValue
Issue 2394: Legal value ranges for numerics in ExchangeRateValue should be discussed
Issue 2395: Clarification on whether stateID manages session or state access
Issue 2396: Correct issues with CosObjectIdentity::IdentifiableObject in StateIDManage
Issue 2397: Change the name of getStateIdentifier to issueStateIdentifier
Issue 2398: Add validity checkign for StateIdentifier
Issue 2399: what values are used to determine if a currency exists in CurrencyBook
Issue 2400: Clarify the areEquivelent interface of the CurrencyBook
Issue 2401: Change get Currency to retrieveCurrency
Issue 2402: Correct Currency create method
Issue 2403: Correct interface symantics for createExchangeRate
Issue 2404: Change the name of addExchangeRate to insertExchangeRate
Issue 2405: Modify and specify the behavior of the insertExchangeRate interface
Issue 2406: removeExchangeRate() interface issue
Issue 2407: Proposed interface changes to ExchangeRateManager
Issue 2408: Clarify MoneyFormatter use of the # symbol
Issue 2409: Clarify legal values for the MoneyFormatter format strings
Issue 2410: Clarify contradiction betw setFormatByLocale & setFormattingString
Issue 2411: Clarify exceptions for setFormattingString in MoneyFormatter
Issue 2412: Typo on SetPatternMnemonicSymbol name
Issue 2413: Interface changes for MoneyFormatter pattern handling
Issue 2414: Create mechanism to modify what negative prefix is for formatting string
Issue 2415: Clarify on comparison methods of the MoneyCalculator
Issue 2416: Add interfaces for internal precision on MoneyCalculator
Issue 2417: Fix omitted precondition for MoneyCalculator
Issue 2418: Improve DTime exception handling
Issue 2419: Corrections to the equals/setEquals interfaces of DTime
Issue 2420: : Change name of interface to CBO::Decima
Issue 2421: Clarify the equality method of DDecimal
Issue 2422: Add interfaces to DDecimal
Issue 2423: : Change name of interface to CBO::Time
Issue 2424: support to set precision to something other than milliseconds
Issue 2425: Clarification required on setYear of the DTime interface
Issue 2426: Add interface to DTime
Issue 2427: Add interfaces to DTime properly handle the DAmountOfTime difference inter
Issue 2428: Change name of CBO::DAmountOfTime interface to CBO::AmountOfTime
Issue 2429: Support millisecond precision in DAmountOfTime
Issue 2430: Improve text in specification of of DAmountOfTime
Issue 2775: Supplied Data for ISO Locales in MoneyFormatter needs to be discussed
Issue 2776: Remove dependence on a specific version of the ISO 4217 standard
Issue 2778: Add ability to clone Money
Issue 2779: Add clarification on formatting string in MoneyFormatter
Issue 2780: Changing RoundType.DONT_ROUND
Issue 2781: Place maximums on wstrings for interoperability
Issue 2782: Remove Dependence in FBCCurrency of CBO::DTime
Issue 2783: Remove Depedence in FBCCurrency of CBO::DDecimal
Issue 2886: Value types need state

Issue 2265: clarification on how the "#" is used in the money formatter (currency-rtf)

Summary: Need more clarification on how the "#" is used in the money formatter -
  i.e. if the digit is zero and doesn"t contribute to the value, 0 will not show.
 

In section 2.3.12.1, in the default symbol box for the meaning for symbol # add the following text:  
Zero does not appear in formatted output where its inclusion would otherwise add no information, e.g. "GBP 012.34" vs. "GBP 12.34"

Summary: Clairfy comparisons of two CBO::Ddecimal values on equality (i.e. 2.0 equal to 2.000) 
 regardless of scale factor
 

 received issue

Summary: Clarify on comparison methods of the calculator that no rounding etc. would take place before the 
 comparison,  it would be the raw numbers in each money instance that is compared.
 

Summary: Change text description of behavior of ROUND_FLOOR and ROUND_CEILING.  The descriptions are mixed between the two.  
 

Summary: Add text for formatter that the format string will be used for parsing.  
 Clarify the formatting string and how it is used.  
 This way the parser routine will use:  M##,###.00 to help it parse:  RUR10,00  
 This also means the radix character was set to: "," and the grouping symbol was set to: "."  
 Show an example to distinguish between what the pattern gives you and what the actually settings of the characters give you.
 

Summary: Add idl and text to describe the getAllExchangeRates method
 

Summary: Change double to short for internal precision
 

Summary: The idl for CBO::DTime needs the method:  long getYear()
 

Summary: Now that the CBO submission no longer exists, we need to add the text for DTime and DDecimal
 from the CBO submission into the Currency Spec.
 

Summary: Need exceptions for stateId indicating that one was never created from the
 StateIdManager for all methods that take stateId.
 
 

Summary: Text needs to be added to describe what causes an exception to be raised
 for a given interface, when the semantics/preconditions for the interface
 have been violated (vs. exceptions specific to a vendor
 ’s implementation).
 e.g. Money.[gs]etValue(), MoneyFormatter.[gs]etFormattingString(), etc. It
 appears that most every interface raises (FbcException), but quite often
 the text which describes which exceptions can be raised, in terms of
 ExceptionType and under what conditions the exception is raised/thrown, has
 not been detailed. A detailed pass through the entire FbcCurrency spec
 should be conducted with attention paid to each interface and its exception
 generating details.
 
 
 

Summary: Need to add some additional enumerations to the ExceptionType enumeration.
 Some of the suggestions are the following : INVALID_VALUE,
 INVALID_STATE_IDENTIFIER, INVALID_DATE_RANGE, INVALID_CONVERSION_FACTOR,
 INVALID_STRING (when a provided string is empty or contains only white
 space), UNINITIALIZED_DATA, DATE_RANGE_FRAGMENTATION (when adding an
 exchange rate whose effective window in time would fragment existing
 exchange rates), INVALID_MULTIPLIER, INVALID_DIVISOR, STATE_IDS_EXHAUSTED.
 (Our implementation plan is such that INVALID_ROUNDING_DIGIT,
 INVALID_MULTIPLIER, etc. should really be discarded in favor of using
 INVALID_VALUE. Where an explicit value has already been specified in the
 submission (e.g. INVALID_ROUNDING_DIGIT) we will use it but hope for our
 recommendation to be heeded. For exception types that are necessary but
 were not included in the adopted submission, we will add our own (e.g.
 INVALID_STATE_IDENTIFIER, INVALID_VALUE) and use whenever necessary.
 
 

Summary: .A Currency implementation should probably provide default values on behalf
 of a given valid stateIdentifier (i.e. MoneyCalculator.roundingType,
 MoneyCalculator.roundingDigit, MoneyCalculator.conversionType,
 MoneyCalculator.internalPrecision, MoneyFormatter.radixSymbol,
 MoneyFormatter.groupingSymbol, MoneyFormatter.negativePrefixSymbol,
 MoneyFormatter.inputMultiplier, MoneyFormatter.outputDivisor, locale,
 etc.). The standard should state that a vendor’s responsibility is to
 provide defaults, but leave the choice of the actual default values to the
 vendor.  An interface allowing state to be set back to defaults should be
 considered.
 
 

Summary: RoundingType.ROUND_DOWN – The textual description needs to be far more
 explicit and/or include examples for both positive and negative numbers.
 Round toward zero? Is the rounding digit truly ignored?  e.g. Let the
 internal precision be two.
 

Discussion: RoundingType.ROUND_DOWN - The textual description needs to be far more explicit and/or include examples for both positive and negative numbers. Round toward zero? Is the rounding digit truly ignored? e.g. Let the internal precision be two. Thus: ROUND_DOWN(-2.135) yields -2.13 ? ROUND_DOWN(2.135) yields 2.13 ? RoundingType.ROUND_UP - The textual description needs to be far more explicit and/or include examples for both positive and negative numbers. Round away from zero? e.g. Let the rounding digit be 5, with an internal precision of 2. Thus: ROUND_UP(-2.135) yields -2.14 ? ROUND_UP(2.135) yields 2.14 ? RoundingType.ROUND_FLOOR - The textual description needs to be far more explicit and/or include examples for both positive and negative numbers. Round toward negative infinity? e.g. Let the rounding digit be 5, with an internal precision of 2. Thus: ROUND_FLOOR(-2.135) yields -2.14 ? ROUND_FLOOR(2.135) yields 2.13 ? RoundingType.ROUND_CEILING - The textual description needs to be far more explicit and/or include examples for both positive and negative numbers. Round toward positive infinity? e.g. Let the rounding digit be 5, with an internal precision of 2. Thus: ROUND_CEILING(-2.135) yields -2.13 ? ROUND_CEILING(2.135) yields 2.14 ? RoundingType.DONT_ROUND - DO_NOT_ROUND would be more explicit and prohibit confusion as the contraction might cause some confusion. 

Summary: In Fbc: Need the ability to have date based exchange rates and for the
 manager to manage date based exchange rates.
 - Since we need to start accounting for dates for exchange of currencies
 and also for doing multi-currency money calculations, it would be nice to
 add settings on the ExchangeRateManager that is state based that allows for
 client configuration.
 
 
 

Summary: The specification should state very explicitly how the subsystems/entry
 points (i.e. StateIdManager, CurrencyBook, ExchangeRateManager,
 MoneyFormatter, MoneyCalculator) locate each other if multiple vendor
 implementations (e.g. StateIdManager and MoneyFormatter implementation from
 one vendor and the remaining from another) can work with each other. If the
 intention though is to support homogeneous implementations only (i.e. A
 vendor solution supports all subsystems/entry points and only works with
 its one implementation) this needs to be called out in the specification
 instead.
 

Summary: Should the subsystem/singleton components (i.e. StateIdManager,
 CurrencyBook, ExchangeRateManager, MoneyFormatter, MoneyCalculator) all be
 published separately to the CORBAservices Naming Service?
 
 

Summary: Propose the following interface change(s):
           void init(
                in wstring name,
                in wstring fractionName,
                in wstring mnemonic,
                in short numericCode,
                in wstring symbol,
                in wstring fractionSymbol,
                in short ratioOfFractionToWhole,
                in wstring description,
                in CBO::DTime introductionDate,
                in CBO::DTime expirationDate,
                in boolean isISO,
                in wstring ISOVersion,
                in StringCollection locales)
                     raises(FbcException); - Note in this signature that
                     scaleFactor, isExternalOutputShowingFractions, and
                     isInternalOutputShowingFractions have been deleted.
 

Summary: The init() method appears in the consolidated IDL Specifications portion of
 the standard, but does not appear and is not documented or discussed in
 section 2.3.6.
 
 

Summary: Missing details on preconditions on the Currency
 interface as a whole
 

 received issue

Summary: Can the wstring argument(s) to setMnemonic(), setName(), setFractionName(),
 setSymbol(), setFractionSymbol(), or init() be empty strings or strings
 containing only white space? Acceptable arguments need to be discussed.
 

Summary: Can the short numericCode presented to init() and setNumericCode() be <= 0?
 What are its legal values?
 Can the short ratioOfFractionToWhole provided to init() and
 setRatioOfFractionToWhole() be <= 1? What are acceptable values?
 Can the point in time represented by introductionDate be >= expirationDate
 in init() and setExpirationDate()/setIntroductionDate()?
 

Summary: Typos in the section that describes setRatioOfFractionToWhole(). The second
 sentence should be “The ratio for United States Dollars is one hundred
 pennies to one dollar, which is 100. In cases where there is no minor part
 of a currency (e.g. Yen), this method should return a value of 1.”
 

Summary: There is no description of isCurrentlyActive() and when/why it would return
 true vs. false. Since it is described in the same area as the
 introduction/expiration date, does it simply perform a check to see if the
 current system time falls between the introduction and expiration
 date/times?
 

Summary: Issue Description:  There is no mechanism to create Money instances via a
 factory/type manager method.
 

Summary: The init() interface appears in the consolidated IDL Specifications portion
 of the document, but does not appear and is not documented or discussed in
 section 2.3.7.
 

Summary: There is no descriptive text stating why an FbcException would be raised
 when calling init(), [gs]etCurrencyMnemonic(), or [gs]etValue().
 
 

Summary: Propose the addition of the following interface(s):
 
           void setDateRange(in CBO::Dtime beginDateTime,
                          in CBO::Dtime endDateTime) – Sets the window in
           time over which the ExchangeRate instance is valid.
           CBO::Dtime getStartDate() – Returns the date and time at which
           the ExchangeRate took effect.
           CBO::Dtime getEndDate() – Returns the date and time at which the
           ExchangeRate is no longer valid.
 
           Will also need an appropriate exception to throw when the date
           range is attempted to be set and beginDateTime >= endDateTime. Do
           not think that the beginDateTime should be allowed to be equal to
           the endDateTime as that then means that the ExchangeRate is valid
           for zero seconds.
 
 

Summary: The init() interface appears in the consolidated IDL Specifications portion
 of the document, but does not appear and is not documented or discussed in
 section 2.3.8.
 

Summary: Issue Description: Missing details on preconditions on the
 ExchangeRateValue interface as a whole
 

Summary: Can conversionFactor represent a value <= 0.0? I would think not. An
 exception should be thrown if the conversion factor is attempted to be set
 with a Ddecimal that represents a value <= 0.0
 The beginDateTime must be < endDateTime in the init() call correct? Throw
 an exception if this is not the case.
 The source and target currency mnemonics cannot be the same in the init()
 call correct? Throw an exception if they are.
 
 

Summary: In general the decision needs to be made as to whether a given
 stateIdentifier is used to indicate the boundaries of a session or a simple
 configuration, as it currently seems to attempt to support both. Whichever
 direction is chosen, all of the interfaces that accept a stateIdentifier as
 an argument should be revisited to ensure that the intent of the interface
 is still properly supported. e.g. Should the currency component still offer
 a “connectionless” interface to its consumers?
 

Discussion: It is only there to support state access.    A client can use the currency service in a separate session and use the same stateId in order to get the equivalent state applied.  It will still be a connectionless interface.

Summary: Use of CosObjectIdentity::IdentifiableObject as the interface for a
 stateIdentifier. There is a particularly concerning paragraph in v1.0 of
 the Relationship Service regarding the interface: “The value of this
 attribute [readonly attribute ObjectIdentifier constant_random_id] is not
 guaranteed to be unique; that is, another identifiable object can return
 the same value. However, if objects return different identifiers, clients
 can determine that two identifiable objects are not identical”.
 

Summary: getStateIdentifier() implies an accessor which it is not. Change name of
 the interface to issueStateIdentifier().
 

Summary: Add the boolean valid(in CosObjectIdentifier::IdentifiableObject
 stateIdentifier) interface. This must be included so that each interface
 that accepts a stateIdentifier can do validity checking against it before
 servicing the request.
 

Summary: addCurrency() will raise an exception “if the currency already exists in
 the CurrencyBook …”. There is no mention of what elements of a currency are
 required to determine if one “already exists”. What 
 needs to be fully
 detailed are those Currency elements which must be used to determine
 uniqueness. e.g. mnemonic, numeric code, etc.
 

Summary: areEquivalent() “determines whether the two passed-in Currency objects
 contain the same elements”. Again, what needs to be fully detailed are
 those Currency elements which must be to determine uniqueness. e.g.
 mnemonic, numeric code, etc.
 

Summary: The getCurrency() method name lends the consumer to believe that it is
 simply an accessor method, which it is not. It is a searching method.
 Change the method name to retrieveCurrency() or something that indicates
 searching semantics.
 

Summary: Currency create(
                          in wstring name,
                          in wstring fractionName,
                          in wstring mnemonic,
                          in short numericCode,
                          in wstring symbol,
                          in wstring fractionSymbol,
                          in short ratioOfFractionToWhole,
                          in wstring description,
                          in CBO::DTime introductionDate,
                          in CBO::DTime expirationDate,
                          in boolean isISO,
                          in wstring ISOVersion,
                          in StringCollection locales)
 
 

Summary: The createExchangeRate() and getExchangeRate() interfaces accept arguments
 sourceCurrencyMnemonic and targetCurrencyMnemonic. There is no mention in
 the document regarding how the component should react (e.g. throw an
 exception) if the passed arguments are the same mnemonic.
 

Summary: The addExchangeRate() method name could connote mathematical summation.
 Change the method name to insertExchangeRate().
 

Summary: The behavior of the insertExchangeRate() interface should be modified.
 Since ExchangeRates will now have a window in time over which they are
 effective, the behavior needs to address what happens when an exchange rate
 is attempted to be inserted that overlaps (in time) an existing exchange
 rate. i.e. Suppose an exchange rate exists in the system for a certain rate
 type, source currency mnemonic, target currency mnemonic, and is effective
 from 12:00 15 July 1998 until 12:30 15 July 1998. Now suppose we attempt to
 insert an exchange rate for the same rate type, source/target currency
 mnemonics and is effective from 11:45 15 July 1998 until 12:15 15 July
 1998. How does the insertExchangeRate() interface react in this case, or in
 any other case where the exchange rate to be inserted has an effective
 window in time that in whole or in part overlaps existing exchange rate
 data?
 
 

Summary:    The removeExchangeRate() interface may be too heavy handed.  Modify
 the semantics of this interface  to support making an exchange rate
 instance unsuitable for use (e.g. inactive). In this way, the exchange rate
 instance would still be known to the component, but could no longer be used
 in computations. It could however be extracted for reporting purposes, etc.
 Would need interface accommodations though to indicate the extraction of
 exchange rates that are “inactive”.
 
 

Summary: Propose the following interface changes:
       ExchangeRate createExchangeRate(
                          in wstring rateTypeId,
                          in wstring sourceCurrencyMnemonic,
                          in wstring targetCurrencyMnemonic,
                          in CBO::Ddecimal conversionFactor,
                          in CBO::Dtime beginDateTime,
                          in CBO::Dtime endDateTime)
 

Summary: Clarify how the ‘#’ is used in the money formatter – i.e. if the digit is
 zero and doesn’t contribute to the value, 0 will not show.
 

Summary: Clarify legal values for the MoneyFormatter format strings
 

Summary: It appears that setFormatByLocale() and setFormattingString() override each
 other, but the supporting text for each does not support this conclusion.
 If setFormatByLocale() is executed, and then a call to
 getFormattingString() is executed, a format specification for the given
 locale should be returned correct? If a call to setFormattingString() is
 then executed (which would change the format specification for the given
 state identifier from the locale based specification previously),
 getFormattingString() then returns the format specification just assigned
 correct? The supporting text needs to address this behavior.
 

Summary: Need to indicate that an exception will be thrown if setFormattingString()
 is called with formattingString being an empty string or one containing
 white space only.
 

Summary: Fix typo to setPatternMnemonicSymbol()
 

Summary: Interface changes for MoneyFormatter pattern handling
 

Summary: There is no mechanism to modify what the negative prefix is, in a formatted
 string. You can modify what the placeholder for the negative prefix is, but
 not the actual prefix. This then means that "-" is to be used in every
 locale. I would bet that we should support changing that character ... much
 like we allow changing the radix character or the grouping character.
 Hence, [gs]etNegativePrefixSymbol() above.
 
 

Summary: Clarify on comparison methods of the calculator that no rounding etc. would
 take place before the comparison,  it would be the raw numbers in each
 money instance that is compared.
 

Summary: Propose the following interface change(s):
           short getInternalPrecision(in
           CosObjectIdentity::IdentifiableObject stateIdentifier)
           void setInternalPrecision(in
           CosObjectIdentity::IdentifiableObject stateIdentifier,
                short precision) – See example of use of this in the
           MoneyCalculator Interface section.
 

Summary: Issue Description: What are the legal short precision values which can be
 presented to setInternalPrecision()? Should it be limited to values >= 0?
 

Summary: The CBOException type currently prohibits the called software from
 informing the calling software as to the source of the problem that raises
 a CBOException. e.g. If CBO::DTime::setSeconds(63) is called, a
 CBOException will be raised, but the caller cannot query the CBOException
 caught for its exception type or description as CBOException does not
 currently support these constructs. In the case where many arguments are
 presented to a method, the caller will not know which specific argument is
 causing the problem.
 

Summary: The equals/setEquals() interfaces accept a base class CORBA Object as the
 parameter type. The instance passed must be narrow’ed to a DDecimal, DTime,
 etc. for the interface to carry on with its task. This is not possible as
 the Ddecimal, Dtime, etc. are not IDL Interfaces, they are IDL Value types.
 Since an IDL Value type does not derive from Object, the narrow’ing is not
 possible. This also affects other portions of the CBO … DCurrency, DMoney,
 etc. Also, equals(in Object anObject) causes a problem in a Java
 implementation as every Java class inherits from java.lang.Object. The
 boolean equals(Object obj) method supported by java.lang.Object cannot be
 overriden AND additional throw an FbcException. Thus, equals(), setEquals()
 should be changed wherever defined to be equal(), setEqual().
 

Summary: Issue Description: Change name of interface to CBO::Decimal.
 

Summary: Issue Description: Clarify comparisons of two CBO::Ddecimal values on
 equality (i.e. 2.0 equal to 2.000) 
 – regardless of scale factor.
 

Summary: Make the following interface changes:
         boolean equal(in DDecimal otherObject);
         void setEqual(in DDecimal otherObject);
 

Summary: Issue Description: Change name of interface to CBO::Time.
 

Summary: Cannot set precision to something other than milliseconds, as DAmountOfTime
 cannot represent sub-second resolution. Cannot set the millisecond portion
 of the point in time as the Factory does not take the number of
 milliseconds as an argument, nor does the init() method.
 

Summary: The setYear(in long year) interface is described such that year is
 expressed in four digit form. Does this then mean that year must be >= 1000
 or that year indicates an absolute year after christ? e.g. 99 means 99 and
 not 1999?
 

Summary: The Currency submission indicates that a specific Currency instance that
 does not have an expiration date will be noted with an expiration date of
 99/99/9999. This attribute is handled via a CBO::Dtime instance, but a
 CBO::Dtime instance cannot be created or mutated to represent 99/99/9999.
 e.g. The CBO::Dtime::setMonth(mon) expects 1 <= 12, etc. Would probably be
 easiest to have two operations on CBO::Dtime to handle this. These could
 be:
         void setUnspecified() – might be handled in an implementation as
         99/99/9999.
         boolean isUnspecified() – insulates the consumer from knowing how
         the notion of “unspecified” is implemented.
 

Summary: DAmountOfTime difference(in DTime anotherTime) does not support an
 implementation properly as the difference between two points in time is a
 DamountOfTime instance and DamountOfTime represents an “absolute (positive)
 amount of time”. Thus, either DamountOfTime must be able to represent an
 amount of time that is less than zero, or the following interfaces must be
 available.
 ·    Propose the following additional interfaces:
         boolean equal(in CBO::Dtime otherObject);
         void setEqual(in CBO::Dtime otherObject);
         boolean less(in CBO::Dtime otherObject);
         boolean lessEqual(in CBO::Dtime otherObject);
         boolean greater(in CBO::Dtime otherObject);
         boolean greaterEqual(in CBO::Dtime otherObject);
 
 

Summary: Issue Description: Change name of CBO::DAmountOfTime interface to
 CBO::AmountOfTime
 

 received issue

Summary: Issue Description: Cannot represent milliseconds or any sub-second
 precision
 

 received issue

Summary: The toWeeks(), toDays(), and toHours()operations return the amount to the
 nearest whole unit. The toMinutes() and toSeconds() operations are not
 specified in the same way, and the commentary for these two operations uses
 such poor English that the intention is not clear.
 

: Need explanation that the ISO locale and it's associated format data will be provided by the vendor supplying the implementation.

All throughout the spec it references ISO 4217:1995, it would be better to reference the latest ISO 4217 standard (i.e. no hard-coded date/year).

Need the ability to clone Money from existing Money

Need clarification on formatting in MoneyFormatter. Can literal text be added to the formatting string, or is it strictly pattern based? If literal text cannot be added, add text to indicate the formatting string must contain only pattern characters.

DO_NOT_ROUND would be more explicit and prohibit confusion as the contraction might cause some confusion.

Should the interfaces that accept a wstring also somehow state the maximum length of that data string? This is necessary for the implementation to know the maximum number of wide characters that may need to be stored in a persistence repository. e.g. Currency.mnemonic is three? This also includes the following : Currency.name, Currency.fractionName, Currency.symbol, Currency.fractionSymbol, Currency.description, Currency.ISOVersion, a locale wstring, ExchangeRate.rateType, CurrencyBook.publishedVersion, MoneyFormatter.formattingString, MoneyFormatter.groupingSymbol, MoneyFormatter.negativePrefixSymbol, MoneyFormatter.radixSymbol.

Replace DTime in FBCCurrency with struct

Replace DDecimal with CORBA fixed type.

Summary: The value types in FbcCurrency (Currency, Money and ExchangeRate) need
 state added to them as defined by Objects By Value.