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) -----Original Message----- From: Bryce K. Nielsen [mailto:[EMAIL PROTECTED] Sent: Saturday, January 29, 2005 11:24 PM To: EDI-L Mailing List Subject: Re: [EDI-L] XML Hierarchy Question > Bryce, am I to assume you're saying one can't have multiple XML > documents, seriatim, in one physical file? This isn't a programming > question, as this isn't a programming mailing list, but I was supposing > there might be some way to use SAX or DOM input streams and exceptions > to force multiple documents in through the same file. Even if not, you > can always package separate XML documents in multiple MIME containers > within one sequential file. > Correct. For an XML document to be valid (i.e. well-formed) it must contain one, and only one document level element. If you had more than one, you would not be able to use any standard libraries to parse it. All SAX/DOM parsers that I know of would throw an exception once it found that second document level editor. You would have to write your own parser that allowed multiple XML documents in one file. Wrapping multiple documents in MIME containers makes it no longer an XML file, it's a MIME file, so you introduce another layer of parsing (which may or may not be acceptable, depending on your circumstances). > I just wanted to make sure that someone reading your e-mail doesn't run > to some suit with this "deficiency," causing all interest to dry up for > gussied-up UML-modeled core-componentized ISO 11179 compliant XML based > e-business standards like OASIS UBL. > Not sure how my post would be taken in that context. What I was trying to infer was that if you're moving an EDI document into XML, a hierarchical nesting of nodes is a very desirable thing. Particularly if you have one file with multiple EDI documents. This was one consideration in our EDI-to-XML product xmlLinguist. The document level node in a translated file has nothing to do with the EDI file being translated, it's merely a container with a user-defined name. Each ISA segment is then a child node directly off of this node. For example, you would see something like this: <MyEDIMap> <ISA> <!-- fields --> <GS> <!-- etc --> </GS </ISA> <ISA> <!-- fields --> <GS> <!-- etc --> </GS </ISA> </MyEDIMap> The point being that now each ISA node contains all the segments for that particular EDI document. The GS/ST/etc nodes are all child nodes of the ISA node. So, if a second ISA is found, it's children won't be confused with the first ISAs. HTH, Bryce K. Nielsen SysOnyx, Inc. (www.sysonyx.com) Read our latest EDI/XML tutorial: http://www.sysonyx.com/xml-to-edi-850 . 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/
