[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FpML-AWG-Legacy Fwd: [fpml-arch-modelling-wg] Re: Class name tags
- To: awglegacy@xxxxxxxx
- Subject: FpML-AWG-Legacy Fwd: [fpml-arch-modelling-wg] Re: Class name tags
- From: "Danielle Cauthen" <dcauthen@xxxxxxxx>
- Date: Thu, 07 Jun 2007 20:03:00 -0000
- Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=lima; d=yahoogroups.com; b=o7VsDCV2u0NoQ4RQ+awGyeCQodFY1aLcBSa70kuN5PN+aGHGsZj5gV2RFU2RIvj9aJKYAMaDeaMFcfQpLvzAQMYP2OIwFcSkdGwWfRIaPb0I1nFk+aQnesgbBRxF1TZk;
- Reply-to: awglegacy@xxxxxxxx
- Sender: awglegacy@xxxxxxxx
- User-agent: eGroups-EW/0.82
--- In fpml-arch-modelling-wg@xxxxxxxxxxxxxxx, "Shaun O'Kane"
<sokane@...> wrote:
Sorry about the previous accidental posting.
In response to John's comments:
Having worked at Chase with end-users defining message formats I came
to the conclusion that it was important that any XML message modeling
paradigm should support as many OO constructs as possible, and
compromises were made due to restrictions in the tools used. (This had
nothing to do with nest instance/class name tags per se). I believe
that the approach should be to concentrate on the mapping from obejcts
(UML?) to XML.
John is correct that implementations are important, but that does not
mean that we should adopt the first, or second implementation that
comes along without some consideration of the alternatives.
There are alternative marshaling schemes which work arrays. The
addition of class name tages can remove ambiguity from ((a?, b?)+), but
so can the adittion of other tags as required by other approaches. In
fact, the definition of a good OO mapping scheme ensure that this type
of ambiguity does not arise. (JOS scheme can also be viewed at this
level)
It should be noted that some of the "insights" I have published came
from the implementation of marshaling code. I believe dropping class
name tags (which I believe are meaningless) actually simplifies coding.
Name tags map directly to class marshaling.
Consider the following.
penaltyFare Money
It does not follow that penaltyFare should be implementated as a class
of type Money. For example, it may be there are additional constraints
which are implemented by penaltyFare (< £1000?) i.e. It should be
implemented as a separate class from Money. In this context, the Money
class is meanginless.
I am not implying that we should adopt the above scheme, but it would
make sense if the XML was machine generated. It does howvere cast a
serious question mark over nested class name tags.
I believe that class name tags should be dropped becuase:
(1) I belive they complicate (or are meaningless in) mapping schemes
(2) They are inconsistent with the Schemas approach. (tx Nic)
(3) They add verbosity
(4) I believe they complicate implementations
On a personal note, I'm glad to announce the birth of my son , 8lb 3
oz, on Sunday at 10:22 pm. I shall be organising drink soon.
Tx
Shaun
<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