There are always trade-offs for any technology or IT architecture. The trade-offs must be balanced against both business and technical functional requirements. If the **only** requirement were to be able to transmit a short concise message using as few characters as possible, then of course, X12 or UN/EDIFACT could be a logical choice. But, when - ever - was this the single and only requirement? There are a whole host of requirements. My good friend & colleague, Mike Rawlins, wrote an excellent paper (his masters thesis?) on this topic a while back. Perhaps he'd be willing to share a portion of that paper discussing this. Rachel Rachel Foerster & Associates, Ltd. 39432 North Avenue Beach Park, IL 60099 Voice: 847-872-8070 Fax: 847-589-8081
_____ From: Hurd, Richard [SLCUS] [mailto:[EMAIL PROTECTED] Sent: Friday, February 04, 2005 11:21 AM To: EDI-L Mailing List Subject: [EDI-L] <ADVOCACY> Why I Don't Like XML > -----Original Message----- > From: William J. Kammerer [mailto:[EMAIL PROTECTED] > 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. FILE-CONTROL. SELECT REPORT-FILE ASSIGN TO UT-S-REPORT01. I'm all about that. > 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. Careful, Bill, people will be quoting you out of context like I just did. :) > And anything X12 > syntax can do, XML can do equally well - or better. In the interest of fairness, I'm leaving this in there. :) > 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. First of all, I thought the whole point of XML was that you wouldn't need to read it; the style sheets and parsers and whatnot would just know what to do with it. But that brings up a different issue for me. I think you put your finger on part of the problem I have with XML... and this is my own personal discord, so it has no basis other than (a) a lingering distrust of something I can't quite get my arms around and (b) my natural predilection to have things nice and neat. The XML syntax for the above example would read something like this, would it not? <BuyerParty> <Party>Wile E. Coyote</Party> <Address>123</Address> <StreetName>Roadrunner Lane</StreetName> <City>Flat Rock</City> <State>NV</State> <Zip>12345</Zip> </BuyerParty> How about the X12 version of the same data? N1*BP*Wile E. Coyote. N3*123 Roadrunner Lane. N4*Flat Rock*NV*12345. That is... let me see... 44 characters of actual content. (Wile E. Coyote123Roadrunner LaneFlat RockNV12345) and 17 characters of "stuff" for X12 (N1*ST*.N3*.N4***.) and 125 characters of "stuff" for XML. (<BuyerParty><Party></Party><Address></Address><StreetName></StreetName><Cit y></City><State>NV</State><Zip></Zip></BuyerParty>) We have a trading partner with an odious program (that they recently retired, thank $DEITY) called "one on one." The way it worked was that one SKU was shipped per pallet if there were more than 5 cases per SKU. What that meant, essentially, was that the cube utilization of smaller orders went down dramatically, as we ended up shipping more wood to the customer than product if we couldn't combine orders on the truck. A very non-value added activity. Our argument to the customer for cancelling 'one on one' - how about the efficiencies in unloading one truck rather than two? And having to process and store all those extra pallets? The small increase in the accessorial charges were FAR offset by the other huge cost efficiencies gained in the system. Now maybe it's the puritanical spirit in me, but geez, if I'm spending damn near twice as much time, data storage and bandwidth shipping my delimiters as I am to ship my data (44 bytes versus 125 bytes), well that to me is just plain dumb. I don't care how cheap it is, I don't care how fast your data link is -- if you spent twice as much time shipping data than overhead, your throughput would double. Wouldn't it? As I said, that's just my opinion. The fact that I can read the tag within the XML data is slightly less important to me than being able to double-click on a document (say, an EDIFECS online standard) and figure out what an N1*BP is - and I have plenty of people on the business side who can do just that (not just EDI folk.) So I remain unconvinced. Sorry. [Non-text portions of this message have been removed] . 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] <mailto:[EMAIL PROTECTED]> * Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> . [Non-text portions of this message have been removed] . 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/
