FpML-AWG-Legacy Fwd: [fpml-arch-modelling-wg] Re: Class name tags

["Danielle Cauthen" <dcauthen@xxxxxxxx>]

--- In fpml-arch-modelling-wg@xxxxxxxxxxxxxxx, "Robert Silver"
<robert.e.silver@...> wrote:

John -

(This reply is while I am wearing my "representing Deutsche Bank" hat,
and not my "Architecture Working Group Chair" hat.)

Agreed that the following is not a reasonable representation.
<Product>
	<PaymentArray>
		<currency>USD</currency>
		<amount>10.00</amount>
		<currency>EUR</currency>
		<amount>20.00</amount>
		<currency>JPY</currency>
		<amount>3000.00</amount>
	</PaymentArray>
</Product>

---------------------------------------

Either FpML has no standard as to when the class is specified or FpML
has no standard as to what is a class.

One can argue that date, like money, should be a class that is used
throughout FpML.

In turn:
<startDate>2000-03-01</startdate>

Should really look something like:
<startDate>
	<d:Date>
		<d:date>2000-03-01</d:date>
	</d:Date>
</startDate>

---------------------------------------

Should date be a class?  The real answer is "it depends".  It depends
on the OO design of the application.
It depends on the language.  It depends on the subjective views of the
designers, etc.

---------------------------------------

It takes more time and effort to transform XML to an application´s OO
design.
But, you get the flexibility to independently evolve the XML and/or the
application.

In contrast, there is pain when you tightly tie a design to XML, and
the XML evolves
(hence the strong objections raised with respect to removing Money).

---------------------------------------

I see two ways for FpML to define standards that are consistently
applied to FpML.

1) Have both the class and the instantiation in XML in all cases.
Here, FpML must clearly define what is a class and what is not a class.

Otherwise there will be endless debates similar to "is a date a class
or not?"

2) Have clearly understandable XML.  In turn, two constructs are needed.

Where there are 1 to n (or 0 to n) repeating tags, intermediate tags
are needed.
(Note all are lower case, no claim is made as to which, if any, are
classes):

<product>
	<payment>
		<currency>USD</currency>
		<amount>10.00</amount>
	<payment>
	</payment>
		<currency>EUR</currency>
		<amount>20.00</amount>
	<payment>
	</payment>
		<currency>JPY</currency>
		<amount>3000.00</amount>
	</payment>
</product>

Or, in the case where there specific identifiable instances, use unique
names:

<product>
	<feeAmount>10.00</feeAmount>
	<feeCurrency>USD</feeCurrency>
	<initialAmount>20.00</amount>
	<initialCurrency>EUR</initialCurrency>
	<finalAmount>3000.00</finalAmount>
	<finalCurrency>JPY</finalCurrency>
</product>

---------------------------------------

Deutsche Bank, would prefer option 2, but could live with option 1.
The alternative is not attractive.
That is, Money is a class, but date is not a class - because that is
the way it is!

<john.osulliva-@xxxxxxxxx> wrote:
original article:http://www.egroups.com/group/fpml-arch-modelling-wg/?s
tart=12
>
>
>
> As promised in today's FpML architecture meeting, here's
> my contribution to the content model debate.
>
> Cheers
> John
>
> (See attached file: ClassNameTags.doc)
>

--- End forwarded message ---



-------------------------------------------------------------------------------
To unsubscribe: Email majordomo@xxxxxxxx with a blank subject line
In the body include the line: unsubscribe awglegacy youremail@address
To view archives: http://www.fpml.org/_wgmail/_awglegacymail/threads.html