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

["Danielle Cauthen" <dcauthen@xxxxxxxx>]

--- In fpml-arch-modelling-wg@xxxxxxxxxxxxxxx, Nic Fulton
<nic.fulton@...> wrote:

Robert,

I don't think Date should be a class, as it will be a built-in data
type in XML
Schemas, and therefore this will become redundant very soon. Simply add
something in the documentation.

The documentation is where ALL class information should be contained
until XML
Schmemas are migrated too. If any of this class information is
reflected in the
XML it'll ALL become redundant in a few months.

I am sorry that I am repeating this over and over, but it seems to me
that we
don't all agree to the division of labour between the XML markup, as
seen in an
instance, and the XML Schema and its element type definitions and model.

In John's code, it seems that you should serialise the Java object
model into a
DTD, and then serialise a running instance of the object model into a XML
document valid against that DTD. If DTDs can not support the object model
definitions, generate documentation too.

As for PaymentArray, shouldn't the subelements be 'Payment' not money?
Payment
needs a date associated with I'd guess, Money doesn't. This way
Payment can be
a subclass (or element type) of Money, if you choose to. I am not sure the
PaymentArray is needed anyhow, isn't that the point of the 'one or
more' and
'zero or more' declarations in a DTD or Schema?

As another example, consider this case taken from the FpML spec. Note
that the
values may make no sense at all.

<r:FixedRate>
  <r:Fixed>4.0</r:Fixed>
  <r:spreadSchedule>
    <r:SpreadSchedule>
      <r:steps>
        <r:SpreadStep> 
          <r:percentage>0.5</r:percentage>
          <r:date>20000315</r:date>
        </r:SpreadStep>
        <r:SpreadStep>
          <r:percentage>0.6</r:percentage>
          <r:date>20000415</r:date>
        </r:SpreadStep>
        <r:SpreadStep>
          <r:percentage>0.7</r:percentage>
          <r:date>20000515</r:date>
        </r:SpreadStep>
      </r:steps>
    </r:SpreadSchedule>
  </r:spreadSchedule>
</r:FixedRate>

In my opinion, the spreadSchedule and steps elements are redundant as the
FixedRate element could have had an "optional" SpreadSchedule
subelement, and
this element could in turn have had "one or more" SpreadStep elements.
In fact,
in some sense the SpreadSchedule element is also redundant as it is
embodied in
a "zero or more" declaration  of SpreadStep directly in the FixedRate
element.
This would lead to the following:

<r:FixedRate>
  <r:Fixed>4.0</r:Fixed>
  <r:SpreadStep>
    <r:percentage>0.5</r:percentage>
    <r:date>20000315</r:date>
  </r:SpreadStep>
  <r:SpreadStep>
    <r:percentage>0.6</r:percentage>
    <r:date>20000415</r:date>
  </r:SpreadStep>
  <r:SpreadStep>
    <r:percentage>0.7</r:percentage>
    <r:date>20000515</r:date>
  </r:SpreadStep>
</r:FixedRate>

The documentation could then contain the description of what having
SpreadStep
elements in FixedRate means. Once the XML Schema specification is
brought out,
it will be possible to clearly express the more abstract notion that
FixedRate
elements are 'spreadschedule-able', in a similar way to Java interfaces.

I hope this helps.

Cheers,

Nic.

-----

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)
>


------------------------------------------------------------------------
To Post a message, send it to:   fpml-arch-modelling-wg@...
To Unsubscribe, send a blank message to:
fpml-arch-modelling-wg-unsubscribe@...

------------------------------------------------------------------------
Get your money connected @ OnMoney.com - the first Web site that lets you
see, consolidate, and manage all of your finances all in one place.
http://click.egroups.com/1/1636/4/_/385382/_/952001742/

-- Check out your group's private Chat room
-- http://www.egroups.com/ChatPage?listName=fpml-arch-modelling-wg&m=1


-----------------------------------------------------------------
        Visit our Internet site at http://www.reuters.com

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.

--- 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