Bill, right on the heels of your posting comes this plea from _AB:
"Hi- Can you please help me with the syntax in AI of gentran,
how to test a datetime element is blank."
Now tell me that "parsing [is] the trivial part of the equation." This
is a parsing question, plain and simple, as all of these Gentran
specific questions invariably are. I don't think these people ever get
far enough to worry about "what data (once it's been isolated by
parsing) goes where in the application."
It's not to say that folks wouldn't have problems parsing XML, but there
are fine mailing lists and resources all over the place for posting or
researching questions on how to operate Java, SAX, DOM, XSLT, Schema,
XPath, etc., shared by people in all disciplines. This would go a ways
in freeing up EDI-L for discussion of the "big picture" e-business
interoperability and standards issues.
I've never said XML is a simpler syntax than those of X12 or UN/EDIFACT-
it's just far more ubiquitous, with vast implications for cost-savings
and improved management. This ubiquity is illustrated by the following
quote:
"I've also found that many employers have stopped listing XML
in their advertisements, not because they don't need that skill,
but because they assume that working with XML is something that
you should just know if you work with most computer languages."
-- Kurt Cagle, author, on the xml-dev list
William J. Kammerer
Novannet
Columbus, OH 43221-3859 . USA
+1 (614) 487-0320
----- Original Message -----
From: "Bill Chessman" <[EMAIL PROTECTED]>
To: "EDI-L Mailing List" <[email protected]>
Sent: Tuesday, 01 February, 2005 12:48 PM
Subject: RE: [EDI-L] XML Hierarchy Question
William,
I fear my point (probably overly simplistic) has been obscured in the
discussion. (On the other hand, maybe I just don't get it...)
My overriding point is that examples that illustrate a straight
one-for-one EDI to XML conversion mean exceedingly little since the
primary bugaboos of EDI are really not solved. Though I don't "laugh
away the parsing problem as trivial," I respectfully regard the parsing
as the trivial part of the equation. Perhaps there is a terminology
problem. The *parsing* of EDI is a strictly mechanical and predictable
operation that frankly doesn't require an expensive translator (in fact,
the syntax of EDI is arguably a little simpler than XML). To me,
*parsing* is just getting at the data. The magic part is the
*translation* which figures out what data (once it's been isolated by
parsing) goes where in the application.
Far be it for me to suggest XML is a bad idea. It definitely can
replace much of what EDI does, but it's not a drop in replacement, it's
(dare I use the clich�?) a paradigm shift (I dare, I dare!). Your
examples illustrate that very thing.
Respectfully submitted,
Bill Chessman
Inovis(tm)
-----Original Message-----
From: William J. Kammerer [mailto:[EMAIL PROTECTED]
Sent: Monday, January 31, 2005 3:59 PM
To: EDI-L Mailing List
Subject: Re: [EDI-L] XML Hierarchy Question
Bill, I myself have asked the same question: "what's the point?" The
intent of mechanical EDI-XML conversion isn't to "bulk" up the data for
transmission over the network just for the heck of it. The same old EDI
is sent between companies. But once it's received, it can the be "blown
up" into XML using, say, Bryce Nielsen's xmlLinguist. Yes, "one would
still be faced with all of the old problems that have dogged
EDI...semantic content remains", and on and on. But at least the
*parsing* problem goes away - or at the minimum it can be done without a
$50,000 translator (where the only support you can find is by bugging
folks on the EDI-L mailing list). That's the theory, at least.
Don't laugh away the parsing problem as trivial. Perhaps upwards of 80%
of inter-company bulk data transfer is non-EDI (in the X12 and EDIFACT
sense). Most of it is flat files, comma-delimited records, and stuff
like that. None of that stuff is going to be turned into classic EDI,
even if X12 and EDIFACT got busy devising messages for each and every
possibility.
But it's conceivable that if we e-business folks devised a workable
framework for core components implemented with XML and schema, then
perhaps the non-e-business folks would see the merit of following in our
footsteps, and take all their data (anything from oil drilling geologic
data to toxicological reporting) and do the same. With almost 100%
certainty, I can state that these other data sets will **never** be
encoded in classic EDI. If we couldn't convince them before to use X12
or EDIFACT, we're certainly not going to do so now (since everyone has
heard of XML).
Let me tell you a short story. I had some chunks of data once, encoded
in ASN.1 BER and described by an ASN.1 specification (much like an XSD
schema). When I told the programmer at the other end what to expect, he
was not in the least perplexed. He vaguely knew of ASN.1 and even heard
of the freeware SNACC routines for parsing the data. That's the last I
heard from him regarding the syntax, and I confirmed that he was able to
read the data relatively effortlessly. Mind you, ASN.1 is not at all
common, but there's a heck of a lot better chance that the random
programmer on the street is going to at least have heard about ASN.1,
more so than the X12 or EDIFACT syntaxes. This was complex recursive
data which would not have been suitable in some comma-delimited format,
by the way. I'm not advocating ASN.1, as anything you can do in ASN.1,
you can do in XML better.
By the way, with ebXML core components, you're not limited to
implementing the physical data in XML - even ASN.1 encodings can be
used. The same core component models used to build the XSD schema were
also used to generate the ASN.1 specification! See Appendix F
(Informative): ASN.1 Specification, at
http://docs.oasis-open.org/ubl/cd-UBL-1.0/. Amazing, huh? Try to do
that with X12 or UN/EDIFACT.
William J. Kammerer
Novannet
Columbus, OH 43221-3859 . USA
+1 (614) 487-0320
.
Please use the following Message Identifiers as your subject prefix: <SALES>,
<JOBS>, <LIST>, <TECH>, <MISC>, <EVENT>, <OFF-TOPIC>
Access the list online at: http://groups.yahoo.com/group/EDI-L
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/EDI-L/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
