Re: Are value ranges misplaced

[Martin Bryan <mtbryan@sgml.u-net.com>]

Dwight


> Where range of valid values exists for a particular item, these ranges are
> expressed in the "data format" form. I am questioning whether this is the
> correct place.

The basic ranges are expressed in data formats, but the application specific qualifications to this should be recorded in the Constraints on use of Entity field on the entity definition form. (There is a fundamental problem with designing static forms to describe inheritence - what you want to do is easier to specify in a Schema than it is in a fixed data capture form!)

> My question derives from the process of extending or refining a component to
> define another component. This process may involve defining a valid range for
> the child that is a subset of the range for the parent. An example, that comes
> up in the work we are doing on Securities (Brokerage) components, is this: a
> monetary amount  is represented by a currency code and a signed decimal number.
> The value of a deal can inherit the representation of a monetary amount,
> representing the sale of an asset versus the sale of a liability. Likewise,
> signed monetary amounts can represent the amount of a payment, to accomodate
> credits versus debits. However, a bank check for a negative or zero amount is
> meaningless, so the range must be refined to positive values greater than zero.
> 
> To accomplish this I would like to define an entity (bank check amount) that
> uses a defined representation (monetary amount) but specifies an additional
> validation rule: numeric value greater than zero. I cannot do this because there
> is no opportunity to specify validation ranges at the entity level.

There should be no need to create a separate entity for bank check amount. There should be a general-purpose entity for MonetaryAmount and then an application of this that uses it with the Banking industry as an applicaiton CheckAmount. Then you can constrian the application of the generic entity without any problems.
> 
> The best application of the current forms I can work out is this: I define a
> data format for a signed decimal number and a separate format for positive
> decimal number. I then create representation classes for signed monetary amount
> (currency code and signed decimal number) and another for positive monetary
> amount (currency code and unsigned decimal number).

I would do it the other way round. I would define a single representation class for MonetaryAmount and then define a set of data formats within this for signed decimal number, positive decimal number, etc, and allow the user to determine which of these applies to his application of the MonetaryAmount core component. The currency code should not be part of the definition of the data format of a singed monetary amount, because you do not want the currency code within the value, but separated from it. (You can do mathematical operations on <Amount currency="USD>12.34</Amount> better than you can on <Amount>12.34USD</Amount>.) Also remember that the currency symbols need to be defined as a separate code set, so that you really need to list it separately in the list of embedded components. (We have yet to add a mechanism for identifying which embedded components should be represented as attributes and which as embedded elements, but I have an algorithm in mind for this!)

> The problem with this is that it defeats inheritance. Consider the possibility
> that future monetary amounts needed to accomodate an optional "Gross/vs/Net"
> settlement indicator with a default value of "gross" if not specified. 

I'm not sure that inheritance really needs to be applied here. While a positive decimal number is a subset of a signed decimal number, what is important is that they are both subsets of the core component decimal number, which is turn is a subset of reals. The real question is whether there are other properties that need to be "inherited". For example <Amount type="Net" currency="USD">12.34</Amount> is the simple way to extend the basic decimal datatype while still allowing methods specific to decimal numbers to be applied to Amounts.

> If the
> requirement foir a positive number were expressed at the entity, the new
> indicator would be expressed in the representation "monetary amount" which would
> be carried forward to all entities: DealValue, PaymentValue, and
> BankCheckAmount.

IFit applied to all versions of a monetary amount you would need to create a separate representation class for positive decimal numbers, but I do not believe this to be the case. The generic case is for a decimal number - the constraint only applies to your particular application of monetary amounts. Accountants would scream like mad if you insisted on the generic monetary amount core component being constrained to just positive values!!
> 
> In the current system, I have to make that change in the representation class
> SignedMonetaryAmount which will effect the change for DealVAlue and
> PaymentValue, but I must at the same time remember to make the same change in
> PositiveMonetaryAmount in order to effect the change in BankCheckAmount. This
> approach will add maintenance costs and promote the possibility of error/

Hope the above comments help

Martin