|
[EDI-L Mailing List Archive Home]
[Message List]
[Reply To This Message]
Re: X12 sees the writing on the wall.
Having had considerable experience over the last five years implementing EDI
(and other solutions) using both ANSI X12, EDIFACT, and XML formatted messages,
I have not really noticed any significant differences in ease of use or
implementation that would favor one path over the other conclusively so far. I
expect XML formatted messages to take the lead in the future as XML
applications mature and XML-based standards for business documents are more
widely accepted. XML may also offer additional advantages as XML formatted
databases come online.
However, I still expect most large organizations will lean towards a packaged
solution for at least part of their business document exchanges regardless of
the underlying technology used to format, translate, and communicate the actual
messages. As one example, four of four clients ($5-80 billion dollar
companies) I am familiar with who implemented EDIINT AS2 selected a packaged
solution and one was a multi-billion dollar software consulting firm creating
an "all" JAVA solution for a client. They all had the expertise to create
their own solution using readily available open software tools mentioned in
this thread but all chose not to.
I further expect the half dozen sites I'm familiar with will continue to
support ANSI X12, EDIFACT, & XML formatted messages for the foreseeable future
and in many cases using traditional EDI translators or middleware to route and
translate even the XML messages. I hear foretelling of application-to-
application XML messaging but I haven't come across anyone implementing it yet
in the industries I've worked in.
Maybe my experience is not the norm but in working with perhaps 30 large EDI
clients in that last six years I have noticed that very few EDI staffs were
staffed with programmer types. Of course, maybe those sites are just the ones
that are more apt to use packaged EDI solutions or an EDI/EC consultant which
accounted for the bulk of my experience.
In conclusion, I'm reminded of one of my favorite maxims which may or may not
be relevant to this thread: When the only tool one has is a hammer, everything
begins to look like a nail.
Jim Divoky
EC Solutions, Inc.
> I must disagree, Bill, with your bit about "parsing is the easy
> part--even in EDI!" Parsing EDI is a lot more complicated (than parsing
> XML), what with all the travails involved with separators and
> terminators, elements, composites, segments and loops. This thread
> started over the problem with loops - as there's nothing inherent in the
> EDI message itself delimiting the loop, whereas XML messages can have a
> naturally hierarchical structure. The complexities of parsing and
> mapping effectively prevent most folks - even those capable of writing
> good maintainable programs - from writing EDI parsers, and are what led
> to the EDI translator industry in the first place.
>
> Imagine taking in a relatively simple 850 PO. You still have to be on
> the lookout for non-standard stuff like control characters - common
> enough - appearing after segment terminators, or serving as the
> terminators themselves. On the other hand, XML is so no-nonsense strict
> about structure and format that this loosey-goosiness never arises.
>
> Even if you're only extracting the buyer name and ship-to address, along
> with the PO line items, you pretty much still have to write a complete
> parser with full 850 capability, so that at a minimum you can safely
> skip over the ignored parts. None of this is a concern with XML, since
> with standard XSLT and XPath you can extract exactly what you want
> without even looking at what you don't need. And XSLT and XPath are
> standard - unlike the thousands of special purpose EDI parsers in home
> grown or purchased EDI systems. Though it's not so simple that any
> monkey walking in off the street can read XSLT, I'll repeat again that
> there are far more motivated folks that "do" XSLT, Java, Perl and XML
> than will ever "do" Sterling Gentran Server on some particular platform.
>
> Len Schwartz makes excellent points. If I already had a smooth-running
> EDI system in place, I wouldn't mess with it. But new stuff (read
> "opportunities") come up all the time. And if you don't already have a
> sunk investment in an EDI system, XML is well worth looking at for
> exchanges between yourself and willing trading partners.
>
> If the much-anticipated "Train Wreck" of HIPAA comes to pass this
> October, fairly or unfairly (and I believe unfairly) most of the blame
> will be leveled at complex and fussy X12. This should have really been
> labeled the "Healthcare Clearinghouse Protection Act of 1996."
> Providers, unable to "do" EDI themselves and unable to afford expensive
> EDI translators with onerous annual maintenance fees, are forced into
> the clutches of clearinghouses - the only entities who can "legally"
> convert their electronic claims into the "special" X12 read by payers.
> And clearinghouses are booked solid with conversions up to and past
> October, so the poor providers will have no recourse other than to
> "drop" to paper (claims). Imagine how much simpler it would have been if
> billing services and other business associates of providers could merely
> have cobbled together claims in XML with Perl scripts!
>
> William J. Kammerer
> Novannet, LLC.
> Columbus, US-OH 43221-3859
> +1 (614) 487-0320
>
> ----- Original Message -----
> From: "Bill Chessman" <
> To: "'New EDI-L'" <
> Sent: Wednesday, 16 July, 2003 12:57 PM
> Subject: RE: [EDI-L] X12 sees the writing on the wall.
>
>
> Paul,
>
>
> What a great example! The interesting thing is that, yes, assuming the
> text is truly stored in UTF-8 (that's the default for XML) and the
> parser is truly up to snuff (the one from IBM for Java for example), the
> parser will handle that example just fine. (Those tags are completely
> valid, and probably very meaningful for Japanese-reading people or
> systems.)
>
> Now, here's the rub: The data will go into the parser and be chunked out
> into tags and data values. Mr. Bosak hit's the problem square on the
> head: What does it mean? Wags around the globe used to claim "XML solves
> the semantic question." Um. I think I've said this in previous emails,
> but seeing the tenor of the conversation over the last day or so, I feel
> it's not inappropriate to say it again (albeit with different
> phraseology as I can't remember how I put it last time): Replacing EDI
> with XML (effectively 1 for 1) gains nothing. I'll amend that. There is
> one advantage to XML over EDI: Syntax has (theoretically) been taken out
> of the equation. That is to say, all XML documents use the one and true
> XML syntax (can't say that about X12, EDIFACT, TRADACOMS and, say, VDA,
> to name but four). So, we can get a good parser (free in many cases)
> that can parse _any_ XML document on the planet (assuming, of course,
> the XML is actually well formed).
>
> Okay, so now we have that cheap and easy solution to the parsing (late
> news: parsing is the easy part--even in EDI!). Insert XML, get tags and
> data back in a nice digestible stream. But we still have to take that
> data and assign meaning and associate it back to the application(s). XML
> has not done anything to solve that problem. One solution is to tie one
> of these free parsers to each application and voila, it's XML
> enabled...but for the SMOP (small matter of programming) to do the tying
> in. That's a different exercise but functionally equivalent to mapping.
> Oh, and there'll be a unique SMOP for each application to which the XML
> enablement must be performed. On the other hand, there's always the
> possibility that an organization could scrap all their non-XML
> applications and upgrade to or replace them with XML-enabled products...
>
> Does that mean I think EDI is king and XML is completely unworthy? Not
> at all. What I am saying is that XML used as EDI is the same as EDI used
> as EDI. But, on the other hand, there are places where EDI doesn't make
> as much sense. XSLT is a very useful tool for transforming XML into
> "human understandable" formats that are _not_important_ in true
> automated EDI environments. In fact, unless I'm mistaken the sample page
> you point us to began life as XML in Docbook format (same XML syntax,
> distinct, well-defined DTD or schema). Docbook combined with XSLT can be
> used to transform Mr. Bosak's presentation into a number of useful
> formats including HTML (as seen here), postscript printed matter and
> even RTF word processing files. That's pretty neat. It's also useful in
> other situations where EDI doesn't particularly lend itself, such as web
> services.
>
> So, if you're going to be doing XML in place of EDI, you're not talking
> about a technology shift, you'll need to take in the bigger picture, a
> (dare I say it?) paradigm shift. Frankly the use of XML might transform
> processes such as JIT (since web services could be used to do smaller,
> real-time, ad hoc JIT ordering and inventory management)...by
> eliminating the "batch orientation" that comes with EDI. So, when Mr.
> Kammerer suggests throwing away your X12 manuals, he is, in a sense,
> correct. But you'll also need to throw away the preconceptions that come
> with them. That's just one of the tough parts.
>
> Respectfully and with best regards,
> Bill Chessman
> Inovis(tm), Inc.
> (Opinions herein are mine and not necessarily reflective of my employer)
>
>
>
> To unsubscribe from this group, send an email to:
>
> Message Identifiers: <SALES>, <JOBS>, <LIST>, <TECH>, <MISC>, <EVENT>,
> <OFF-TOPIC>
> Access the list online at: http://groups.yahoo.com/group/EDI-L
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
|
 |
Subscribe in XML format
| RSS 2.0 |
|
| Atom 0.3 |
|
|
Cart
