Colleagues,
I very rarely pass comment on these discussions - not because I'm sat in an
ivory tower, nor because none of them warrant augmentation. The primary
reason is time which these days I have very little of. However, in this
instance I really must say something.
There is one thing which these threads seem to miss which I believe is
indisputable - the concept of variability. That is business processes,
business models and their corresponding revenue streams change frequently
and even on a daily basis - for a variety of reasons - regulatory, market
driven, product or service functionality. There is a need now for mass
personalisation (even in B2B) all the way down the supply chain.
EDI applications will never be able to implement these business process
changes 'on the fly' - what is now emerging as a technology to address these
needs is Web Services - e.g. Microsoft .NET. By far the biggest player in
this field is Bowstreet (www.bowstreet.com) - I strongly advise you to visit
their site - much of MS .NET's marketing and promotional material is scraped
from this site and even IBM is jumping on the bandwagon (in a big, big way).
Finally, keep a close eye on UDDI (see www.uddi.org)- I just can't see how
EDI systems can play in this space without XML.
EDI has a future - it's just a very short one!
Finally, business webs as they are called fit very closely to next
generation economic principles - big subject but see www.bionomics.org.
Feel free to contact me (one on one please) for more detail.
Happy hunting.
Leon Benjamin.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 01 February 2001 14:21
To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: The XML/EDI has no Clothes!
Well, you all have good points, but let me present an alternate view. The
big guys are all doing EDI now, and they are unlikely to change. However,
they are still missing a large piece of the supply chain. The further down
the supply chain you go, the less likely the companies at that level are to
be doing business entirely in one vertical chain, and the less likely they
are to be doing EDI at all. If a company isn't doing a large percentage of
business with a big guy, it's not going to spend the money to install EDI
because it doesn't care if it keeps that customer or not. It may, however,
be the sole supplier of some essential component. If we can guess that Mr.
Pareto's theory applies, about 80% of suppliers are not doing EDI at the
moment. It takes much longer to cascade requirements down the supply chain
when they don't do EDI, and at the bottom of the chain, the suppliers may be
working with month-old data. Do you see the problem here?
With XML, the big guys can create the same old EDI files they always have,
and they can be readily transformed into XML, which in turn can be, with a
style sheet, either formatted to a web form, applied to a spread-sheet, or
sent directly into an off-the-shelf MRP or ERP system. I feel confident that
there will soon be a myriad of very inexpensive tools available to do those
things, provided we don't get into the same mess we did when we started with
EDI. That's why the work of ebXML's Core Components and Business Process
groups is so important. There is an opportunity, now, to get control of XML
in a way that those of us who were early X12 participants never even
considered in the EDI world.
Just my two cents,
Sally Fuger
-----Original Message-----
From: littlesys [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 01, 2001 8:40 AM
To: David RR Webber; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: The XML/EDI has no Clothes!
I usually follow these discussions in the background, but I'm compelled to
comment here. Although the registry is definately a part of addressing the
deficiencies in understanding the semantics, the real meat of the problem is
in making the "mappings" available to eliminate that cost.
This would mean that you have to know what the backend applications file
structures are, and from my somewhat limited understanding, the standards
folks don't have that body of knowledge in its entirety. Who does? The
application developers. But where are they blind? They don't know what
variations the trading partners are sending.
Consequently, each company implementing finds itself mapping or buying maps
or hiring mappers in order to achieve all the great stuff EDI and XML
delivers.
So, I guess I'm just reinforcing Steve's observations.
Kindest regards,
Karen Raper
Little Sys, Inc.
----- Original Message -----
From: "David RR Webber" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, January 31, 2001 11:29 PM
Subject: Re: The XML/EDI has no Clothes!
Steve,
It is frightening that 3 years on people are still none the
wiser than when we started! But why should that surprise me!!
Anyway - XML-EDI is simply that - this approach was taken
by CommerceNet in the first scramble to jump on the XML
bandwagon. Take an EDI transaction and 'convert' it to
XML by replacing the segment ids and field separators
with <tags> instead. You may shuffle the fields around
abit, create some new parent structures, and add additional
fields, but essentially its EDI in an XML wrapper.
The BizTalk mapper takes this one step further by
auto-generating the tags simply off the segment name
and field sequence number.
XML/edi on the other hand requires that you first of
all create a Registry. Then each element within a
transaction is allocated a Bizcode (aka UID in ebXML
parlance, GRef in RosettaNet). Then each element is
assigned semantic metadata information and business
information within the Registry that can be referenced
by the application software automatically querying the
XML structures in the registry that hold the semantics.
Then the last piece is the use of XML scripts (templates)
to define the mappings required and essentially
carry the integration linkage for the particular combination
of business process and application software. This makes
these re-usable (notice in the EDI world this is the expensive
internal proprietary mappings that EDI tool vendors sell you).
RosettaNet has created a Registry - but stopped short
of referencing it during the content processing.
Now you can begin to see why the early money went on the
quick and dirty fix-it - because noone wanted to implement
the registry and scriptable mapping technologies first.
The ebXML work is now crossing this milestone with
registry specifications.
Thanks, DW.
=================================================
Message text written by "Steve L. Bollinger"
>
Most of us were not here three years ago. Please state again the
difference between XML-EDI and XML/edi. The web page does not clearly
state that nor does your email.
David I don't think that distinction will matter at all to the major point
I raise because regardless of this you still need to integrate the received
document into the back-end data base of the receiving partner. It is this
point of semantic translation that is the problem in XML-EDI or XML/edi (or
X12, etc.).
At 11:18 AM 1/31/2001 -0500, David RR Webber wrote:
>I'm sorry that CISCO has poured millions into the hole
>finding this out - but I am not in the least bit surprised.
I expect by this you would also have to apply this same comment to
RosettaNet who continues to form these standards? Is this not also XML-EDI
and bound to fail?
<
------ XML/edi Group Discussion List ------
Homepage =http://www.XMLedi-Group.org
Unsubscribe =send email to: [EMAIL PROTECTED]
Leave the subject and body of the message blank
Questions/requests: [EMAIL PROTECTED]
To receive only one message per day (digest format)
send the following message to [EMAIL PROTECTED],
(leave the subject line blank)
digest xmledi-group your-email-address
To join the XML/edi Group complete the form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm
---------------------------------------------------------------------
Plan on attending the upcoming meeting during DISA's conference:
http://www.disa.org/conference/annual_conf/index.htm
------ XML/edi Group Discussion List ------
Homepage = http://www.XMLedi-Group.org
Unsubscribe = send email to: [EMAIL PROTECTED]
Leave the subject and body of the message blank
Questions/requests: [EMAIL PROTECTED]
To receive only one message per day (digest format)
send the following message to [EMAIL PROTECTED],
(leave the subject line blank)
digest xmledi-group your-email-address
To join the XML/edi Group complete the form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm
---------------------------------------------------------------------
Plan on attending the upcoming meeting during DISA's conference:
http://www.disa.org/conference/annual_conf/index.htm
------ XML/edi Group Discussion List ------
Homepage = http://www.XMLedi-Group.org
Unsubscribe = send email to: [EMAIL PROTECTED]
Leave the subject and body of the message blank
Questions/requests: [EMAIL PROTECTED]
To receive only one message per day (digest format)
send the following message to [EMAIL PROTECTED],
(leave the subject line blank)
digest xmledi-group your-email-address
To join the XML/edi Group complete the form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm
---------------------------------------------------------------------
Plan on attending the upcoming meeting during DISA's conference:
http://www.disa.org/conference/annual_conf/index.htm
------ XML/edi Group Discussion List ------
Homepage = http://www.XMLedi-Group.org
Unsubscribe = send email to: [EMAIL PROTECTED]
Leave the subject and body of the message blank
Questions/requests: [EMAIL PROTECTED]
To receive only one message per day (digest format)
send the following message to [EMAIL PROTECTED],
(leave the subject line blank)
digest xmledi-group your-email-address
To join the XML/edi Group complete the form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm
---------------------------------------------------------------------
Plan on attending the upcoming meeting during DISA's conference:
http://www.disa.org/conference/annual_conf/index.htm
