FpML Issues Tracker

Tony –

I think this is a great start. However, I would suggest that we make it clear that we’re not just referring to validation rules, but rather also to assumptions by implementers about the order of the elements in the instance documents. (This is implicit in your proposal, but I’d like to make it explicit).

Starting with your proposal, I suggest the following slight revision:

When an FpML element is repeatable in an FpML Schema (i.e. “maxOccurs” is
> 1 or unbounded), no unnecessary constraints (i.e. validation rules)
should be defined to impose an ordering of the elements based on the data that they contain, nor should an implementer assume that such an ordering exists. Such ordering is usually unnecessary and unproductive, especially if the data already contains ordering information (e.g. timestamps). For example, it is inappropriate to have a rule stating that elements should be sorted in FpML documents in order of date if the date is part of the data; such sorting is better done at the application or database-query level, rather than the XML document level.

The only cases where validation rules may be imposed on ordering, or where implementers may assume that elements are in a specific order, are where both of the following are true:
* the order of the elements has genuine business significance;
* the order cannot be inferred from the data alone.
An example of this is address lines in an address. Such situations are the exception rather than the rule; where they occur, it must be noted in the documentation for the repeatable element that the order of the elements in FpML documents has business significance.

Brian

—–Original Message—–
From: awg On Behalf Of Anthony B. Coates (Miley Watts)
Sent: Thursday, August 23, 2007 11:13 AM
To: awg
Subject: Re: FpML-AWG Some ideas on wording about content ordering in the FpML Architecture doc

PS I wrote:

—
(i.e. “maxOccurs” is > 1 or unbounded)
—

but the “>” may have been interpreted in some mail clients as a quote indent, rather than a greater-than sign.

Cheers, Tony.

On Thu, 23 Aug 2007 16:04:16 +0100, Anthony B. Coates (Miley Watts) wrote:

> OK, here is an attempt at a starting point for this text:
>
> —-
> When an FpML element is repeatable in an FpML Schema (i.e. “maxOccurs”
> is
>> 1 or unbounded), no unnecessary constraints (i.e. validation rules)
> should be defined to impose an ordering of the elements based on the
> data that they contain. Such ordering is usually unnecessary and
> unproductive, especially if the data already contains ordering
> information (e.g. timestamps). For example, it is inappropriate to
> have a rule stating that elements should be sorted in FpML documents
> in order of date if the date is part of the data; such sorting is
> better done at the application or database-query level, rather than
> the XML document level.
>
> The only cases where validation rules should be used for ordering are
> where both of the following are true:
> * the order of the elements has genuine business significance;
> * the order cannot be inferred from the data alone.
> An example of this is address lines in an address. Such situations
> are the exception rather than the rule; where they occur, it must be
> noted in the documentation for the repeatable element that the order
> of the elements in FpML documents has business significance.
> —-

—
Anthony B. Coates
Senior Partner
Miley Watts LLP

Resolved, because the rule requiring this was withdrawn.