Newsletter Purpose: This is the periodic newsletter of Zetein Inc. offering insights into current standards and technology topics. This letter also serves as a means of staying in touch with you. Here are the major topics covered this edition:
I had several readers request that I add previous newsletters to our website. I have done this and you can get previous nrewsletters at the following link Newsletters
There are three variables in any project; cost, quality and time, For any project you can absolutely fix a maximum of two of these variables.
During the late 1990s quality and time were fixed. Companies worried about lawsuits on the 2000 doomsday if their systems failed. So, most companies threw caution to the wind in hiring “Year 2000” consultants to assure that their systems would not fail on January 1, 2000. This greatly increased their development costs so they could meet the deadline with adequate quality.
As soon as 2000 passed without many problems and the economy turned down, companies went into a mode of reducing costs. Over the past few years projects have either taken longer than desired, finished later than originally planned or were of a dubious quality.
Companies asked their workers for more production in the same amount of time (or overtime with no pay). Many people are ready to leave their perceived oppressive environment as soon as the market eases. The reality is that most companies have also been pushing their workers and there is no eden to go towards. Increased productivity can only be pushed so far. A change is near.
We have experienced a breather in new financial product introduction or legislation that would usually have fueled application tremors in the past.
Many systems are getting very much out of date. The push to more web enabled applications is becoming more of a competitive factor. The move from mainframe technology to web based technology is gaining momentum.
As your company gets pressure to change systems, which of the three factors are you going to strive to control (remember you only get two).
If you would like me to discuss this topic in more depth or other topics in future newsletters, please let me know.
Many people did not receive the last issue of this newsletter since I included a simple Visual Basic example in the body of the newsletter. Many mail servers thought it might be a virus and blocked it. I only found out about a few. So, I have added a section on my website containing past newsletters. Here is a link to it Newsletters
During the last several newsletters we have been exploring different methods of processing XML data streams. We first looked at XSLT. Then a simple Visual Basic program using DOM was used. This newsletter explores some basics of SAX processing using Java.
To avoid the virus detection problems, here is a link to the Java program: Java SAX
Download the program and compile it. I used Java 1.4.1
As input the program uses the same XML file we used in the previous letters. The name is NameSample.xml.
All sample programs and the input file can be downloaded using this link All File Link
You will notice that SAX is the most code intensive of the samples. Using SAX, you are called to process each element. In fact, you are called multiple times for each element.
The “startElement” method is used to store the element name being processed. The local variables are reset when each new Party element is processed.
The “characters” method is used to store the actual data from the element in a temporary variable.
The “endElement” method moves the actual data from the temporary variable to local variables for later use.
The “doOut” method is used to display the results. It is executed each time the party changes and at the end of the document.
You will notice that in XSL, you indicated what elements to use and what output to produce. The XSL transformer did all of the processing (most use a SAX like process internally). In DOM, you stored the XML stream in a document and then retrieved elements you needed from the document as desired. In SAX you have to store any element needed as it is processed and then use it later.
Whether to use Visual Basic .NET, C#, or JAVA is a matter of preference. Each has its advantages and disadvantages.
In the next newsletter we will explore what criteria ( other than the basic differences discussed so far ) should be used when deciding whether to use XSL, DOM, or SAX.
If you would like me to discuss this topic in more depth or other topics in future newsletters, please feel free to contact me.
Zetein provides consulting services to implement ACORD and IFX standards projects you need done. We can help in many ways; training your developers, design tasks and implementation.
We have extensive experience in insurance, XML, ACORD,and IFX standards.
Visit our website (http://www.zeteininc.com/) for more details, then please call (469.374.0984) or email me ( jmeagher@zeteininc.com) to explore how we can help with your ACORD project.
Thanks, John Meagher
▲ Zetein Inc BX 741083 Dallas TX 75374
If you do not wish any future emails, please reply to this email with "Remove" in the subject line.