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:

Nic, 

It is reasonable to exclude Date because it will (likely) be a built in
data type.  Or, because Date is not built-in data type for some OO
languages, it is reasonable to leave it as a class.

My point was IF the XML is to include the class as well as the
instance, FpML must also define what is and is not a class.  Excluding
schema built-in data types would only partly define what is a class.

I also agree that your FixedRate example is understandable.  My second
point was, an alternative (and clearly less verbose one) would be to
leave out ALL classes, and just have put in appropriate XML levels to
make the FpML understandable.

nic fulton <nic.fulto-@xxxxxxxxxxx> wrote: 
original article:http://www.egroups.com/group/fpml-arch-modelling-wg/?s
tart=15
> 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.
>

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