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 ----- Original Message ----- From: "Bill Chessman" <[EMAIL PROTECTED]> To: "EDI-L Mailing List" <[email protected]> Sent: Monday, 31 January, 2005 12:44 PM Subject: RE: [EDI-L] XML Hierarchy Question While the points made about XML below (ie., one XML root document per file, the hierarchy questions, etc.) are quite correct, it always troubles me to see examples that at least suggest a one-to-one mapping between an EDI document or interchange and XML. If that's all that a given product can do (reformat the EDI into pretty "human readable" bits), I must ask, yet again, "what's the point?" Assuming that someone actually did such a transformation one would still be faced with all of the old problems that have dogged EDI...semantic content remains unclear, coded fields remain coded and their respective meanings are those of the Trading Partner (not necessarily in alignment with the standards themselves), to name just two. On top of that, you expand the size of the data (I expect disk drive manufacturers have no problems with that). The task of getting the data from the documents to the application remain the same (some sort of map must be created). Maybe I haven't been paying attention, but I thought the point of XML was to foster interactivity with shorter messages that work much more like a dialog. (I think that's one of the goals of ebXML and WebServices...in fact, ebXML and RosettaNet both use MIME wrappers around their XML data, don't they?) Although there is also Interactive EDI, it still hasn't taken the world by storm, so the vast majority of EDI remains batch oriented. Sure, I understand that SAX is very easily obtained, inexpensive or free, and pretty easy to use (I have used Java versions of SAX on numerous occasions). Sure, I understand that using XSLT you can reformat the XML data in an assortment of ways. From a user perspective it sure is nice to see all that icky data presented in a pretty HTML format in your browser, but the point of the EDI (which XML seeks to--and may still--replace) is to transfer data from application to application. Sure, I also understand that you can use XSLT to reformat the data so that it can be fed into your application (back in the olden days, we called that process "mapping"). Okay, I guess I've been ranting a bit (gee, I don't think I've ever done that before! 8-) ). In summary, if EDI is so objectionable that we need to move toward XML, we need to think more about the process than the format of the data. Best regards, Bill Chessman Inovis(tm) . 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 . 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/
