FW: Fantasies

["CRAWFORD, Mark" <MCRAWFORD@lmi.org>]

Title: FW: Fantasies

Kris,

        I am not sure why this is such a surprise. If memory serves me correctly, I seem to recall seeing SWIFT draft design rules for this "automatic" mapping between UML and XML last summer on either the core components or business process list serve.

        It would be most beneficial for all if you could share with us the current version of that document and, if not covered in the document, advise us what steps have been taken to -

        1) Ensure the XML vocabulary and corresponding schema developed through this methodology are consistent in every instance

       
        2) Ensure compatibility with developing Schema specification

        3) Identify what methodology was used to ensure optimization of the map with the XML syntax

        4) Identify approach and logic in using elements/attributes

        5) Identify approach and logic in data typing

        6) Identify how you are accommodating the various ancillary XML specifications (XPath, XLink, et. al)

        7) Identify if and how your effort supports XSLT

        8) Identify if your design rules also optimize XML when manually creating schema's from non UML models

        9) Identify if your design rules optimize XML  when manually creating schema's from other syntax based messages

        10) Identify how the above issues would be addressed for other syntax based message representations of the core components

        11) Identify if your methodology could work for non-UML representations (i.e. XML) in an ebXML repository of the core components, and what would be required within the representation to support the methodology

        I could probably get behind an automatic generating approach, if all of the above are adequately addressed.  However, from what I have read, I fear the focus has been on the methodology for conversion rather than optimization of the XML instance of your objects, and that your much work still remains to be done.

 In the interim, it is time that we get on with creating what business is looking for in the XML world and what ebXML has FAILED to deliver - a standard vocabulary, consistent design rules, and boilerplate Schemas that ensure semantic agreement - with which to do business.  The vocabulary and boilerplate schemas should harmonize with a core components library developed by business experts with technical assistance from the XML guru's in an international business standards setting.  The design rules should be developed by the technical experts and adopted by the business standards body.  The whole thing should be done quickly, and shared with everyone. Once the core components, vocabulary, schema's, and design rules are complete - and the family of XML specifications achieves recommended status - we can then focus on automatic generation methodologies.

Mark Crawford
Research Fellow - XML Lead
E-business Strategies
______
Logistics Management Institute
2000 Corporate Ridge, McLean, VA 22102-7805
(703) 917-7177   Fax (703) 917-7518
Wireless (703) 655-4810
mcrawford@lmi.org
http://www.lmi.org
"Opportunity is what you make of it"

> -----Original Message-----
> From: KETELS Kris [mailto:kris.ketels@swift.com]
> Sent: Thursday, April 05, 2001 6:05 AM
> To: William J. Kammerer
> Cc: 'ebXML Core'
> 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
>