Ken, you asked for it...
If you are simply looking at the size of the documents (XML vs X12/EDIFACT)
then the costs *can* be higher with XML. This may not necessarily be the
case, however. How well (and easily) is X12 data compressed when sending
over-the-wire? XML compresses very well (and it should, it's very bloated
with all those redundant character tags). But that's a minor point anyway.
Consider the situation of transmitting binary data such as maps or facial
images. With XML, a hypertext link to the binary can easily be embedded into
the XML document and then be presented to the client for selective retrieval
or examination. Note, I use 'client' to mean either a human using any number
of *different* software applications (custom application, generic office
suite software, web browser, mobile pc device) OR an automated server
application that, when using business objects and rules, can decide to
download or process the binary data.
Flexibility is also a cost-issue for my clients. Some of them want to be
able to pick and choose equipment from a list of their suppliers. Instead of
downloading the entire catalogs from each of their suppliers or even
navigating the suppliers web site to get part numbers for the items, they
use an XML-based search engine that has indexed all the XML tags in the
suppliers' XML formatted catalogs. In that way, my clients don't have to
store each suppliers' catalogs (with the associated costs involved in
storage and upkeep) but can still get fast, updated access to suppliers'
catalogs. This all comes down to the idea of keeping 'references' or
'pointers' to data that already exists in the world and not keeping copies
of that data (again, with the associated costs and maintainance time). For
programmers, this is like using pointers to memory locations instead of
actually copying the exact data to another memory location. You don't have
to worry about keeping your copy syncronized with the original AND you save
memory space.
Still more to do with flexibility: I can present data directly to my users
with XML in the form of a web browser that handles XML directly without
having to decode it first. For instance, a Transportation client of mine
sometimes wants to see what Load Tenders have been sent to them on the
weekends or when they are away from their offices. I can present to them the
XML Load Tender as long as they have a web browser running (which could mean
they are looking at it on their refridgerator these days!). Flexible
presentation of the XML data is handled by the XSL (style-sheet) text files
that they choose. For instance, the dispatchers just want to see details on
pickup and delivery and they can choose the XSL sheet that formats the XML
data to give them just want they want. The maintaince personnel just want to
see what kind of equipment is going to be needed to haul this load and when
it has to be ready (fueled, repaired, etc). The accounting department wants
to know what is being hauled and who to bill it to so they can get a
jumpstart on the billing process. Each of these people get the same single
Load Tender but can chose a 'view' based on their needs at the time. Now,
you say "Big deal! I can do that now with my X12" and you'd be right. But, I
didn't have to store that raw data in my databases yet (although, I
certainly could have. They aren't *always* away from the office or on an
extended weekend!). And if there is some new 'view' of the data that they
want to see, I don't have to reprogram their custom applications to let them
see it. I can (and DO!) sit right here in my office a couple of hours away
type out a simple XSL textfile that gives them that 'view' of the XML data
and upload it to their webserver. I've given them what they want in about 15
minutes and the best part is ... it hasn't cost me a trip to their site. So,
it saves me money too.
There's also the flexibility of extending the normal tags (segments) of a
given document which I'll call metadata fields. These could be used to
identify information on how a certain section should be stored or processed
or maybe extra information such as a chain of responsible parties for the
document (a trace of who has 'handled' the document and who would be
responsible for errors, etc.) Different language versions can also be
included here. A tag could be used to denote language (Spanish, French, etc)
and handled appropriatly by processing applications on the receiving end.
The net effect of all this is that translation of the raw data coming in or
out is reduced and sometimes eliminated. Validation and some business-logic
processing isn't reduced, however. Storage space is reduced depending on
what you are storing now. Flexibility to the client AND the administrator is
enhanced. This all assumes you have a situation just like mine too. <grin> I
don't see how introducing XML-formatted data into an existing X12/EDIFACT
environment and simply translating the XML into flatfiles and/or into your
databases and treating it the same as your X12/EDIFACT data will do any
good. When I was first requested to EDI-ify a client I searched everywhere
for information on EDI and what the heck it was. I routinely found comments
like "To get the most benefit from EDI you must not only look at the
transmitting/receiving of data but how that data can flow thru the entire
business process ..." and I believe it holds true for using XML as the data
formatting structure for EDI. If you aren't going to use the special
features of the format then you might as well not use it at all.
Standardization isn't an issue with XML any more than it is for X12/EDIFACT.
If standardization was so important and pervasive in X12/EDIFACT then why
was I given (forced to accept, shall I say?) a 2 volume manual of
'enhancements and modifications' of the X12 v4010 'standard' by a trading
partner that lists how exactly different their version is from the
'standard' ? Standards mean nothing till a contract is signed and an
attorney retained... regardless of data formatting type :)
Where do you get your "3-4 times more expensive" statement? How many
different types of messaging/calling formats do you use in your
applications? You know, to move around call parameters or to return search
results or pass back tables to functions, etc.? I know that I use probably
5 different formats. I'm moving all but 1 of those to an XML based format.
That'll give me 2 ways to pass data back and forth from within my programs
and allow me to 1) reduce my time/cost updating those routines and keeping
them current to the ever-changing programming environment 2) make
smaller/faster applications 3) provide an extensible, uniform delivery
mechanism to a broad range of client applications (ie I can hook into my
programs from many different sources like Foxpro apps, Visual Basic apps,
C/C++ apps, VBScript/JScript, Java, Perl, etc. and provide just ONE
pass-back mechanism for all of them). It saves me money in the long run and
it's not hard to do either.
- A Hilton
> > For my clients and their
> > situations, XML transfered direct thru the Internet would be
> the most cost
> > effective solution. It's simply more of a direct link into
> their business
> > processing, data storage, and client applications than is X12/EDIFACT
> > formatting.
>
> It would be interesting to have a bit more reasoning behind that
> assertion.
>
> My experience is exactly the opposite. Unless applications are completely
> reprogrammed to use XML input (which appears to be roughly 3-4 times
> more expensive than using conventional syntaxes), XML simply introduces
> another level of complexity and cost into the equation.
>
> Please explain why I am getting the "wrong" answer.
>
>
> --
> Ken Steel
=======================================================================
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/
