Actually, XSLT is such an engine. You are telling which XML elements you want in the output, what to add between them etc. Now questions:
1) how complex your transformation is?
As long as it's close one-to one mapping from input to output, XSLT is almost trivial. But if you need to perform calculations, groupings - then it's more difficult.
2) How many different kinds of XML document do you have?
With XSLT you will have to write a stylesheet for each type. (you can reuse similar parts, but this is again less than trivial)
3) How big XML doc are?
Most if not all XSLT processor read an input document in memory as a whole, so for very large files there can be problems
4) How fast the transformation must work?
XSLT isn't very fast. There are some workarounds, though, like precompiled stylesheets.
Now if not XSLT, you can use binding frameworks, like JAXB or Castor. These will convert XML into a set of Java classes, so you can use all power of Java to output them as you want.
Thanks for the reply !
I think based on the above questions, I can decide that I don't need to use Castor or JAXB. My requirement is limited to just convert from XML to a fixed record format. So, I think I will unnecessarily introduce overhead in my application if I go with JAXB or Castor... since I really don't need to work with the data too much... just have to convert and throw it away.
The reason I am looking for something other than XSLT (some other light tool that does just conversion) is because I am having problems representing FILLERs (COBOL Fillers) in the XSLT document for non-numeric fields. XSLT provides FILLER handling if data is numeric type, but for PIC X() data (String
type), I could not find any way of representing FILLERs.
I hope I am clear on what I want... I'd really appreciate if you could help me figure this one out.