W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > January to March 2001

Re: LC-16 ( LC-132 ): Allow arbitrary order with occurrence > 1

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
Message-ID: <f5bg0izgwrl.fsf@cogsci.ed.ac.uk>
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

  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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:54 UTC