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.
> 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. 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).
> 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)? My X12 v4010 manuals don't say how I'm going
to interoperate with my TPs. 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. 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?
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.
> The situations you describe are all involved with displaying
> information on a screen for a person to read. Interoperation
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. 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!). 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). Next, the BO notes that Joe Blow is on-call this
weekend and makes attempts to contact him (email, pager, telepathy). No such
luck. 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. 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. There are also extra
fields included that haven't been agreed upon. No problem. 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. It simply handles what it can
and notifies the appropriate humans when something extra is received. 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. 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. :)
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.
Need more examples?
- 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/
