Re: implementations of "XML Voucher: Generic Voucher Language" ?

[Ian Grigg <iang@systemics.com>]

<snip>
> By the way, I'm studying how to write your bond and currency defined
> in <http://www.systemics.com/docs/ricardo/issuer/contract.html>
> in XML voucher.

Great!  Let me know when you're ready to issue :)

> I think some of properties of the contract do not have to be interpreted
> by the program and they are defined only for clarifying its legal meaning.
> In case of bond, for example, bond_face, bond_currency, and
> bond_maturity_date are needed to be processed especially when it is
> redeemed. But, bond_issue_date and bond_total_issue_number seem to be
> defined only for clarifying its legal meaning, am I right?

That's correct - the intention is to let a bond
writer put in the fields he wants, and guide the important
fields with conventions.  Obviously, things like face and
maturity are needed so that calculations can be done.  The
addition of the issue_date, etc, is simply there to complete
the full set of data, not because a program can use them.

IMHO, there is no useful meaning to a Ricardian contract
"conforming" to a particular layout such as that described
for bonds.  Every bond is different, and there is no good
reason to make them all the same.  What will happen over
time is that new bonds will introduce new tags, and software
vendors will be encouraged to interpret these extra fields
according to their usefulness.

(Another thing to bear in mind is that the bonds area, whilst
the original genesis of the Ricardo project, has not been
used since the early days.  We've done most of the last 3
years doing commodity currencies (precious metals) and are
currently experimenting with shares and national currencies.)

> I think that we do not have to introduce specific tags for these
> properties which are not interpreted by the software, since it is
> sufficient to write them in a plain text in "one" XML element such as
> <Contract>...</Contract>. I think it can be used as a criteria whether we
> introduce as an element in XML voucher or not.
> How do you think this approach?

Initially that would be fine - experience would guide us as to
how to develop the inner parts.

One thing that happened with currency contracts that I didn't
predict was that a currency issuer added a complete section
called [conditions] and a lot of fields like conditions_backing,
conditions_reserves, conditions_audit...  which all specified
the terms of the contract in those particular areas.

Likewise, a new contract that is being worked on by an issuer
has added a complete [definitions] section at the very beginning.
If we were to translate his contract to an XML format, it would
look like:

<contract>
 <definitions>
  <dollars>
   [ivan's] dollars are ...
  </dollars>
  ...
 </definitions>

 <entity>
  <shortname>...</shortname>
 </entity>

 <issue>
  ...
 </issue>

 <currency>
  <name>[ivan's] dollars</name>
  <tla>USD</tla>
  <type>decimal</type>
  <decimal_power>2</decimal_power>
  <fraction>c</fraction>
 </currency>
 ...
</contract>

(for example ...)  One thing I'm unsure of is the appropriate form,
should it be tags everwhere or fields?  E.g., would the following
be more appropriate:

 ...
 <currency name="ivan's dollars" type="decimal" power=2 fraction="c">
  Ivan's dollars are denominated in dollar units, with a fractional
  unit of contract of a cent.
 </currency>

-- 
iang