RE: [xml-dev] RE: Markup Combinators -- A Functional Approach to XML

[Norm Birkett <Norm.Birkett@reval.com>]

Well said, Bruce.

I've worked for a couple of decades doing data modeling for financial systems, ranging from quantitative analysis to front-, middle-, and back-office transaction-processing systems, and I can assure the list with some authority that:

(a) every data modeler (and mathematician and programmer and "financial engineer" who has anything to do with programming) in the field has dreamt of doing something like what Roger has outlined (with one important qualification, to follow), and

(b) no system has ever been built based on a model remotely resembling what Roger has outlined.

The qualification: The people I've rubbed shoulders with for years who engage in this sort of fantasy exercise have generally been professionals who know a good bit about the financial markets
--which Roger's illustration leads me to suspect neither he nor S.P. Jones does. They therefore tend to use financial terminology, and they use much more fruitful approaches to defining and naming their primitives.

I hope that last paragraph doesn't come across as "dissing" Roger or Mr/Dr Jones. I don't mean it to. It just seems evident that they don't know much about financial contracts.

A much more promising approach to this sort of thing tends to start with a grammar along these lines:

CashflowCollection :== CashflowSet *

CashflowSet :== CashflowGenerator | ExplicitCashflowSet

ExplicitCashflowSet :== Cashflow +

Cashflow :== DateRange, ConditionalityFunction?, CashflowAmount

CashflowGenerator :== SecurityPosition | ETContractPosition | OTCContractPosition

SecurityPosition :== Security, Position

Security :== CommonStock | PreferredStock | Bond 

ETContractPosition :== ETContract, Position

OTCContractPosition :== OTCContract, Position

ETContract :== ETOption | ETFuture

OTCContract :== OTCOption | OTCForward | Swap | CapFloor | Debt | CDSwap | Repo | FXSwap

What you quickly notice, as you launch into this sort of exercise, is that you write most of your valuation and other mathy functions to operate on an ExplicitCashflowSet, to which a CashflowGenerator can be converted on demand.

The reason recursion doesn't become all that useful is that the ConditionalityFunctions on Cashflows are never defined in terms of other Cashflows or CashflowCollections--except theoretically. If there's a CashflowCollection that any sizable number of Cashflows are defined in terms of, you can bet your bottom dollar that the financial markets have produced an index to be used in place of the underlying CashflowCollection. (In practice, the process goes the other way: Someone invents an index that might be useful for this sort of thing, and then Cashflow conditionalities get defined in terms of it.)

Norm


APPENDIX: DISQUISITION ON MATHISM
=================================
The western intellectual tradition has been obsessed for a very long time with mathematics, and has longed to find it in any problem it tries to solve. Descartes, for example, tried to rebuild metaphysics as an axiomatic-deductive system, and the discipline of philosophy is still trying to find its way back to having some connection with reality. Others have tried to turn politics (Bentham) and ethics (Mill) into mathematical disciplines, without conspicuous success. And so on and so forth.

Yes, we mathematically-inclined nerds WANT our mastery of math to turn us into superheroes, but it generally doesn't work out that way, for the simple reason that the only realm of reality that is comprehensively amenable to modeling as one or more axiomatic-deductive systems is mathematics itself. (We've created a few mini-realms, such as formal languages, where this type of approach works, but it's much less gratifying to show that something that was devised to be quasi-mathematical is in fact quasi-mathematical than to reduce, say, industrial organization to math.)

The key to using math powerfully to do real things is to use it modestly and carefully.

