Re: XML vs. EDI questions
Thanks very much, this definitely helps. My responses are interspersed. > Most EDI software does come with mapping software, but.... > > The real difficulty with implementing EDI *or* XML is getting the partners > to understand what the various segment/elements (ANSI/EDIFACT EDI) or tag > values (XML) mean "in the business context." Take an example of segment PO1 > of the ANSI 850 Purchase Order: > > PO1*00001*100*PC*2.62*CT*BP*12345~ > > In element 6 and 7 ("BP" and "12345"), the item the purchaser wants is > identified as "buyer's part number" ("BP") "12345." > > Gee that's great, but WHAT DOES THE BUYER USE FOR HIS PART NUMBER? If the > seller does not know what that buyer's part number means, does he guess? > > Contrast (?) this with its XML counterpart: > > <buyerpartno> 12345 </buyerpartno> > > Hmmm, seems to me XML has really done nothing to resolve the *business* > question. > > So a new message to be exchanged by partners needs the partners to agree on > what the meaning of the elements - or tags - means "in context." > > Sure, VANs can translate/map, for a fee, but if I have a VAN translate but > how does the VAN know what to put in the target field specified by the > seller (the VANs mapping customer)? Thanks, that's a very interesting point. I don't know much about XLink, but maybe the buyer part numbers could link to another document from the buyer explaining to what their part numbers refer. Or, once the relationship between buyer part numbers and seller part numbers is known, XSLT could be used to map between them rather than hard-coding it into an application somewhere. I've also heard it's a common problem to have undocumented fields and no one knows what they mean any more. Also, with no "authoritative" standardization/repository of XML message formats, I can see people using a lot of different tags for the same fields. Even with XSLT, people are still going to have to spend time explaining the meanings of their tags to one another. All this would make it hard for the ad hoc, automated business relationships we've heard proposed by B2B exchanges and MS with UDDI. I think there's a business-related objection to those as well; companies might use a reverse auction for their indirect goods (office supplies, etc) but they want long-term relationships for their direct goods (the materials with which they manufacture their products). > This "translation" using XSLT is, in my view, more XML hype. I think it depends. Suppose two companies use EDI and want to share data. Each maps their application format to a different EDI format. So they create a new mapping from their application format to an agreed-upon EDI format. Alternatively, suppose they each map their application format to a different XML format. So they create a new mapping between their different XML formats. Whether the second way is better depends on how hard it is for them to create new mappings from their application formats to EDI formats. One interesting XML article (http://www.ontology.org/main/papers/glushko-xml99.html) suggests that this usually requires tinkering with the application. If lots of companies did not use separate EDI translators/mappers, but actually altered their applications to make their output conform to EDI standards, then I can see how this would happen. I don't know how long it took between the appearance of EDI standards and the appearance of mapping tools - but I do know that the packaged software industry was still in its infancy in the 70s when the EDI standards came out.... > > 2. I've also read that connecting a company to a VAN is very > > time-consuming and expensive. Is this generally true? > > No it is not. It's fast and easy. (Well, it does require the prospective > user to have already invested in technology: something called a > "telephone"). Expensive? Well, there have been any number of comparisons of > VAN pricing over the years, but since pricing has been somewhat volatile of > late, I'd pick up the phone and call around to get current prices. VAN > service is essentially priced by the character, with subscriptions available > in which a fixed fee gets you so many characters per month, with an extra > charge per character for going over. (Kind of like cell phone usage or > automobile leasing). Okay. I know VANs also provide a ton of services (store-and-forward, transaction/rollback, non-repudiation) that you'd have to build on your own with an XML/Internet system. I imagine VANs will begin providing these services over the Internet to lower costs and be competitive, but the Internet obviously isn't going to kill them. > ANSI EDI also has a transaction set, the "868 Electronic Form Structure" > designed for this purpose. I've seen a couple of these used by translator > vendors to update customer systems for new standards tables, but in > eighteen-plus years working with ANSI/EDIFACT EDI I've never seen it used > between trading partners. (I work in manufacturing/distribution and > healthcare; other industry segments may use this transaction set). > > XML DTD's (schema) serve the same purpose; but neither IMPDEF format or 868 > or DTDs address the underlying business questions. True, and that's a point I intend to bring up - schemas will save you from having to hard-code some of the really basic validation, but you've still got to determine if a requested part number is valid, in stock, etc.
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format