- From: Henry S. Thompson <ht@cogsci.ed.ac.uk>
- Date: 04 Jan 2001 15:30:38 +0000
- To: William Jamieson <jamieson_william@jpmorgan.com>
- Cc: www-xml-schema-comments@w3.org
William Jamieson <jamieson_william@jpmorgan.com> writes:
> Here is a "concrete use case" with an arbitrary sequence of
> repeating elements ...
>
> When modeling financial derivatives the risk engineer will typically
> compose the trade from a toolkit of financial "widgets". In the
> part of the model where the refix behaviour is defined he/she will
> create an arbitrary sequence of formulae, let's give them names such
> as "applySpread", "rateToYield", "round", "observeRate",
> "applyCapFloor", "knockIn", "knockOut" etc. In an instance document
> (in our case a message) the order in which these can be combined is
> arbitrary and many of these formula can be repeated. In the
> following I have omitted the (often substantial) content within each
> formula so as not to obscure the point...
>
> <refixCashflow>
> <observeMarketRate> ...etc... </observeMarketRate>
> <round> ...etc... </round>
> <yieldToRate> ...etc...</yieldToRate>
> <applySpread> ...etc... </applySpread>
> <round> ...etc... </round>
> <applyCapFloor> ... etc... </applyCapFloor>
> ... etc ...
> </refixCashflow>
>
> Tomorrow they may create a trade where the <applyCapOrFloor> is
> performed before the <applySpread> and <rounding> is only performed
> on the final blended rate. The proposed constraints that the "all"
> group imposes make this type of structure very cumbersome to model.
> This is an instance of a general class of document that describe
> workflow or procedure where the number and order of the procedural
> steps is arbitrary. Intellectually, for the purposes of validation
> the imposition of strict sequencing of data that is in a
> self-describing hierachical format seems Byzantine and, at a more
> practical level, the performance based justification for it is poor
> - it simply moves the processing burden.
But isn't an iterated <choice> the right way to model this? <all> is
for when there _are_ cardinality constraints on the components, and as
your prose and example make clear, this is _not_ the case for your
example.
ht
--
Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
W3C Fellow 1999--2001, part-time member of W3C Team
2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
URL: http://www.ltg.ed.ac.uk/~ht/
Received on Thursday, 4 January 2001 10:30:41 UTC