Hello all
I am trying to convert a fixed length flat file to XML.
I believe the only required information for such a coversion is- the element or field names, their data types, and the fixed length of each field.

I do not want to generate a xsl document by hand. Just looking if there are any open source tools which can help me out here.

Let me know if you guys have done this before.

Thanks
Mahesh :)

I am pretty much in same boat, but mine has little bigger scope. flat file to xml and xml to flat file and along with that there may be more formats later on. I was thinking about using Interpreter for this!!!! Am I smoking something? Anyways, for your problem, look in to jakarta digester.

there is easier solution form http://www.unidex.com/ but it isn't free

Although people sometimes deffer to XSL and other languages to manipulate/create XML, first of all consider using Java and say JDOM, the learning curve as a java developer is not so steep and I'm sure you'll find maintenance easier too.

Ian Purton
Website and Server Monitoring | Email Marketing | Website Traffic Analysis | Top 100 Album Charts

I've tackled this same problem with a bi-directional solution. Basically, I have a "model" of the legacy (fixed-length to legacy system) message. The model specifies the length of each field and the relative order. In my particular case, I also threw in shorthand for repeated structures and also some rudimentary data types.

For XML-to-legacy, I read through the model in order, selecting values out of the (JDOM) XML document, grabbing the length from the model, and pad/truncate as necessary -- concatenating along the way. I speed this up by pre-caching an XPath object in each node of the model to make selecting easier.

For legacy-to-XML, I walk the model again, this time, using the lengths to select substrings out of the legacy record and using those values as the child text of an Element named for the node in the model.

And, to make it all easier, my model is specified in an XML file that is loaded and parsed into a LegacyModel object on startup. Basically, everything is loaded, parsed, cached and ready to go as far as the model is concerned. Then I can ask the model to convert between legacy/XML.

Have a look at http://servingxml.sourceforge.net/, in particular, the Examples link.

Regards,
Daniel Parker

do you have experience about how to use it's library for EJB?

Have a look at http://servingxml.sourceforge.net/, in particular, the Examples link.Regards,Daniel Parker

Sorry, I don't have experience with that. I can see two issues.

One is that the Serving XML resources state is not serializable. The app driver would need to be shutdown on passivate and restarted on activate (see the Embed link on http://servingxml.sourceforge.net/.) If that's done, this shouldn't be a problem.

The second is that the framework performs optional caching of resources like stylesheets, and employs two threads to manage the cache. The last time I worked with EJB servers, a couple of years ago, they didn't like code in session beans creating threads.

If you're interested in experimenting, please report all issues and they will be addressed.

Regards,
Daniel Parker

This might be late compared to the date of your post.

But, one excellent approach to solve this problem is to abstrcat the nuances of data representation from the core data model of the application.The app should be writen sgaianst this data model that provides a data binding api.
In terms of implementation you may choose a dynamic data model or even a static one.

Once you do this your domain is never concerened about the exact represenattion as long as you can bind that data into your data model API.

Have a look at http://xml2sequential.sourceforge.net/index.htm.

I once implemented this package to convert sequential files to XML and vice versa. The conversion is driven by an interface definition of the message layout.

The IDL definition is based on the parameter layout description that is used by Natural (4GL language that is used mainly on mainframes), but it should not too be difficult to define the layout of your fixed-length message.

Another interesting feature is that you can modify the message since I'm using the field names to address the section within the buffer. It is a kind of data binding using field names, just you would also do with jdbc.

I'm sorry I was not able to react sooner on your request, but I do hope you can use it.

Regards,
Rudolf