[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Edi complexity, does ebxml really reduce it?

• To: <bry@i...>, <xml-dev@l...>
• Subject: RE: Edi complexity, does ebxml really reduce it?
• From: "Hunsberger, Peter" <Peter.Hunsberger@S...>
• Date: Tue, 13 Jul 2004 10:43:07 -0500
• Thread-index: AcRotxi60/gTQCrMRlqtYrPXvEEO7AANWzHA
• Thread-topic: Edi complexity, does ebxml really reduce it?

bry@i... <bry@i...> writes:
> 
>  Whenever one examines one of the ebxml specs or reads an 
> article on the subject  there is likely to be a reference to 
> how edi had problems with being accepted because it was too 
> complex, but luckily ebxml, being based on xml, solves all 
> this. A very suspect class of assertion it seems like to me. 
> I'm wondering if anyone who has familiarity with these 
> technologies can clarify exactly how and in what ways ebxml 
> reduces the complexity of edi. 
> 
> Basically my understanding is that ebxml just wrapped the edi 
> model in xml, so I have a hard time seeing how it could be simpler. 

I've done nothing with ebXML other than read bits about it here and
there.  However, I have designed and implemented a generalized (database
driven) EDI parser.  I personally believe that EDI was more or less just
getting to the point where it was gaining traction when XML arrived on
the scene and blew it away.  

Yes, EDI was around for a long time (as was SGML), but the nature of the
tools, and computing capabilities around at the time was such that
nothing had driven EDI implementation costs down to the point where
medium and small sized businesses could casually consider implementing
it.  You had to have a real big business driver to cost justify it.
OTOH, XML technologies arrived with well implemented parsers and tools
that have low costs (software and hardware wise). 

Yes, EDI was a little more restrictive in what you could generally
exchange, but for most business purposes it hit at least the 80% mark if
not the 99% mark; talk about tag soup, everything including the kitchen
sink was in there in some way or the other.  

For us, once you built the parser you basically had to load the database
with the equivalent of a schema; what elements where valid for what
document.  Individual business partners could still negotiate on what
this meant, but the biggest difference WRT to XML was that there was no
simple, common metadata exchange mechanism. That also added to the cost
of implementation.

Bottom line, for me, was that if you already had a (good) EDI exchange
mechanism in place there was little benefit to XML. To clarify my
parenthetic qualification; it depended a lot on your tools, many where
hard to adopt to new business areas. However, the lower cost of entry
for XML based technologies allows it to displace EDI technologies from
the bottom up and horizontally.  In the end it's really no contest if
you've got to exchange lots of different kinds of data with lots of
business partners.

> Also am wondering about CPAs in Ebxml, it strikes me that 
> this process could actually be somewhat onerous, does anyone 
> know of any case studies etc. on problems with making CPAs 
> between two companies?

Got me, I suspect you're right.  However, I also suspect it at least
takes some of the pain out of the pure person to person negotiations
that one might otherwise encounter... 

• Prev by Date: RE: What is the rule for parsing XML in a namespace inside HTML?
• Next by Date: RE: What is the rule for parsing XML in a namespaceinside HTML?
• Previous by thread: Edi complexity, does ebxml really reduce it?
• Next by thread: RE: Edi complexity, does ebxml really reduce it?
• Index(es):
  • Date
  • Thread