|
[EDI-L Mailing List Archive Home]
[Message List]
[Reply To This Message]
Re: X12 sees the writing on the wall.
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)
|
|
Subscribe in XML format
| RSS 2.0 |
|
| Atom 0.3 |
|
|
Cart
