"William J. Kammerer" wrote:
William, thanks for the conscientious attempt to address some of the
real problems of B2B automated interoperation.
>> "What problems (and costs) that stop the wider adoption of EDI are
>> solved by using XML?"
> When all is said and done, though, it's hard to believe that these minor
> syntax considerations are what hold back greater acceptance and use of
> EDI.
>From some research I did several years ago, the big problems for
adoptability of EDI stem primarily from 2 factors (but there are many
other such as "standards" that aren't implementable):
1. The fact that there are no true standards for EDI. This means that
the precise code values, data positioning and data content have to be
discussed between each set of trading partners up front, and then the
translators at both ends set to the result of that discussion. In other
words, each EDI implementation between each set of trading partners has
to be customised.
This in turn involves people experienced in the intricacies of the EDI
language have to be involved in the implementation of each pair of
trading partners. It can also mean that the business processes have to
be re-engineered every time a new trading partners or existing trading
partenr comes in with new data content demands. A never-ending source of
revenue for the EDI industry and a never-ending escalation of the cost
of doing business for the end user.
This makes the overall implementation cost very high, the implementation
time very long and the maintenance costs prohibitive. It also means that
packaged application software can rarely be used - particularly across
industry boundaries. It also effectively restricts the players to those
with in-house IT departments which is why primarily only the large
organisations adopt EDI.
2. Business language is translated to a foreign context (a dispersed
semantic language) at one end and an attempt is made to "untranslate" it
back to business language at the other end. This can lose the semantic
consistency and quite often custom built programs are needed at the
receiving end to make the result useable by the processing application
program.
So why not just customise adapter software and do away with all the EDI
guff? [This appraoch is actually now more widely adopted than EDI].
As the big players dictate the interchange structure, the smaller
players must do all this complex work (the party who can least afford
the cost of doing it) and as a result their cost of doing business
escalates with little benefit. Not a good long term basis for a business
relationship.
-------
ebXML appears to have the same problems for 1. and for 2. although a
small number of the myriad ways of expressing semantics in XML can limit
the extent of disadvantage in 2 a little.
--------------
>> "How does XML achieve these dramatic improvements over EDI so that XML
>> brings automated B2B interoperation within the scope of the resources of
>> small 20-employee organisations?"
> XML doesn't, by itself. As Rachel Foerster noted, XML has the
> mindshare, which translates into ubiquitous infrastructure support.
> There *will* be standard ways of moving XML and attachments from point
> to point in a secure manner, using ebXML's Messaging Services.
Another "gunna do"? IT is littered with failures when the "try to do"
happens. At the moment, XML is destandardising very much faster than EDI
ever did.
Is ebXML doing anything to specify which of a million or two ways of
writing XML must be used in interoperations? In other words, is there an
attempt being made to standardise the XML language for automated B2B
interoperations?
> At the
> very least, because of ebXML's MS reliance on MIME encapsulation of
> payloads, any mail client will be able to send and receive ebXML
> messages as ordinary e-mail. Attachments in formats alien to EDI, such
> as JPEGs and PDF documents, are handled consistent with e-mail in that
> you can simply point and click on the attachment icons. Compare that
> with X12 EDI, where the EFI and BIN segments would have to be processed
> without the help of a MIME decoder that "knows" what to do with
> attachments.
That is not specific to XML or ebXML. That is a feature of the workable
Internet standards. EDI can be transmitted in exactly the same way just
as easily. One can attach the EDI interchange file, pictures or other
"objects" and send it to the receiving trading partner who can process
the attachments in exactly the same way as you describe above. It can
even be automated with suitable mailer programs, one doesn't have to use
conventional mail clients.
> All this means that a cottage industry of applications can be developed
> based on ebXML standards, which would provide the shrink-wrapped
> software that the small 20-employee organizations would use.
Now that claim has not been substantiated by the explanation you gave
above:
If there still exists a DTD that must be used between the trading
partners, all the major problems inhibiting EDI adoptability still
exists in ebXML. ebXML can't be shrink-wrapped, because each
implementation needs to be customised for each trading partner. To
achieve a shrink-wrappable solution is not a transport problem, but
stems from a fixed defined structure/data content being interchanged
(the IC in EDI, the DTD in ebXML).
The only way to be able to shrink-wrap an interoperation philosophy is
to not define an interchange structure and data content and for the
receiving end to be able to handle anything that comes. If it is
shrink-wrapped, the tagging becomes ultra important, because if
different tags are used for the same data in different "shrink-wrapped"
solutions, interoperation is impossible.
This in turn requires a uniform naming facility for tagging data. As I
understand the ebXML people aren't even close to solving this problem
(see Alan Kotok's email of yesterday). It also requires a uniform
semantic environment and nothing I have seen in the ebXML blurbs
indicate that problem has even been recognised yet.
> ebXML will
> make it easier for software developers to use common interoperable B2B
> standards supported within their applications;
For 30 years, EDI has claimed to do that and hasn't been able to. ebXML
interoperation is still based on the same base premis as EDI (defining a
DTD or interchange data content), so why should ebXML be able to solve
this problem magically when EDI hasn't been able to over 30 years?
The reason for MIGs is that different industries need to use different
transaction parameters. Why EDI needs fully customised implementation
for each trading partner has a lot to do with different sizes of
organisation - even within the same industry - using different levels of
functionality in their application programs which dictates different
interchange data patterns.
There does not appear to be any solution to these problems offered from
the ebXML initiative. Have I missed something?
>> "More particularly, how does XML avoid the problem of upfront discussion
>> between the parties defining the interchange structure and then
>> customising the implementation for each pair of trading partners?"
> XML doesn't..
As these problems have been identified as one of the more significant
reasons why EDI is not widely adopted and also is a prime reason why EDI
can't be shrink-wrapped, it follows that ebXML will also have the same
adoptability and shrink-wrap problems. That means limiting to just the
big players who alraedy have EDI. So why ebXML?
>> "The problems are different, but XML uses tags to identify data. Doesn't
>> that cause a different set of big problems: A language must be selected
>> for the tag. Doesn't that preclude XML from being used in a multilingual
>> environment?"
> The XML element tags may be in a particular language; this is not
> unlike programming, where most variable names are in English, even
> though the application is used in a multilingual environment. If XML
> documents are examined by a human at all, it will probably be done by a
> programmer.
> And for sure, ebXML element tags will most likely be written in
> English - the language of Longfellow, Churchill, Shakespeare, Mencken,
> Jesus and Jefferson. But preferably the hardy American variety ripe
> with republican virtue as opposed to the effete version used across the
> sea.
When William posts to this list, it is always possible to learn
something. I didn't know before this, for instance, that Jesus spoke
American. Waddayano? ;-).
Good point. It can't be used in a multilingual environment but it
doesn't matter because it is a computer and not a "human thing". So even
the French computers must used American Inglish to be able to adopt
ebXML. ;-)
Wasn't "human readability" one of the "features" of ebXML?
But, OK, I'll give you that one.
>> "Doesn't the receiving party have to cope with different tagging names
>> and the burgeoning differences continuing to emerge in the way the data
>> semantics are represented and tagged in the XML programming language?
>> Does the small user have to learn to program in XML or call in
>> high-priced consultants to implement each trading partner?"
> If ebXML is successful in providing an XML framework for developing B2B
> standards, then the tag names should be consistent within the same
> problem domain when used for the same purpose.
Is see a big IF there again. ebXML appears to be folowing exactly the
same "wisdom" as EDI, but using a different file syntax. Is that really
eneough?
> As said above, the small
> user will be insulated from ebXML standards by the use of off-the-shelf
> software.
But will it? You really haven't substantiated that claim and there is a
logical argument to the contrary:
If each of these off-the-shelf software packages use differnet tags for
the same data unit or express the semantics in any one of the million or
so different ways of writing XML, then that will never happen. So the
chances are this is not a valid solution.
So, how does one ensure EVERY application program/ebXML implementation
uses precisely the same tag to identify the same data - that tag being
absolutely unambiguous and no slight meaning overlaps with with any
other tag?
How does ebXML ensure that the XML code is written in exactly the same
way (particularly the semantic structure) for every implementation?
Unless these two conditions are met universally exactly the same
barriers to widespead adoption exist with ebXML as with EDI - not
withstanding the unreadable UML models which are unlikely to be complete
or practical due to the complex layout and visualisation difficulties.
>> "How can the small end user customise the implementation for all these
>> differences in tagging and semantic representations for each trading
>> partner and the use of XML still fit within the available resources of
>> the smaller organisations?"
> If all the trading partners are using the same interoperable standards
> (in this case, ebXML), customization should be simplified and
> implementable in off-the-shelf software.
Yes, I agree. But the rub is that EDI hasn't been able to achieve that
in 30 years, why do you think that all of a sudden ebXML will be able to
do it using exactly the same basic philosophy?
>> "How is the small user able to get its application software package
>> customised for each of the DTDs and tagging/semantic structures demanded
>> by each of the larger trading partners?"
> Customization would supposedly be driven by the registry/repository,
> which could be queried for the specific configuration of core components
> used by the other trading partner. Since the RegRep specification uses
> UML diagrams, I haven't made it past the first page, so I can't tell you
> how this will be done.
Yes, I agree with your final conclusion: "Pigs might fly".
>> "How does an existing EDI user implement XML without having to double up
>> on the overhead and running costs (translators, training, reprogramming
>> applications to select the EDI or XML stream depending on the trading
>> partner, cope with two different sets of operating problems and
>> complexities etc)?"
> ebXML Messaging Services supports EDI (X12 and EDIFACT) messages as just
> another payload. Right off the bat, you'll be able to exchange EDI
> point to point, bypassing the VAN. Or you can continue to use a VAN,
> since VANs will probably support ebXML messaging services.
Transport is not the problem. I don't see any difference between
transporting a file written in any EDI sytax to one written in any XML
or other syntax.
The problem is that existing EDI users will not have XML-enabled
translators and must buy one if some of their trading partners adopt
ebXML. These new translators must be able to cope automatically with
files sent in any EDI and even more impossibly, any XML syntax (I really
am referring to the semantic representation method rather than the
language structure itself). The new "technology" will also have an
associated new set of problems.
Hence the doubling up of costs and problems has not been addressed in
your answer.
> Even if XML documents are exchanged, mapping to and from your internal
> applications files will still be required, though the task will be
> somewhat simplified because the templates for business messages will be
> automatically retrieved from the ebXML registry/repository. Someday pigs
> will fly too.
Exactly.
So, when it is all boiled down, you really exposing the same base
questions I am asking: If ebXML has all the same barriers to widespread
adoption as EDI, where is the benefit for the end user and why should it
be any more widely adopted?
In fact, one could extrapolate: the EDI market is appraoching (or
achieved) saturation - so where is the market for the same problems, but
using XML syntax?
All I can deduce about ebXML from this discussion is
* an added level of complexity;
* the ability for "tool" makers to sell expensive XML products to the
same people as already have made a heavy investment, but achieved little
benefit from EDI;
* A long, long term future for everyone involved in the ebXML
initiative while they attempt to turn a "gunna do" into something else;
* another similar initiative to take over and out-hype the ebXML world
in another 5-10 years.
Please argue logically to the contrary if you disagree.
I suspect stongly that before ebXML gets any useable answers, other
solutions from the outer field will have come up with real solutions to
the automated B2B interoperation problem and achieve widespread adoption
throughout all kinds and sizes of end user organisation.
Then all those that have invested time and money in this direction will
have done their dough yet again.
Don't ever forget: the IT industry traditionally makes its money by
producing yet another "you beaut" failure to replace the previous "you
beaut" failure. ;-)
Happy Christmas.
Regards,
Ken
--
Ken Steel
ICARIS Services
Research results: http://www.icaris.net/
Email: [EMAIL PROTECTED]; [EMAIL PROTECTED]
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
