xml-dev - Re: Babel (again) or standard taqs and aliases (UDEF, Bizcodes)

[dick@8760.com]

I've been lurking for quite some time and feel it's my time to "join the party".

IMHO, there appear to be two viewpoints from different affiliations; XML'ers and
EDI'ers.

XML'ers believe that XML is better than EDI because it lowers the barrier to
entry, is more flexible and is easier to implement than EDI. I don't want to
oversimplify and I'm sure there are more benefits, but these seem to be the
major ones from my observations. The XML'ers view of EDI'ers, IMHO, is they
don't understand how important XML is in creating a worldwide B2B infrastructure
and they are resisting change.

The EDI'ers, having been the B2B standard used by business for the past 20+
years, have a great deal of knowledge in the B2B arena, have a proven solution
and perhaps most importantly a substantial installed base.  IMHO, the EDI'ers
view the XML'ers as new kids on the block with a modicum understanding of what
it takes to build a B2B solution. EDI'ers don't see XML as an adequate
replacement for existing EDI solutions because B2B requires more than a transfer
syntax.

I work with clients in the Energy and Healthcare fields, both of which are users
of EDI and are currently investigating XML. There is a great deal of confusion
regarding the way EDI and XML fit in an organizations B2B infrastructure. Here
are some of the questions/comments I'm hearing:

- Should I consider replacing my EDI with XML?
- What are the benefits of replacing EDI with XML?
- When should I use EDI; when should I use XML?
- If I use XML how will I manage the mapping infrastructure to internal data
formats?
- Will I have to rewrite all my EDI maps to XSLT in order to use XML or do I
change my backend system to use XML directly?
- How will I keep track of trading partner information with XML?
- How will security (digital signatures) be applied to XML documents?
- What packaging/algorithm standards should I use to encrypt and package XML
documents?
- XML relies heavily on base64 encoding to encapsulate non-XML objects and this
makes files larger than standard XML. This means it will cost more to send XML
data over a VAN than traditional EDI.
- Can I use compression over XML to reduce file sizes and cost of transport over
a VAN?
- My VAN doesn't support XML, should I use the Internet?
- What protocols should I use to transport XML over the Internet, E-mail, Ftp,
HTTP?
- It seems the real benefit lies with using the Internet to send EDI, not in
adopting XML. If I send all my EDI via the Internet and avoid VAN charges I can
save huge sums of money and I don't need to adopt XML to receive this benefit.
- The change to XML appears costly.

These are all real questions/comments from real clients. The B2B marketplace has
a legacy and it is EDI. The marketplace is changing and XML appears to have some
merit. Answers to the above questions must make "common sense" to the people
facing the questions.

The ebXML group is wrestling with these very questions and it is my hope that
this group will provide the direction needed to help B2B marketplace
participants answer these questions and make the best decision.  As a co-author
of the ebXML packaging specification I can tell you that the ebXML Message
Routing, Transport and Packaging group is building a solution that will allow
existing EDI data to be carried along with XML data, essentially providing a
single solution that can be used by both EDI'ers and XML'ers. This is a small
step, I admit, but I believe it's a step in the right direction.

Regards,

Dick Brooks
http://www.8760.com/


----- Original Message -----
From: KenNorth <KenNorth@email.msn.com>
To: W. E. Perry <wperry@fiduciary.com>; <xml-dev@xml.org>
Sent: Monday, May 01, 2000 2:03 AM
Subject: Re: Babel (again) or standard taqs and aliases (UDEF, Bizcodes)


>
> < The economic incentives to do so lie in the advantages of
> cartelization. >
> [...]
> < If, one by one, newcomers can be constrained to doing business only in the
> forms prescribed by the pre-ordained vocabulary, they can be bullied by the
> other players into accepting cartel discipline. This is not in the larger
> interest of any of us. The promise of B2B is doing business on a
> peer-to-peer basis
> with anyone capable, on any occasion, of taking the other side of a trade.>
>
> Doing B2B according to prescribed forms has been the status quo among large
> companies and their suppliers for a couple of decades. It's history, not a
> practice being introduced by ebXML and BizTalk. Long before the W3C released
> the XML spec, the largest corporations defined B2B standards and transaction
> sets used by their trading partners. Something like 95% of the Global 1000
> use Electronic Data Interchange (EDI) systems.
>
> Because EDI isn't cheap, trading groups consist of partners who can afford
> the technology and the infrastructure it requires. The cost has been a
> barrier to entry for smaller companies. That's been one of the motivations
> behind initiatives such as ebXML and BizTalk. The technology at the core of
> those efforts (XML and the Internet) enables a smaller player to
> participate.
>
> P.S. This panel discussion might be of interest. You'll hear Bill Smith
> (OASIS), Dan Rogers (BizTalk), Bruce Peat (XML/EDI) and others discuss this
> issue:
>
> http://technetcast.ddj.com/tnc_program.html?program_id=59
>
>
>
> ================== Ken North =============================
> See you at AD2000 London (www.applicationdevelopment.com)
> XML DevCon 2000 New York City (www.xmldevcon2000.com)
> ===========================================================
>
>
>
>
>
>
> ***************************************************************************
> This is xml-dev, the mailing list for XML developers.
> To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
> List archives are available at http://xml.org/archives/xml-dev/
> ***************************************************************************


***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************