- 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