Re: [xml-dev] RE: Markup Combinators -- A Functional Approach toXML

[=?UTF-8?B?UGlvdHIgQmHFhHNraQ==?= <bansp@o2.pl>]

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
> 
>  
>