(Editors Note: Summation in the last three paragraphs !)
> You really didn't explain any of that. For instance:
>
> 1. How do you avoid "translation", more accurately conversion,
> when different remote business systems will use different
> semantics and data patterns?
>
I avoid 1 step of translation with the TP that sends XML since that is the
message mechanism used by my applications. The databases I use also are
optimized for data input/extraction with XML. With the TP that sends X12 I
have to translate that formatting to the XML used internally as well as
extract the data elements in an unoptimized form to be input into the
databases.
> 2. What storage costs are involved with traditional EDI (trad-edi)
> that aren't involved using XML? Particularly, given that the
> XML data stream is many orders of magnitude larger than an
> equivalent EDI data stream.
>
Storage of binary data as well as large sets of TP-provided lists (catalogs,
spec sheets... more on this below) that is available (at their costs of
storage) from those TPs in a dynamic form. This means I don't have to
download all the maps/pictures or lists to my local storage and take time
keeping them updated locally. It's on the order of client/server. Why keep
something stored locally on your computer when you can simply have
references to the storage area on your server?
> 3. How is XML a "more direct link into the business
> processes"? Please
> choose an example and show how the link is established into the
> business processes using trad-edi and using your XML, pointing out
> how you arrive at your conclusion.
>
Please read my response to #1 above and most of the LENGTHY 2 posts I've
made.
I, obviously, don't understand how you are elevating the formatting
structure of X12/EDIFACT to have a business process interoperablility in
itself. I don't see the difference between X12/EDIFACT and XML in this
regard. Perhaps I just separate the data formatting structures with the
process of defining business process interoperablility and you don't. I
don't forsee a clearer understanding on either of our parts with example
after example either.
>
> > My X12 v4010 manuals don't say how I'm going
> > to interoperate with my TPs.
>
>
> Oh yes it does. Perhaps you don't realise how it does it? Do you
> now?
>
(Oh, sure. Simply because you tell me "oh yes it does" makes me magically
know now.)
No. Nowhere in the manuals does it tell me that the X12 204 transaction, L11
segment, L1101 data element is actually a Rocet# when the L1102 = "IL" and
that it is to be put into the Consignees' PO# internally and then used to
fill-in the 210 sent back to the TP. This was a mutually agreed upon (read:
we were forced to conform) requirement of the TP and provided
interoperability between us. This is the EXACT same procedure we went thru
when we switched to the XML format. We had to DEFINE what the XML tags MEANT
in this business context between two TPs. I say it again... Interoperability
isn't defined by the data formatting structure but it can certainly be
constrained by an inflexible one.
>
> You haven't described an external use of XML to achieve interoperation.
> I would be very surprised if you can - you'd be the first to do so.
>
You must have some idea of what the X12/EDIFACT formats can do in this
regard that XML couldn't. Since I don't believe the data formatting
structure is to be confused with the interoperation process (except in the
context of providing a flexible framework to allow these processes to be
constructed), I don't think I could be 'the first to do so." suitable to
you.
>
> In this example you have tended to describe a routine business
> system operation with a fairyland solution. If you claim you are
> doing this, I'm afraid I don't believe you - there are too many
> departures from business reality and too many unsolved problems
> glossed over.
>
Aren't we all living in this fairyland called 'Technology Land' ? :) I'm
not terribly sorry that you don't believe me. I wasn't believed last
~September when I made the decision to write my own EDI applications and do
the transmission direct with Bisync 3780 for a client forced to get into
EDI. I was laughed at by that first TP when I told them how I was going to
do it alone. 2 months later it was all working and saving that client over
$3000 a month in VAN charges/software updates/EDI consultant fees/line
transfer charges. This client has since gotten a few more (under 30 at any
one time) TPs and has real-world small-business solutions using both X12 and
XML. I stand by my comments and the real-life examples of my clients that I
shared.
Both examples I gave (one that was more people-oriented benefit by use of
XML and one that was more server-oriented) are true. The server-oriented
example was the precise business problem that prompted this client to use
XML instead of X12. The people-oriented example arose from my need to update
their 'views' of data quickly and cost-effectively with the existing XML
stream to/from their TPs. Yes, both examples were 'glossed over' because
those posts were too long as it was. Also, I have no desire to write a
business solutions article. I do not have the creditials to do so. I was
simply trying to provide you with just enough information to answer your
questions. See if you can find some case studies from someone more versed
and with more time that I have on the web.
>
> Here's what really happens. An application program runs nightly to
> match stock levels against the current demand pattern (different
> industries will determine this in different ways) and determine
> replenishment requirements. (Please excuse the simplification by
> ignoring the supplier lead/delivery/terms in this determination)
>
What 'really happens' is what I described. It does run nightly and sometimes
there are not enough equipment/supplies available given the number of loads
tendered to that client at any time (some Shipper TPs send a bunch of load
tenders late on a friday and this client doesn't want to decline them if at
all possible). This situation has only happened 3 times since December 20th
when it was put into production. But the process worked and could only have
worked that well/cheaply with their XML approach.
>
> No practical implementation would attempt to download the whole
> catalogue, so XML offers no advantage there.
>
Practical or not, this is exactly what this client was faced with by their
supplier TPs. The suppliers contacted about doing EDI business thru X12
(before the clients' migration to XML) REQUIRED that their catalogs were
downloaded locally. Don't ask me why, I was just told to make it happen.
> A search mechanism would be provided to identify the
> products which meet supplied criteria. However, the product
> catalogue server would send all the attributes of those products.
> Using XML, the customer could sort out the ones of interest once the
> data arrived, but could not specify to the catalogue server which
> ones were required. [The only technology that can do that (which
> I know of) is BSI].
>
As I said, you can do a search (much like your Yahoo,Lycos,etc) by
leveraging the tags in XML of only those items that match your search
parameters and downloading ONLY those items. This is across our XML-based
supplier TPs and not just one by one.
> That is quite an unnecessary step if the process is as automated as you
> describe. The rules for validating an automated purchase (eg Open-to
> buy) would be built in to the appropriate application program.
>
This is exactly what I was saying. The purchase decision was made
automatically after certain conditions where met. One of those conditions
happened to be (and QUITE necessary for this client) contacting the on-call
person for that weekend so the process could be stopped if there were
extraordinary circumstances involved. I believe in automation within the
supervision of humans and not the other way around. If there are no humans
around to take care of these decisions, then the automation continues within
the rules set for it ahead of time.
>
> XML is not needed to do that. A person can simply use an ordinary
> enquiry program (locally, via Internet or dialup access) to see exactly
> the same thing. And this can be done without the horrendous cost and
> disruption of reprogramming for XML.
>
True, this part can be done without XML. BUT, there was no translation
involved (just validation). The XML sent from the TP was DIRECTLY sent to
the webserver. The on-call person got a notice that something happened (but
you don't think that's necessary, do you?) and he wanted to see what it was
by browsing to the website, seeing the XML (with views applied for it being
a palm pc browser) from the TP. Quick, easy, flexible and no translation or
other processing for THIS PART. Yes, there IS extraction and processing of
this EDI transaction to put it into databases, etc. But NOT for this part of
it.
> > The supplier sends back a previously agreed upon (but
> > unavailable data element in the X12 standards) field that, when
> received,
> > tells the BO to print this extra and detailed equipment
> assembly sheet for
> > the maintainence personnel working with this equipment.
>
> Here is where you have conflict with business realities. Why would you
> want to do that? You'd be producing mountains of paper nobody needs.
OBVIOUSLY, since it was agreed upon in the first place, it IS mountains of
paper that people need. Otherwise it wouldn't have been agreed upon in the
first place.
>
> > There are also extra
> > fields included that haven't been agreed upon. No problem.
>
> You are right, but for the wrong reason. If incoming data is not
> used by the business system, it is ignored. XML is no use at
> all there.
>
"it is ignored" ! Exactly. Don't you ever wonder WHY your TP might be
sending you more information? "Oh, let's just junk it and worry about it
later..." is what most people do. Not so with this client. They WANT to know
what's going on. It's called being 'proactive'. They (the humans involved
here) might very well junk it but at least they have the choice.
>
> > The BO knows that
> > it has to print the entire document so humans can decide what
> to do with it
> > now and in the future. However, it doesn't bomb the entire
> system and send
> > back a "Rejected" Functional Acknowledgement.
>
> Why reject if the information required by the receiving business system is
> there? Superfluous information is not of interest.
>
> You have just introduced an useless cost for both parties in sorting
> out those "rejects".
>
If I send extra segments to my X12 TPs (those not in the X12 v4010 standards
and/or those agreed upon by both parties in the structure contract), the
entire transaction get rejected. Simple as that.
> Nice, but impractical. How is the semantic translation between Spanish
> and English (or other language) performed? What guarantee is there that
> tags like "productCode" won't be totally misinterpreted during this
> language translation step and lead to catastrophic confusion?
>
Tags are language-neutral in this case. But they don't have to be. In the
example you gave above "productCode" wouldn't translate so that's why it
isn't done with tags. Just the data delimited by those tags. This is really
just turning into an XML tutorial and not really an EDI discussion eh?
> You have just introduced an unacceptable vulnerability which could
> render your example quite useless. As for the cost - it could
> be enormous. None of the interoperation tools I've referred to have
> this problem.
>
Nor do they even have ability to handle this situation?
> > Sometimes, it's English and
> > sometimes it's Spanish. Depends on where the orginal document from them
> > comes from. The BO read this tag and used a neat little translator to
> > convert the text into English so the maintainance personnel
> could actually
> > read the assembly sheets. All automated over a leisurely
> weekend for those
> > blasted humans. :)
>
> You obviously don't realise the very severe practical problems involved
> in doing that. If you designed such a system you would probably have
> leisurely weeks and weekends from that point on!
>
Please explain the 'severe practical problems' in allowing flexible language
handling and an automated XML-based business process to run. I'd like to
know what I should look out for in the future. <s>
>
>
> > The TP didn't have to change their processes to communicate
> with us and we
> > didn't either. That's what I'd call interoperability between disparate
> > business processes WITHOUT forcing the 'little gorilla' to
> conform to the
> > 800lb one's preferences in this instance.
>
> But there are very severe problems you haven't offered any solution to:
> ...
Your questions about the XML-based catalog searching functions come down to
one simple fact that should be familiar to everyone here dealing with EDI.
Trading Partner agreed-upon (ie Contracts) structure. For the example I
gave, this client has 3 XML capable suppliers for the products that were
needed. Each of those TPs and the client AGREED that there would be certain
tags (but certainly not the only tags) that could be counted upon to be
there. Any new tags introduced with this search function couldn't be counted
on by all parties involved to be used. IF those new tags were warranted
important enough, then the Big Gorilla of the bunch would force all the
other ones to conform. Just because a different format (XML) comes along, it
doesn't wipe out the function of the business interoperability process.
>
> 2. The language translation sounds simple, but how are you
> going to ensure semantic consistency across the language
> translation? (Detail above).
>
Do you mean "How are you going to be sure the translation is accurate and
meaning the same thing to both sender and receiver" ? If so, then it's done
the same way everybody ensures semantic consistency within even a
same-language transaction... you don't. The phrase "Joe Blows a duck" means
different things to different people. <g> You simply have to use the most
accurate language translator that you can so the meaning of the messages
(remember, not the tags... just the data with the language-defined
parameters included) are as close to the original as possible. XML or not,
this is how translating is done in ANY context.
> So, you see you are quite wrong about not having to reprogram. The
> reprogramming involved could be so costly as to blow your neat
> little example out of the water.
>
> And you have not achieved any interoperation. You have just ignored
> most of the business and semantic realities involved.
>
> In fact, you have just demonstrated some of the important reasons why
> XML is not suitable for interoperations.
>
>
> > Need more examples?
>
> Don't bother. Please sort out the serious problems I've identified in that
> little gem and come back when you have something practical to report.
>
Just inflamatory.
I see from your website that you've done a lot of work in the area of
Interoperation of Business Processes. I'll have to read over it in the next
couple of weeks to see how you're getting your views on the tight connection
between the function of interoperation and data structures. I certainly
don't have all the answers to the XML - X12/EDIFACT debate but I do have
real-world SME EDI experience from a programmers perspective. There are far
better resources than I to learn XML from. I suggest that you might look
over them to get a fuller 'high-level' view of what that format has to
offer.
If any of you have been reading my posts (and how could't you.. it's been
SOOOOOO entertaining <g>), I hope you have caught on to my use of the
"XML-formatting" and "X12/EDIFACT-formatting" phrases instead of comparing
"XML" to "EDI" in general. In my view, XML is just a formatting structure
the same way X12/EDIFACT is but I see it as a more flexible, extensible, and
direct way of information flow into the systems I create. Those are the
important points I wanted to make all along.
Ken, this is my last post on this thread <letting the applause die down>
because I don't get paid to do this. I get paid to solve business problems
in hardware and code. Simple as that. If there's a so-called 'better'
solution out there for the business problems I'm asked to solve, then I will
gladly evaluate it and implement it for my clients (just as I have with X12
and now with XML). I have no vested interest in any particular technology
(except maybe the Intel platform. Never worked on anything else except an
AS400 for 911 stuff but that's another story) and pick what gets me richer
and fatter. :) Like I said before, I stand by my comments and experiences
shared here. I wish you luck in your pursuit of knowledge in this area.
I leave the last word up to you...
- A Hilton
=======================================================================
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/
