Re: RE: Markup Combinators -- A Functional Approach toXML
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.  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 > >  http://lists.xml.org/archives/xml-dev/201107/msg00116.html > >  > http://research.microsoft.com/en-us/um/people/simonpj/papers/financial-contracts/contracts-icfp.htm > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format