I think the idea that XML (or any other syntax) is going to be the "magic
bullet" for EDI is a real misconception. I also don't think Mr. Kammerer
was actually implying that XML, in and of itself, was such a thing.
What I've found in the past is that when new technology becomes prevalent,
it gives people an opportunity to open there minds, think things through
and approach problems (old and new) from a different perspective. Gosh if
stick to the old precepts and all we do is transliterate all of the
elements from X12 straight into XML, I guarantee we will have gained...
nothing. In fact, we would just make life worse since there would be all
those extra characters (somewhere between 0 and infintely more characters,
depending on who the authority is).
We're all in a hurry to adopt the latest and greatest so long as it doesn't
mess up what we're already doing. Send documents via XML instead of EDI?
Cool, right? Just think we'll be doing XML!!!
Sorry, I don't see the point if that's all there is. So why not rethink
some things? We keep seeing (and saying) that EDI doesn't work well
enough. Could it be that we need to come at the problem from a different
angle? Is it enough to worry about where is the data in the application
and what is the format of the data across the wire? That's the major focus
of EDI today. Who really cares about process...let's just get those
separators and codes in the right format.
I think it's interesting that ebXML is focusing on process and XML is just a
means (and not even the only one), rather than an end in itself. To me
that makes a lot more sense.
In summary, if the only reason to jump on the XML bandwagon is to do
exactly the same thing as EDI using XML, that's not good enough.
Best regards,
Bill Chessman, whose opinions may not exactly match those of his employers
Peregrine Systems - e-business connectivity group (formerly Harbinger)
On 16-Oct-2000 Paul Krikke wrote:
> William Kammerer wrote:
>
>> As far as XML's benefits go for B2B ecommerce: if permission to "play"
>> with XML is accompanied by a management dictate to improve the process
>> (regardless that the processes could have just as well been optimized
>> with X12 EDI), then all might turn out well in the end. As an example
>
> Doesn't this just mean that the real benefits of converting from X.12 to
> XML are gained from reengineering the process as opposed to anything that
> XML brings to the table?
>
> Perhaps I'm just cynical about "yet another magic bullet that solves all
> EDI problems", but I wince when I read all about XML's "magic ability" to
> make things faster/easier/cheaper. In my case, most of my EDI is
> customer-driven, and my customers come from such disparate market
> segments such as auto manufacturing, construction, and appliance
> manufacturing. Each customer's EDI implementation guideline differs from
> the next customers, often significantly. I don't see that being any
> different with XML (one cu
> stomer may use <CustomerName>Bzzt</CustomerName> while the next will use
> <ShipTo>Bzzt</ShipTo>, I'm sure). This doesn't seem a whole lot better
> than one customer saying "N1*ST*Bzzt" while the next says "N1*ZZ*Bzzt".
> I *still* need to tell my application that these examples all map to
> something like BLinfo.ShipTable.ShipName in my database tables.
>
> I've always seen the real work in any EDI project as being the
> application integration, and I don't that as being any easier with XML.
> As a matter of fact, I think that the ease of creating customer-specific
> "standards" (cough choke gasp) may well make the situation worse.
>
> Keep in mind that I'm talking about the situation where XML is used in
> place of X.12 for EDI. I *do* see some significant benefits in using XML
> to communicate between applications internally, but I'm still (very)
> jaded about XML for EDI. Is this way off-base? What am I missing? I
> really want to jump on the XML bandwagon!
>
> Paul Krikke
> Coordinator, Business Applications
> Taylor Steel Inc.
=======================================================================
To signoff the EDI-L list, mailto:[EMAIL PROTECTED]
To subscribe, mailto:[EMAIL PROTECTED]
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
