A Hilton wrote:
>
> Perhaps I lost you in all the detail I gave for a very specific real-world
> example. My point was that if the trading partners would exchange the EDI
> data in an XML-format then they wouldn't have to go thru all the extra steps
> of translation and storage (and associated costs, which is one of the things
> you wanted me to explain... as well as how it more of a direct link into
> their business processes) to get that data to the processing equipment in
> the companies that really matter ... people.
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?
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.
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.
> > The thread you contributed to was talking about the interoperation
> > of differently designed business processes. Here the great ...
>
> I don't see this as an issue with the formatting of the data as much as the
> MEANING of the data in that format. That's up to the contracts of standards
> to resolve.
Quite true. That's the trad-edi way of solving the interoperation
problem. By saying it isn't an issue, you are admitting there is
no equivalent stand-alone XML solution. With that I agree, hence my
belief that XML is not suitable for use in interoperations.
> The FORMAT of XML tells me, as a programmer, that I can expect
> to see segments and data elements delimited by "<>" and "</>", etc. and that
> there will be references to field type/length as well as other such
> formatting. How I understand what you are talking about is how the data
> WITHIN that structure is to be interpreted and processed. That belongs in my
> Business Logic programming and is completely separate from my ability to
> move that data around that single organization OR the entire document
> lifetime (from TP to TP and back and forth, etc).
I see you are starting to appreciate some of the problems.
>
> > its own. It must be remembered that XML is only a data syntaxing
> > method (ie a Markup Language). XML can be used, however, to format
> > the transaction attributes used by the interoperation methods
>
> Excuse me if I'm wrong here but isn't X12/EDIFACT the same thing (a "data
> syntaxing method" as you say)?
No it isn't. X12/EDIFACT both organise the transaction attributes in
nested sequential files which use a simple character delimited syntax.
That's only a minor tail end of the trad-edi story.
The crux of the trad-edi philosophy is that if everyone transmits the
same transaction attributes and formats them in precisely way, any
business process can operate with any other business process. That
premise is invalid (isn't true) which is why so few organisations
(relatively) world wide have adopted it.
So most of the "interoperation" focus of trad-edi is in defining the
attributes of the various business transactions and the segments to
carry them. There is no equivalent to this (yet) in XML. The ebXML
effort is trying to do something akin to this, but, judging by progress
so far, it will be many, many years before they even get to understand
how to go about it.
> 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?
> It simply says that I'm going to put this and
> that data into these structures so that my TP can (hopefully) figure out
> where they are and extract them.
You are right about the data being put into structures, but wrong about
the TP having to figure out where they are. This is determined during
the up-front discussion between each and every pair of trading partners.
It is implemented by various simplified click and drag methods used
by the translation software to specify the conversion between the
map of the incoming/outgoing interchange and the format of the file
used by the application program.
So in trad-edi there are two conversions and two translations involved
(one of each at each end of the interoperation).
Another interoperation philosophy (BSI) uses no translations and just
one conversion. It's basic mechanism for determining the transaction
attributes and the basis for interoperation is the Process Framework
and the Technology Support Infrastructure known as BEACON. Here consensus
is minimised to agreeing the goal of each external business process in an
industry - usually achievable in one half day meeting held
electronically.
There is also no equivalent interoperation mechanism to BSI in XML.
Although XML can be used to tag and identify the various data in the
transaction attribute streams used by both BSI and trad-edi, the BSI
or trad-edi interoperation mechanism is relied on to enable the
interoperation to happen. XML contributes in no way at all to this
achievement (in fact it just adds an unnecessary level of complication
and cost without providing any offset benefit).
> Aren't the EDI committees the actual
> standards bodies and decide how the format will be designed so that
> interoperation will accomodate the documents being interchanged and for the
> widest available population adhering to it?
Yes and No. The focus is what data (attributes) are applicable to
each business transaction. These are then build into an ungainly
segment arrangement that results in complete confusion as to what
is applicable to what business process. This confusion is sorted
out by two subsequent "destandardising" stages (Implementation
guidelines and determination of the actual customised interchange
to be used between each and every pair of trading partners).
> Is the term "EDI" not actually as broad in its meaning as I see it? Is it
> tied to a specific data formating (X12/EDIFACT/etc) and no other? I would
> honestly like to know because I wouldn't want to use the wrong term for what
> I'm successfully/efficiently doing now.
I refer to EDIFACT, X12 and the other similar interoperation methods
as Traditional EDI (trad-edi). EDI is not as specific and there is no
hard definition for it, although it does tend to be used nowadays to
mean automated interoperation between business processes with no
human intervention.
>
> > The situations you describe are all involved with displaying
> > information on a screen for a person to read.
>
> Yes, that's what I described but it's certainly not the only use and benefit
> to my using XML as an internal AND an external messaging mechanism.
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.
----
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.
> Another
> real-world example in an automated server-based context based on the same
> client: A business object (BO) is running unattended on a server late on a
> Friday and sees that the Transportation company is in need of some supplies
> to continue operations for the following week. This company only has minimal
> staff for the weekend and nobody will be able to manually order the supplies
> (blasted humans!).
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)
> The BO is setup to detect this situation and contacts the
> various suppliers to request a catalog of the supplies needed. Now, instead
> of receiving the entire catalog via X12, it does an XML-based search of each
> suppliers catalogs based on the equipment type, quantity available, price
> points, delivery time and stores this information in temporary storage (No
> need to download the ENTIRE catalog of each supplier with the costs of
> transmission and storage).
No practical implementation would attempt to download the whole
catalogue, so XML offers no advantage there.
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].
> Next, the BO notes that Joe Blow is on-call this
> weekend and makes attempts to contact him (email, pager, telepathy). No such
> luck.
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.
> After a certain time, the BO decides that this MUST be done and
> selects a supplier based on predetermined ranges of price points, etc. The
> BO orders the supplies and provides the XML received details of the order to
> the web server so that when the on-call human can see exactly what has
> happened when he actually does turn on his palm pc and not have to come into
> the office to see it.
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.
> 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.
> 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.
> 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".
> It simply handles what it can
> and notifies the appropriate humans when something extra is received.
Why? What are the humans going to do with it if it is not used by the
organisation's business system? File it WPB (waste paper basket) most
likely.
You have just introduced another useless cost and task for humans.
> By
> the way, all of the transactions coming from the supplier is in Spanish! An
> agreed upon tag in all the XML sent/recieved with this TP is "<Language>"
> and tells each TP what language is used.
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?
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.
> 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!
> 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:
1. How is the XML generator at the catalogue end going to know
what XML tags you use at the customer end for each of the
attributes? Does it have to be smart enough to use a different
set of XML tags for each interrogator? How does it know what
tag to use for each interrogating business system.
If it uses the same tags for every interrogator, how is each
interrogator going to align to the tags used. Do you need
different application programs to be used with each supplier?
Do all suppliers have to agree to use the same tags in their
catalogues - every supplier in the world? Does every customer
in the world have to agree to use the same tags as every supplier
in the world? How long will this take? Where are the walk-on-
water guys that can achieve it?
What if someone comes up with a new tag? Who approves it, who
disseminates it to every supplier and every customer? Does it
conflict with one already in use and introduce ambiguity or
overlap in the semantics? Who changes every customer and supplier
program to use it?
2. The language translation sounds simple, but how are you
going to ensure semantic consistency across the language
translation? (Detail above).
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.
--
Ken Steel
ICARIS Services
Brussels and Melbourne
Research results: http://www.cs.mu.oz.au/research/icaris
[EMAIL PROTECTED]; [EMAIL PROTECTED]
=======================================================================
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/