> -----Original Message-----
> From: Cox, Bruce [mailto:Bruce.Cox@USPTO.GOV]
> Sent: Monday, December 19, 2011 1:03 PM
> To: Piotr Bański; xml-dev@lists.xml.org
> Subject: RE: [xml-dev] RE: Markup Combinators -- A Functional Approach
> to XML
> 
> I agree with Piotr, it makes me very uneasy to see what I'd have
> considered content used as element names.  No harm in using XML syntax
> to create a financial calculator, but it no longer reads like XML, to
> me.  When my colleagues and I set out to model business concepts and
> practices in a schema, we take some care to separate business
> vocabulary from the values associated with what amount to variables in
> the vocabulary.  For example, "Applicant" or "Claim," either of which
> can take on numerous values.  The complexity of the vocabulary (as
> others have said in this chain) is proportional to the complexity of
> the business.  Yes, of course we can simplify it, but at the great risk
> of losing sufficient transparency for the customer.  If it doesn't
> look, smell, taste right, they won't buy it.  Of course, I'm as
> fascinated by the allure of pure, abstract systems as the next geek.
> Maybe, after I retire, I'll get to actually work with one.
> 
> Bruce B Cox
> OCIO/AED/Software Architecture and Engineering Division
> 571-272-9004
> 
> 
> -----Original Message-----
> From: Piotr Bański [mailto:bansp@o2.pl]
> Sent: 2011 December 17, Saturday 10:59
> To: xml-dev@lists.xml.org
> Subject: Re: [xml-dev] RE: Markup Combinators -- A Functional Approach
> to XML
> 
> Hi Roger,
> 
> I'm not sure I get the idea: what if the contract is worth not "one"
> but
> 1.32 USD (etc.)? Do you then create integer-based element names? (I
> fear to ask about reals :-))
> 
> This reminds me of something that felt deeply wrong to me when I saw
> it, but I felt unable to pin the problem down in one sentence: I once
> saw grammatical markup that used the values of grammatical categories
> not as attribute or element content, but rather as element names.
> 
> Technically doable, assuming a closed set of values, and
> straightforwardly constrainable even with DTDs, and yet it simply felt
> wrong to see something like:
> 
> <entry>
> <noun>car</noun>
> <def>...</def>
> </entry>
> 
> instead of, e.g.,
> 
> <entry>
> <form>car</form>
> <gram>noun</gram>
> <def>...</def>
> </entry>
> 
> I feel a need to keep the container skeleton apart from data values,
> with data type info preferably separated as well, but it's more like an
> instinct, and I'd be happy to tack a reference of two to it. Or to hear
> why it's possibly just one of many valid alternatives.
> 
> I hope this is on topic wrt your original thought and query.
> 
> Best,
> 
>   Piotr
> 
> On 17/12/11 15:04, Costello, Roger L. wrote:
> > Hi Folks,
> >
> >
> >
> > I noticed several typos in my previous message. They are fixed
> (below).
> >
> >
> >
> > I am excited about the markup combinator functional approach to XML -
> -
> > create a small set of primitive markup combinators and use them to
> > create complex combinators. It occurs to me that this is also the
> > approach used in mathematics -- start with a small set of axioms and
> > use them to create theorems.
> >
> >
> >
> > Do you know of an XML vocabulary that was created using this markup
> > combinator functional approach? If yes, would you briefly describe
> the
> > set of primitive combinators and a few of the complex combinators
> that
> > were created from the primitive combinators?
> >
> >
> >
> > /Roger
> >
> >
> >
> > ----------------------------------------------------------------
> >
> > The following example is inspired by “/How to write a financial
> > contract/” by Simon Peyton Jones. [2] Many of the words come from
> that
> > paper.
> >
> > *Example: Use Markup Combinators to Create Financial Contracts *
> >
> > The finance industry has an enormous vocabulary of jargon for typical
> > combinations of financial contracts (swaps, futures, caps, floors,
> > swaptions, spreads, straddles, captions, European options, American
> > options, ..., the list goes on.) Treating these individually is like
> > having a large catalog of prefabricated components. The trouble is
> > that someone will soon want a contract that is not in the catalog.
> >
> > If, instead, we could define each of these contracts using a fixed,
> > precisely specified set of combinators, we would be in a much better
> > position than having a fixed catalog. For a start, it becomes much
> > easier to describe new, unforeseen, contracts. Beyond that, we can
> > systematically analyze, manipulate, and perform computations over
> > these new contracts, because they are described in terms of a fixed,
> > well-understood set of primitives.
> >
> > Let us begin with some simple combinators and then use them to create
> > more complex combinators.
> >
> > Here is a simple financial contract, it pays one USD at the time of
> > acquisition
> >
> > <one>USD</one>
> >
> > The recipient receives one USD.
> >
> > “one” is a combinator. It is a contract.
> >
> > For our next contract the recipient again acquires the value
> > immediately, except all the payments are multiplied by (scaled up)
> 100
> > times
> >
> > <scale><konst>100</konst><one>USD</one></scale>
> >
> > The contract pays 100 USD.
> >
> > “scale” is a combinator. It is a contract.
> >
> > To re-emphasize, this new contract was created by assembling a double
> > with another contract.
> >
> > The recipients of the previous two contracts received the value
> > immediately. We can create a contract that is worthless until a
> > Boolean condition becomes true. Let’s create this contract
> >
> > When at January 1, 2012, acquire one USD
> >
> > Here’s the contract
> >
> > <when>
> >       <at>2012-01-01</at>
> >       <one>USD</one>
> > </when>
> >
> > The “when” combinator consists of a Boolean observable and contract.
> > Here are a couple examples to illustrate what a Boolean observable
> is:
> >
> > Hey, I observe that the date is (not) now 2012-01-01.
> >
> > Hey, I observe that the temperature is (not) now
> > 5 degrees Celsius.
> >
> > “at” is a Boolean observable that becomes true at time /t/.
> >
> > Now let’s create a contract that is known in the industry as a
> > zero-coupon discount bond (zcb). Let’s create this zcb contract
> >
> > Receive 100 USD on January 1, 2012.
> >
> > This is easily created by assembling the above combinators.
> >
> > A zcb contract is created by assembling a date, double, and currency.
> > The below XML creates the desired zcb contract. Read the XML as
> > follows
> >
> > This contract pays off when at January 1, 2012, an amount equaling
> the
> > scaling 100x of one USD.
> >
> > Here is the XML
> >
> > <zcb>
> >     <when>
> >            <at>2012-01-01</at>
> >           <scale><konst>100</konst><one>USD</one></scale>
> >      </when>
> > </zcb>
> >
> > Why did we go to the trouble of defining zcb in terms of multiple
> > combinators rather than making it primitive? Because it turns out
> that
> > scale, when, and one are all independently useful. Each embodies a
> > distinct piece of functionality, and by separating them we
> > significantly simplify the semantics and enrich the algebra of
> contracts.
> >
> > *Recap*: the above discussion illustrates how to approach XML in a
> > functional manner; that is, how to create XML by assembling markup
> > combinators. This is beautiful markup. This functional approach to
> XML
> > is consistent with XSLT and NVDL.
> >
> > /Roger
> >
> > [1] http://lists.xml.org/archives/xml-dev/201107/msg00116.html
> >
> > [2]
> > http://research.microsoft.com/en-
> us/um/people/simonpj/papers/financial
> > -contracts/contracts-icfp.htm
> >
> >
> >