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 2266: Clairfy comparisons of two CBO::Ddecimal values on equality
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 2365: Description of Exception handling semantics
Issue 2380: describe how the individual components should be accessed
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 2429: Support millisecond precision in DAmountOfTime
Issue 2430: Improve text in specification of of DAmountOfTime
Issue 2776: Remove dependence on a specific version of the ISO 4217 standard
Issue 2778: Add ability to clone Money
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 2266: Clairfy comparisons of two CBO::Ddecimal values on equality (currency-rtf)

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: 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: 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: Should the subsystem/singleton components (i.e. StateIdManager,
 CurrencyBook, ExchangeRateManager, MoneyFormatter, MoneyCalculator) all be
 published separately to the CORBAservices Naming Service?
 
 

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: 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.
 

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

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.