I believe that was the point I was making. 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.
Of course, XML data is TERRIBLY bloated and binary data is handled poorly.
Such is life with new technology. All the pieces of the pie aren't fully
cooked yet and you get what you pay for in this situation. I would hate to
see how much it costs to transmit XML data over a VAN compared to
X12/EDIFACT. However, the benefits have, so far, been enough for my clients
to move toward the XML format.
- A Hilton
>
> This is all very good. However; let's not forget the orginal
> reason that we word with EDI or XMS or ?? and that is to move
> information from one application to another application in the
> fastest and most cost ffective method possible.
>
> Stanley Pool
> EDI Consultant
>
>
> In a message dated Tue, 18 Apr 2000 3:34:13 PM Eastern Daylight
> Time, A Hilton <[EMAIL PROTECTED]> writes:
>
> > > My point exactly! Why are we touting XML as the next best
> thing to canned
> > > bread when we already HAVE frameworks? We don't need no steenking
> > > frameworks!
> > >
> >
> > I can see good points and bad points to both formatting options
> and those
> > have been discussed to death by lots of articles (some seem right-on and
> > some are completely off-the-mark... reader beware). Since I'm in the
> > process of moving some of my application data/message transport
> to an XML
> > format, I wouldn't mind seeing the EDI data coming to/from the
> TPs in the
> > same format (given everything else being equal). This allows me
> to use the
> > same optimized routines and fewer translation/processing
> applications to do
> > the same job. I can also read the blasted transactions easier
> with XML than
> > with X12 formatting. Of course, as the TPs use more arcane tags
> > <BillOfLading> is going to become <DJekkl13lk> if some
> business manager
> > ever has his say in the matter! They can't just keep they're
> mitts off the
> > formatting for long), this benefit will erode in time.
> >
> > This all answers your last question too. The more data flowing
> in & out &
> > within the organization with the same format, the easier, faster, and
> > cheaper the Price-Per-Bit for me.
> >
> >
> >
> > - A Hilton
> >
> >
> >
> >
> > > > If I wasn't given
> > > > (or had access to in another way) the definitions by my
> trading partners
> > > > of
> > > > what all those transactions/segments meant then I wouldn't be
> > > able to know
> > > > where it fit into my databases.... XML or X12 or EDIFACT or
> any other
> > > > formatting standard. So, whether it is XML or X12 doesn't
> make the fact
> > > > that you need to know what it all MEANS any different. I have no
> > > > extraordinary love of XML as a formatting standard but, then again,
> > > > neither
> > > > do I have any more love for X12/EDIFACT/etc.
> > > >
> > > Ditto here. I believe, however, that there are too many who are
> > > seeing XML
> > > as that silver bullet that I spoke about, and forgetting the
> fact that it
> > > isn't going to work by itself. It will require a major
> sea-change in the
> > > way we do business, especially for those trading partners who are in a
> > > marriage with X12/EDIFACT (whether love is involved or not is of
> > > no moment.)
> > >
> > > > I *would* like to see my major trading partners move to an
> > > internet-based
> > > > transport mechanism and get rid of this Bisync 3780 junk
> they have now.
> > > > My
> > > > support costs for that one piece of hardware/software
> outweighs all the
> > > > internet connection hardware/software costs by a factor of
> 4! I'd be
> > > > happy
> > > > with just the plain old X12 formatting but if they'd go
> with XML then it
> > > > would take two translating steps out of my loop for all of
> my various
> > > > clients.
> > > >
> > > Flexibility is the key. XML may be the next great technology
> leap, or it
> > > may enable the next great technology leap, or it may be the
> next Betamax.
> > >
> > > Whatever its legacy, let us not forget that there is a huge base of
> > > installed EDI that's been working fine for years. We don't
> want to become
> > > dinosaurs, but neither do we want to get smacked by the comet as
> > > it lands in
> > > the swamp.
> > >
> > > How would adoption of XML by your TPs take two translating steps
> > > out of your
> > > processing loop?
> >
> > =======================================================================
> > 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/
>
> =======================================================================
> 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/
=======================================================================
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/
