|
Ben, Given a choice, I would use Java over RPG for XML. Based on what you are saying, I would look at the jdom. JDom is a fairly efficient API that will soon be part of java. You can find out more at www.jdom.org. If you do this with Java, you can always use the zip or jar utilities to shrink your files before sending via FTP. As far as DTDs, how much does your data change and how many sources for content are there? If you have a single program moving data from a database file to an XML document, a DTD or Schema doesn't buy you much. If you have many companies sending you XML markup, say PO's, it buys you a lot. Like I said earlier, I would look at JDom and Java first. If that does not meet your needs, or you are unable to use a beta product, I would look at Xerces. IBM bases their XML4J parser on Xerces (originally, it was the other way around). Xerces 1.4.4 is very stable, has been out for a long time, and works great on the iSeries. I am sure that IBM's version is just fine, but in the past it has been nearly impossible to find out what build of Xerces it was based on and what changes were made. This makes it hard to determine compatibility with other products since Xerces is the standard. I have also used JDom from within RPGIV. The code is much cleaner than code based on the procedural parser IBM provides. I have only used it on small documents (invoice and PO size) and heard back from someone that this technique is slow for very large documents. David Morris >>> asfour00@yahoo.com 01/22/02 06:50PM >>> Hi, I'm doing some research for possible XML project, and I need to clarify a few things with all you experienced people out there. 1. How do I go about creating XML document/file from a database/process. I understand I have two options, use DOM tree to build document and write it to the file at the end, or use brute force to write markup directly into the flat/IFS file (and then maybe, validate it through parser, just in case). Of course, DOM method is more sophisticated and less error prone, but my biggest concern would be size and memory requirements. It is a big project, and XML is likely to have 1 000 000s of records with 10s of nodes each. So can that fit into the memory using DOM or I'll have to write smart program to write records sequentially and ensure some degree of tag/document validity and well-formedness. Or is there some third way I have no idea about? 2. What would be the pros/cons for doing it in Java vs. RPG. This can sound as a naive question, but we are very early in the project and XML part might be made rather independent. Application is written in RPG/COBOL/SQL, but that itself is not limiting factor. General team skill set is on the RPG side, but there is a will to take this opportunity and learn. Besides, after checking a few samples of RPG using IBM's C++ parser, ... that definitely doesn't look pretty, and I'm afraid that as project progresses and requirements become more complex, we are going to regret for not starting it in Java. 3. Give me some idea about general sizing. Obviously, lots of file storage and FTP- ing will be involved. How much bigger XML file gets compared to its DB2 counterpart? In average, assuming that we aren't going to be over creative when it comes to tag names. 4. Should we develop DTDs , or take simpler route? Receiving side is out of our organization (and control), so DTD might be a safe bet. What is used for creating DTD these days? Some designing tool ? 5. If we decide to go Java, what parser is better, IBM's or independent. I have so menu more questions, but this should be enough to get me started planning. Thanks so much in advance for devoting me some of your time, Ben.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.