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.

resolved by Currency 2 RTF

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.

resolved by Currency 2 RTF

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.

closed issue, resolved by Currency 2 RTF

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)

resolved by Currency 2 RTF

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

resolved by Currency 2 RTF

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

closed, no changes

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?

closed, no action taken

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.

Closed, no change. This issue is fixed by Issue 2393

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.

closed issue, resolved by Currency 2 RTF

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.

closed, resolved by Currency 2 RTF

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.

closed, resolved by Currency 2 RTF

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

resolved by Currency 2 RTF

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.

closed issue, resolved by Currency 2 RTF

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?

closed , resolved by Currency 2 RTF

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.

resolved by Currency 2 RTF

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

resolved by Currency 2 RTF, close

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

resolved by Currency 2 RTF

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

resolved by Currency 2 RTF

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

:AmountOfTime

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

resolved by Currency 2 RTF

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.

Fixed in issue 2409

Summary: Clarify legal values for the MoneyFormatter format strings

resolved by Currency 2 RTF

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

Not an issue

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?

resolved by Currency 2 RTF

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.

resolved by Currency 2 RTF

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.

resolved by Currency 2 RTF

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.

resolved by Currency 2 RTF

Summary: Interface changes for MoneyFormatter pattern handling

resolved by Currency 2 RTF

Summary: Fix typo to setPatternMnemonicSymbol()

resolved by Currency 2 RTF

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.

Already resolved in a previous issue (2271)

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.

resolved by Currency 2 RTF

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.

resolved by Currency 2 RTF

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)

Close, no action

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

resolved by Currency 2 RTF

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

resolved by Currency 2 RTF

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.

resolved by Currency 2RTF

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.

resolved in Currency 2 RTF

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.

resolve dis Currency 2 RTF

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.

resolved in Currency 2 RTF, closed

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.

resolved in Currency 2 RTF, closed

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.

No action taken, this has always been viewed as a component.

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.

resolved by Currency 2 RTF, closed

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

closed issue, resolved by Currency 2 RTF

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

resolved by Currency 2 RTF, close

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()?

close issue, resolved by Currency 2 RTF

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.

closed issue, resolved by Currency 2 RTF

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

resolved is Currency 2 RTF, closed

Summary: Change double to short for internal precision

resolved in Currency 2 RTF

Summary: Add idl and text to describe the getAllExchangeRates method

resolved in Currency 2 RTF

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.

resolved in Currency 2 RTF

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

Change text in spec describing the correct behaviour for the rounding rules

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.

Already fixed in issue # 2415

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.

resolved and closed in Currency 2 RTF

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.

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

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

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

Need the ability to clone Money from existing Money

Replace DDecimal with CORBA fixed type.

Replace DTime in FBCCurrency with struct

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

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

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

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: 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: Issue Description: Change name of interface to CBO::Time.

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

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: The idl for CBO::DTime needs the method: long getYear()

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