> "Weideman, Drake" wrote:
> My question would be:
> What is the difference between trad-EDI and EDI? I don't believe
> there is a difference. I believe this is a nefarious plot on the part
> of the XML faction---they can 'prove' trad-EDI is less efficient than
> XML...why, it even has more letters than the standard 3-letter
> acronym, plus it's awkward to say!!!
>
> I say fight back...let's go back to using the phrase 'EDI" but let's
> refer to that newcomer as <DescriptiveButLarge>XML
Might I suggest this comment is far too introverted.
Today, trad-edi describes a particular approach to interoperation,
namely that used by X12, EDIFACT, Tradacoms etc. This approach has
proved incapable of widespread adoption between organisations and is
rather impractical in the EAI (internal system integration) field. Other
approaches to solving these problems have evolved and have been more
widely adopted.
The most commonly used interoperation approaches today use adaptors or
any-to-any "translation". There are other approaches that have been
developed and are starting to be adopted slowly such as BSI (Business
System Interoperation). Both these and many other new approaches are
capable of adoption to varying degrees of effectiveness (and cost) for
both inter-organisation and intra-organisation application.
It is not at all clear where XML fits. XML is a file syntax, not a
solution to the interoperation problems. All the XML approaches I have
seen use the trad-edi approach, but instead of using a nested character
delimited ASCII file syntax (like all the trad-edi flavours) to carry
the transaction attributes between the interoperating application
programs, uses a quite different way of assembling data into a file. The
XML DTD equates to the Interchange Convention or Message Implementation
Guideline of trad-edi. XML syntax when applied in the interoperation
arena introduces a number of quite severe disadvantages such as direct
coupling (hard-wired semantic identification), etc, which the original
trad-edi syntaxes avoid.
In theory, at least, any interoperation concept can be implemented using
any file syntax, be it nested character-delimited, XML or any other kind
of syntax. The syntax used to build the transaction file has little to
do with the effectiveness or otherwise of the approach to interoperation
(but might have a large effect on the size of the transaction file). XML
syntax applied using trad-edi concepts will still retain all the
inhibitors to adoption that characterise trad-edi using X12 or EDIFACT
syntax, but will introduce a other problems such as another level of
complexity and tight coupling.
Nobody from the XML camp has yet succeeded in showing any areas where
XML solves any of the problems inhibiting the adoption of trad-edi. The
only supposed benefit of XML I have seen put forward by its enthusiasts
is that XML makes it easy to visualise the data. As the whole point of
automated interoperation (ie. today's reason-to-be for trad-edi) is to
enable computer application programs to interoperate with no human
intervention, this point is quite irrelevant and of no practical
benefit.
So, in conclusion, time has moved on and it no longer makes sense to
refer to EDI to mean trad-edi. Other approaches to handling
interoperation have evolved which use electronic interchange of the
transaction attributes and have been adopted more widely than trad-edi
over a very short time span.
--
Ken Steel ICARIS Services
Email: [EMAIL PROTECTED]
Technology: http://www.icaris.net/
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
