Lists Home |
Date Index |
> <Product Item> PLU&="A256" Qty#=5 Rate$=4.56</>
> Somewhere, I assume, you have to encode the fact that Rate is in
> dollars of some sort. Otherwise you cannot reliably convert it.
Actually that is reading too much into it. The $ only defines that it is
a currency type field equivalent to the database column type currency.
I guess if I was in the UK it could be expressed like:
<Product Item> PLU&="A256" Qty#=5 Rate£=4.56</>
in Germany with english,
<Product Item> PLU&="A256" Qty#=5 Rate€=4,56</>
<Product Item> PLU&="A256" Qty#=5 Rate¥=456</>
other countries that don't have their own character, like Malaysia who
have RM, would most likely end up having to use the $ character. My
small study sample of malaysians say this wouldn't be a problem for
On Windows these days, all the locale information is available via the
windows api. So obtaining it is trivial.
If there is any actual currency conversion, showing conversion rates and
so forth, these would be at a different level. Like the UBL level for
example. We're only doing basic data recording here.
> Therefore you have to have at least a partial schema or ontology CML
> does this by having an extensible dictionary system and an extensible
> system of units (which does not but could include currency).
Just some field types that correspond to the sql field types:
& - Text
@ - Date
# - Number
! = Integer
$ = Currency
? = Logical
% = Mime encoded binary data (not yet implemented)
Add ~ to denote an encrypted field.
I've done this all from memory. It becomes rather second nature after a