The "simple" difference(I'm sure someone can give a more technical reason) in speed that you would see from a SAX to a DOM has to do with file size. A SAX parser will read element to next node and pass upon validation releasing the memory after it has valedated. A DOM will try and load the entire data file as an object attempting to valedate the entire file in one pass. So if you have a 100K file the DOM would probably easily and speedily handle the message. If you get to say 1M file the DOM has to allocate a lot of memory so its performance suffers. The thing about parsing is that if validation is turned on you ALWAYS end up getting 2-3 times minimum the amount of data you are loading in memory or you end up with 3-5 times the amount of data on disc. Small files never really hurt you(unless you load alot). Big files can kill you with DOM though. just a thought, John
Jim Divoky <[EMAIL PROTECTED]> wrote: Hi, Bill You bring up good issues but my current requirement is for non-standards based messages. It is for customized messages derived from a complex, proprietary data model (IBM's IAA) used in an SOA environment. It's edi but not EDI. Pruning in the middle of the branch is an option but probably not advisable. After creating messages in various ways that did not correspond in hierarchy to the source model, I realized I needed to maintain the original hierarchy as you suggest for the required elements if any semblance of traceability and repeatedbility was to be obtained. So my final messages are a subset of the source model and merely eliminate the unused elements. If at a future date, an omitted element is required or a new element added to the source model, the XML message can be regenerated with the newly required elements as it is the source model that is the ultimate authority. The XML messages are merely an output representing what is in the source model that can be used by tools which process XML data. I believe other output formats are possible. I did formal performance testing with several variations of the messages and there were indeed significant performance differences with the transformation engine I was using when it validated the data upon input. I don't know what XML parser it was using. I also believe there are significant differences between DOM & SAX parsers but I don't know enough to discuss them intelligently. Regards, Jim Divoky EC Solutions, Inc. --- In [email protected], "Bill Chessman" <[EMAIL PROTECTED]> wrote: > > Jim, > > Chiming in late on this and I have no suggestions for a tool that does > what you describe, but a couple of red flags popped up...not > recommendations, but things (maybe) to think about. > > It strikes me as worrisome that users might omit what "standardized" XML > schemas or DTDs delineate as mandatory. I fear I may be straying into > "re-beating of dead horse" territory, but that continues to suggest a > move toward totally customized messages traded after individual > negotiation with each trading partner...which leads to the questions: > is that the way XML is going to be handled in typical usage? Is that a > good idea? > > Also, being the worrier that I am, I was confused by your comment in > your response to Bryce that "an individual component is referred to as a > 'leaf.'" I'm not so concerned by the term but the implication. A > 'leaf' would be at the end of the hierarchical 'branch' meaning it > contains no sub-components. In a tree structure (particularly in XML), > most individual components are not of the 'leaf' variety and in fact, > they may each contain text data and/or other components. Some of those > hierarchies are pretty complex and sometimes recursive even. I'm hoping > that your pruning plans don't include trimming components from the > middle of a branch (unless you're also trimming everything beyond--i.e. > from there to the terminal 'leaves'). > > I personally haven't spent near enough time working with XML messages so > I haven't done any performance testing. Are the parsers really that > much slower with huge schemas? I've dabbled with some of the UCCnet > messages and the SAX parser but haven't noticed any huge performance > lags (in my very unscientific play). > > Best regards and happy new year, > 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 SPONSORED LINKS Business to business Computer internet security Training computer and internet --------------------------------- YAHOO! GROUPS LINKS Visit your group "EDI-L" on the web. To unsubscribe from this group, send an email to: [EMAIL PROTECTED] Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. --------------------------------- --------------------------------- Yahoo! Photos Got holiday prints? See all the ways to get quality prints in your hands ASAP. [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/
