Re: Fantasies

[Philip Goatly <philip.goatly@bolero.net>]

Hello Kris,

       We are in a similar situation at Bolero - autogenerating from UML.

       There is a difference however in that the SWIFT system deals mainly
with Interbank Payments and does not (correct me if I am wrong) have much to
do with the 'Physical' Goods purchased - nor the transport of the same.
However that is in no way meant to diminish your achievements at S.W.I.F.T.
but we see your work as a very valuable contribution to the overall
'Transaction process'

      At Bolero we are modelling the 'complete transaction' Our definition
of a Transaction is the complete cycle from the Purchase of the Goods, to
the Buyer getting the Goods and Seller receiving his money. The state of the
transaction is complete when the Buyer has the goods and the Seller his
money.

       I am not certain how ebXML defines a business transaction or whether
there is such a definition.


Cheer, Phil Goatly.

----- Original Message -----
From: "KETELS Kris" <kris.ketels@swift.com>
To: "William J. Kammerer" <wkammerer@foresightcorp.com>
Cc: "'ebXML Core'" <ebxml-core@lists.ebxml.org>
Sent: Thursday, April 05, 2001 11:05 AM
Subject: Re: Fantasies


> Just to inform you that we (=SWIFT) are currently (for the moment only
internally, but I guess soon it will become public)
> generating automatically swiftML Schema's based on the same UML business
models from which we are also generating swiftML DTD's.
> The whole idea being that these syntax independent business models will be
the basis for an interoperable business standard.
> I entirely agree that there is no such magic thing that does the automatic
mapping for you. Semantic mapping cannot be done
> automatically.
> But having only one business model (in UML) in which several syntaxes map
into simplifies the whole mapping issue a lot since
> * for each new syntax, you only have to do the semantic mapping once (from
the new syntax to the syntax independent business model
> in UML)
> * you don't have to know/understand 'another' syntax
> * updates/semantic/syntactic changes only have to be done once.
>
> The idea being that existing solutions are reverse engineered into the UML
business model using traceability links. These
> traceablility links are the actual semantic mapping into the business
model.
>
> Once established, THEN you can automatically (or semi-automatically)
generate mapping tables from one syntax to another.
> In this way, each specific solution can plug in to the business model. And
of course, the pre-condition is that the messages MUST be
> semantically the same.
>
> Currently there is an initiative going on in ISO called ISO/TC68/WG10 in
which we are actively participating, which is looking into
> the conversion of the ISO15022 securities standard into ISO XML based on a
UML business repository, and how other financial
> securities standards (FIX-ML, DTCC, FpML, etc...) can plug-in to that
solution. So yes there one of the goals is, at the end, to
> generate mapping tables.
>
> I hope this helps
> cheers
> Kris
>
>
> "William J. Kammerer" wrote:
>
> > Arofan Gregory says "contextual definition of core components, and of
> > modelling those core components" will allow us "to do things that are
> > impossible today, such as auto-generate mappings between syntaxes or
> > vocabularies, or to automatically determine where my document
> > definitions and yours disagree, even though we may have used different
> > local names for the same bits of data."
> >
> > Dear Arofan:
> >
> > Oh, come off it!  When pigs fly, we will.  If you could do that, then
> > we'd just dispense with standards altogether, and just model both
> > end-points so they could "talk" to one another.
> >
> > Heck, I haven't even yet seen anyone take a UML data model and generate
> > schemas from it -  and that should be a lot simpler.  People tried and
> > tried to come up with semantic mappings between X12 and EDIFACT and
> > never did - so I wouldn't hold my breath now waiting for this
> > mumbo-jumbo of auto-transforming ebXML core components into EDIFACT, or
> > vice-versa.
> >
> > William J. Kammerer
> > FORESIGHT Corp.
> > 4950 Blazer Pkwy.
> > Dublin, OH USA 43017-3305
> > +1 614 791-1600
> >
> > Visit FORESIGHT Corp. at http://www.foresightcorp.com/
> > "accelerating time-to-trade"
> >
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
>