Though I didn't get much agreement here, I am pleased to see many thoughtful and
intelligent responses from all of you (Brian, Kurt, Antony, Ken)! No way I can
respond to all points in this email so I will touch on some. I apologize for my
verbosity. I really do try not to be but then it still comes out that way to say
everything I need to say.
In response to my statement: " If we really can pull off standardized "business
processes" and get ERPs, DRPs etc. to comply, then we can finally get beyond the
X12/EDIFACT vs. XML discussion which doesn't fix the real problems in exchanging
business transactions electronically, anyway."
Antony wrote: "This is exactly what won't happen. No business will stick to a
standard as they have to differentiate themselves from competition. Only way they can
differentiate is to offer services that the competition does not offer. "
I agree, Antony. I don't think it will happen either. It is a great idea but a
daunting task. And you hit the nail right on the head as to why. It is the need for
competitive advantage that causes this push away from standardization. And this is
the core reason why "differing partnerships" is an issue and all the problems that
ensue. I admire the attempts by groups such as RosettaNet to create these
standardized processes, but I am seeing first hand the barriers that they are running
into. Even now I believe they are beginning to recognize the hugeness of the task at
hand and how daunting it is. After two and a half years there is still no high volume
trading partnerships in production mode here that I can find. I would love to find
out that I am wrong on this.
Ken North wrote: "every time I hear someone assert that XML/EDI offers no advantage
over X12"
I wouldn't say "no advantage". I am somewhat playing devil's advocate here with the
XML claims of huge advantage. These I consider over-hyped, and are drawing companies
into the idea of how cheap and easy XML/EDI is going to be. I am hopeful that XML can
provide us a way to encompass many smaller players, that X12/EDIFACT leaves out. The
prospect of doing a sort of "rip and tear EDI" with nothing more than a browser and
ISP is very promising. This will require, however, some web infrastructure from a
"hub" partner and won't just happen "because IE5 can display an XML document in a
logical human-readable way". Provisions for ack, response, archiving are also needed.
Beyond this advantage, I find most other "advantages" are more uncertain.
Ken North wrote: "XML is an enabling technology for feeding portals, for content
syndication, for delivering data to wireless clients, for marking up multimedia data
streams, for collaborative authoring, and so on."
Yes, I agree, Ken. XML has many good uses and is a hot technology for good reason. My
comments are exclusively aimed at the use of XML for exchange of business transactions
analogous to the way X12/EDIFACT is done today(XML/EDI). I could envision portals
defining the standards for both customers AND vendors, taking this out of the hands of
all trading partners. This could carve a definite market into this EDI arena.
Remains to be seen though.
Ken North wrote: "Bottom line: every major corporation is going to have a cadre of
developers doing XML projects."
I absolutely agree this will occur. My point is "at what cost?" Less? the same? or
more than the current cadre of developers developing and maintaining EDI projects?
Perhaps for uses other than XML/EDI as you outlined above, they will provide great
value. I know I am on thin ice with many in this group when I say I honestly believe
where XML/EDI issues are concerned that the cost will not be far less has been
suggested. It may easily be as great or greater for reasons mentioned earlier in this
thread.
Kurt Cagle (Author, XML Developer's Handbook and co-author of other XML works) wrote:
"I see XML as being essentially a data language application for the
world, and we're about three years into a five year beta testing cycle."
Kurt, I appreciate insights coming from someone as experienced and expert in the XML
arena as yourself. Perhaps part of the roughness I see in this area is due to this
beta cycle. I think it is not the main factor however.
To Kurt and Brian Curtis: Brian you have a great list of accomplishments using XML.
You are far more an XML veteran (and so is Kurt) than I and I respect that. Both of
you responded to my "differing partnerships" argument and I respond back:
Brian Curtis wrote: "If you do business with one million companies and you have one
thousand translations, is it really such a hang-up? No, because translations
aren't that difficult to create.
Kurt Cagle wrote: "I want to address the combinatorial problem that you bring up --
how do you manage to support XML translations as the number of business
partners increase? I've actually thought about this one for a while, and it
occurred to me that this is actually not as major a problem as it sounds on
the surface."
I would respectfully like to point out that the both of you are approaching this with
forward looking logic trying to foresee how this will be solved (nothing wrong with
this particularly), while I am looking at this with 6 foot wide rear view mirrors. I
don't consider myself entirely an expert on this subject, but I do have 12 years of
veteran experience working on resolving the issues of "differing partnerships". I
have worked the front lines of these issues for years and respectfully propose that
you both are somewhat in error on your view of the scope, impact and resolution of
this issue.
"is it really such a hang-up?" Absolutely. It can be a maintenance nightmare in EDI
and will remain so in XML/EDI.
"No, because translations aren't that difficult to create" Maybe not coding wise. But
coding is only one piece of this. there is also analysis of the differences, testing
etc. Also these differences are not always static issues and tend to change over time
requiring maintenance. All this is costly to the company. This is a far larger
maintenance issue than either of you realize yet. Schemas and XSLT are great tools,
but I don't see that these will put a major dent in this issue.
Kurt Cagle wrote: "it is in the best of interest of any company to work with
as few schema transformations as possible"
In my experience companies don't make competitive business decisions based on this
criteria. This may change over time though.
I have watched for years as companies merrily jump into EDI (X12/EDIFACT) with high
expectations for exchanging business documents based on the rosy hype they read and
hear. Then only to hit the wall of SRA (severe reality adjustment) well into their
project. Although I have been involved with XML for only a short time (4 months) I am
already seeing companies hit this same SRA wall regarding XML. The powerful tools and
technology of XML, XSLT and Schemas alone will not be the fix here.
Brian Curtis wrote: "Now, as for "International Usage," you do realize that XML is
easily translated to other languages, right?"
Perhaps I need to learn more here. Please correct my view as needed: Let's assume an
international EDI scene with say a dozen different languages or so. If a programmer
has to write a translation for every tag into each language, then this is a daunting
task. I expect the bigger solution is with translation dictionaries from words in one
language to another. Perhaps there is some universally agreed URL that provides these
dictionaries? Let's say there is.
These would not contain a translation for <PONumber> for example. I would then need
to say <purchase.order.number> expecting each individual word to be correctly
translated. The question remains: does the English idiom "Purchase Order" translate
correctly into Japanese by translating the individual words "purchase" and "order"
into Japanese and putting them together? What about the longer "Purchase Order
Number"? If so what about the other 11 languages. I expect some do and some don't.
I am reminded of the old joke of the "Russian Language Translator" for translating
languages. It was fed the English "The spirit is willing but the flesh is weak". The
Russian translation came back: "The wine was outstanding, but the steak was rotten"!
:) I grew up in a foreign country and know well the cross cultural humor that has
evolved from real life examples of the literal translation of words vs. the real
meaning of the sentence when you put those together. I may be wrong here but I think
"XML is easily translated to other languages" is a simplified view and that the
reality may require far more work then at first imagined.
In closing: I am sure many of you are sick and tired of listening to my long-winded
ranting about "differing partnerships". I only do it because I truly believe this is
the key missing factor on some companies estimated ROI on what XML/EDI will bring
them. It certainly has often been a missing factor in many company's estimated ROI
using X12/EDIFACT.
If XSLT, Schemas, XLink and XPointers really do make a marked difference here as some
of you suggest, then I will stand corrected and be very happy for it, because then
companies won't suffer the high costs of exchanging transactions as they do today.
But I don't think it will happen at the level of the tools that you mention. I have
seen too many SRA's so I am not holding my breath.
Thanks for listening,
Steve
Steve Bollinger 408-853-8478
Cisco Systems B2B Service Logistics Pjt
------ 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
