Martin, the most reliable means of detecting corruption is to use some kind of cryptographic hash; this is pretty much standard in EDIINT and ebXML messaging services. The error correction protocols in the underlying transport method also ensure that information isn't garbled. To the best of my memory, we haven't seen many of the garbled transmissions you're talking about when using TCP/IP protocols like HTTP, SMTP and FTP. And what few "garbles" we've encountered have mostly been a mismatch between character sets. What the heck are you using that this is a significant problem? I don't even think I've had that many problems with Kermit!!
Nevertheless, I'll add this "deficiency" of XML (or rather is it a deficiency of your communications protocols?) to the list. William J. Kammerer Novannet Columbus, OH 43221-3859 • USA +1 (614) 487-0320 ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[email protected]> Sent: Friday, 04 February, 2005 01:21 PM Subject: RE: [EDI-L] The Ubiquity of XML - again. Every time this issue gets revisited, I find myself wondering what I'm missing. I just don't see the need to change horses (sorry) without real business benefit. I'm hoping for an epiphany this time around. I do have a slightly related question for the XML experts, though... I know all those XML parsers out there do a great job of keeping the data well-formed and validated throughout. But what happens when there is a problem during transmission that "changes" the data in a way that makes it no longer "well-formed"? We see this kind of corruption, usually related to intersystem communication, in most all the traditional EDI file types in use today. When the data gets corrupted in one of the traditional formats, it's usually a simple matter to open it and see what went awry. If an XML file is no longer "well-formed", what is the procedure for identifying the problem? (Assuming none of the XML parsers/viewers/editors are able to work with it). Many of the text editors I've used work acceptably on traditional files, but start to labor on the larger ones. They'd be brought to their knees on the same files represented in XML. -----Original Message----- From: William J. Kammerer [mailto:[EMAIL PROTECTED] Sent: Friday, February 04, 2005 7:53 AM To: EDI-L Mailing List Subject: Re: [EDI-L] The Ubiquity of XML - again. Bill, you might get me to admit that XSLT is an inappropriate means to transform XML to a printed report or flat file. Howard or I would probably use COBOL for the final report generation. But at the risk of beating dead horses, pray tell when is XML ever inappropriate for outward-facing B2B interoperability? Let's be even-handed about this: I can't even think of that many applications for which X12 or UN/EDIFACT syntax would be inappropriate, except perhaps for "real" binary data like JPEGs or PDFs. Excluding those BLOB - Binary Large Objects - cases (for which the X12 BDS or BIN, or better yet, the 102 - Associated Data Transaction Set, were designed), X12 syntax (or, for that matter, UN/EDIFACT) is perfectly competent at carrying anything from POs and Dispatch Advices all the way to oil drilling geologic data and toxicological reports. And anything X12 syntax can do, XML can do equally well - or better. The unsuitability of XML has been repeated so often and loudly (most recently by you and Andres of England), without rationale. If people believe what's repeated, I'm afraid that efforts like UBL and CICA will be ignored. We don't want that to happen. Do we? After all, even you would agree that - syntax aside - it's easier to understand what the XML element "StreetName" means when it's ensconced within "Address" within "Party" within "BuyerParty", even if you didn't have the schema. Try doing the same with the N3 segment without the standard or IG readily available. 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/
