Bernd,
You wrote - in part .."XML is pushed as the future
> solution of the EDI dilemma. But EDIFACT will not be replaced by XML.
> There
> will be both worlds. I need something that seamlessly migrates to both
> sides."
>
I agree completely with your view - specifically that at least for my
lifetime, we will see both worlds. I also agree that there needs to be
something that seamlessly migrates to both sides.
Based on first hand experience, the XEDI translator by XML Solutions does
exactly that. It allows any company that already has an investment in EDI
(either the X12 or EDIFACT flavors) to continue using that foundation system
(built on data dictionaries that took countless personyears of effort to
build) and to extend the reach to those suppliers or customers who are
unable or unwilling to invest in EDI. The XEDI approach allows the non-EDI
types to be reached via the Internet and browser.
> The XEDI approach was endorsed by the Aerospace Industries Association
> (AIA), a consortium comprised of companies such as Boeing, Lockheed
> Martin, Raytheon, and hundreds of other suppliers within the aerospace
> industry. The XML Solutions approach can translate all versions of all X12
> transaction sets and EDIFACT messages into XML format. Their server based
> XSLT then takes the XML and converts it to whatever format desired
> including but not limited to HTML or Java supported HTML. There is no one
> else that I'm aware of who can make the same claim. An excellent technical
> paper is available on their Web site at
> http://www.xmls.com/resources/techpapers.html
>
> Additional helpful information is available at: http://www.xedi.org/
>
> In December, I led the Lockheed Martin team that used the XML Solutions
> translator in a pilot to verify their capability. It was a complete
> success. Currently, we are in the initial planning stages for implementing
> their solution corporate-wide across the Lockheed Martin procurement
> function. Corporate-wide, we have approximately 65,000 suppliers. Today
> less than 20% of our suppliers exchange information digitally with us via
> EDI. Of those approximately 80% do not use EDI as it was intended -
> instead they convert the EDI to paper, known as rip and read types. These
> percentages seem to be fairly common across our industry. We are expecting
> to increase the percentage of suppliers that do business electronically
> with us substantially after we fully implement the XML Solutions system.
> We are currently gathering the information to develop the business case
> and are expecting a favorable ROI.
>
For a company that does not currently use EDI (X12 or EDIFACT), then you
will might want to look at other options. At least at this point in time,
the XML Solutions approach seems to best fit those companies or government
organizations that have already invested in X12 or EDIFACT systems.
Ron Schuldt
Senior Staff Systems Engineer
Lockheed Martin Enterprise Information Systems
Phone: 303-977-1414
FAX: 303-971-4274
email: [EMAIL PROTECTED]
> ----------
> From: Bernd Buchegger[SMTP:[EMAIL PROTECTED]]
> Reply To: Bernd Buchegger
> Sent: Wednesday, January 19, 2000 1:11 AM
> To: XML EDI Group Listserver
> Subject: WG: need help for XML/EDI implementation decision
>
>
> Lets imagine the following scenario:
>
> There is an electronic commerce system with an integrated shopping system
> and you want to generate electronic orders in XML format in order to
> forward
> them to your suppliers business system over the internet. I don't want to
> create an own notation I want to use an existing standard. Reading a lot I
> am aware of the ongoing XML/EDI initiatives. XML is pushed as the future
> solution of the EDI dilemma. But EDIFACT will not be replaced by XML.
> There
> will be both worlds. I need something that seamlessly migrates to both
> sides.
> Sounds like a typical requirement in the recent electronic commerce
> development environment, isn't it?
>
> There is one big question in the air which i am certain I am not the only
> one to be faced with:
>
> "Which xml dtd / format / structure / initiative should be chosen that
> will
> do the best job?"
>
> - I see CBL 2.0, a framework of message building blocks designed to
> construct an order message. 2.0 sounds good and mature. How should the
> order
> message look like? How must the underlying application look like? Are
> there
> any experiences with CBL? CBL and EDIFACT???
> - I see cXML with its predefined message structures. Looks like a
> traditional EDI approach with a fixed and inflexible message structure.
> Does
> it meet all demands a business system can have? How will it be extended in
> the future? Who is using the cXML?
> - I see the biztalk framework, which follows another way. There will be
> XML
> schemata published within this framework. I can submit my own and build
> translators to other message types. Very interesting. How should my
> message
> type look like? What about translators to EDIFACT or ANSI X.12 based
> messages? Doesn't that mean that I have to understand every message type I
> want to communicate with? Sounds quite work intensive from my perspective
> ...
> - What about the ebXML initiative? CEFACT developed the EDIFACT standard,
> how will an XML based work look like? Is there already some concrete work?
> - What about these numerous converter tools that claim to be xml enabled?
> I
> had a notion that they mainly contruct a xml structure out of the EDIFACT
> structure by using the EDIFACT qualifiers or codes as tag names.
> - What about the XML/EDI repository? Is there any work that can be used
> already? Are there any experiences? How should it be used? Is the any
> migration path to traditonal EDIFACT solutions?
> - What else is available? What should be considered and evaluated? Is
> there
> any impartial evaluation of existing xml/edi initiatives already
> available?
> - Where is the main difference between XML.org and Biztalk and why are
> there
> again different approaches, different work, different standards. Are these
> initiatives disjunct or are there any intersections? How should I value
> these initiatives??? Aren't they both aiming the same objective??? And if
> yes, do they cooperate? Or is it again a case of pure competition?
> - Is it too early for an XML based solutions and should we go back to the
> roots and implement an EDIFACT based solution?
>
> Any help, contributions, answers and suggestions will by highly
> appreciated!
>
> regards
> Bernd Buchegger
> Product Development Manager - intos GmbH
> Primoschgasse 3 - 9020 Klagenfurt
> tel: ++43 463 / 3875 - 250
> fax:++43 463 / 3875 - 255
>
>
> ==========================================
> XML/EDI Group members-only discussion list
> Homepage = http://www.xmledi.com
>
> Brought to you by: Online Technologies Corporation
> Home of BizServe - www.bizserve.com
>
> TO UNSUBSCRIBE: Send email to <[EMAIL PROTECTED]>
> Leave the subject blank, and
> In the body of the message, enter ONLY: unsubscribe
>
> Questions/requests should be sent to: [EMAIL PROTECTED]
> To join the XML/EDI Group complete the form located at:
> http://www.geocities.com/WallStreet/Floor/5815/mail1.htm
>
>
==========================================
XML/EDI Group members-only discussion list
Homepage = http://www.xmledi.com
Brought to you by: Online Technologies Corporation
Home of BizServe - www.bizserve.com
TO UNSUBSCRIBE: Send email to <[EMAIL PROTECTED]>
Leave the subject blank, and
In the body of the message, enter ONLY: unsubscribe
Questions/requests should be sent to: [EMAIL PROTECTED]
To join the XML/EDI Group complete the form located at:
http://www.geocities.com/WallStreet/Floor/5815/mail1.htm
