Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

What are my options ??? - Urgent help needed

 
Himanshu Jhamb
Ranch Hand
Posts: 134
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All.
I am facing a problem of how to go about designing a certain task for my app. The task is simple - need to convert data in my app. from XML to a fixed format cobol kind of record.
From where I stand, I can think of two options -
1) Develop my own custom library with object representation of data.
2) Use some kind of a mapping engine/tool which based on a template defining the input/output mapping, can convert from one format to another.
I am more inclined towards Option #2 since the life time of my objects in option #1 will be very less ... so not a good option since a lot of objects would be created and GC'd in memory in very short time.
Keeping that in mind, one option I have is use XSLT ... my knowledge is limited as far as how many more tools Java provides to this kind of a thing. If anyone has used something effectively or can suggest something that would be of help, I would really appreciate it.
Need some urgent help on this, so any quick suggestions would be great...
thanks
- Himanshu
 
Mapraputa Is
Leverager of our synergies
Sheriff
Posts: 10065
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
2) Use some kind of a mapping engine/tool which based on a template defining the input/output mapping, can convert from one format to another.

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.
[ June 24, 2002: Message edited by: Mapraputa Is ]
 
Himanshu Jhamb
Ranch Hand
Posts: 134
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
thanks
- Himanshu
 
Mapraputa Is
Leverager of our synergies
Sheriff
Posts: 10065
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Um... Are fillers fixed-length strings?
I found an example on the Internet:
FILLER PIC X(33) VALUE 'RESCHECK NON-BLANK STATUS - REC: '.
So what it means, the output must have 33 symbols with precisely this value?
 
Himanshu Jhamb
Ranch Hand
Posts: 134
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes Mupra, thats what it means. Sometimes, it may not have any VALUES clause & it is filled with spaces.
Now, we have a couple of options -
1) Find some way in XSLT itself, on how to handle these alphanumeric fillers
2) Parse the input second time, padding spaces wherever there is a FILLER in the Template (defined with the COBOL mapping). This would require writing additional code, of course.
Ideally, I am looking for 1st option to do this since it would be very cleanly taken care of within the XSLT engine. I am a bit critical on doing it as in option 2) because it would mean additional coding & maybe creating more objects in memory for every request that we process.
Any ideas on how I can do this with XSLT ???
Thanks for all your help, I appreciate it.
- Himanshu
 
Mapraputa Is
Leverager of our synergies
Sheriff
Posts: 10065
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I do not have time to test it right now, but here is something that looks as possible solution:
http://www.dpawson.co.uk/xsl/sect2/N3751.html#d132e126

This seems work:

on input
<?xml version="1.0"?>
<someElement>a string</someElement>
<xsl:variable name="long_string_of_blanks"> *</xsl:variable>
- it doesn't work without "*" , not very elegant, there must be better variant...
[ June 25, 2002: Message edited by: Mapraputa Is ]
 
Himanshu Jhamb
Ranch Hand
Posts: 134
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi.
Ok, I could understand your code till the point that I could get the number of spaces I have to append to the actual value of the variable.
My goal is to append (or prepend) 'x' spaces to a field where 'x' is given by the formula -
x = (fldlen - actlen)
where fldlen = Length of Field as defined.
actlen = Actual Length of Field in the input data.
For example, consider, the following input XML
<CUSTOMER-REC>
<ID>CR12345</ID>
<NAME>Himanshu Jhamb</NAME>
</CUSTOMER-REC>
Consider the following XSLT ( I am only presenting the relevant lines )

- In the above code, the <HJ-DUMMY-VAR> comes populated with 'x' number of spaces, my question is how do I concatenate or prepend these spaces to my original value of <ID>.
Hope I am clear in what I am asking.
Thanks for all your help.
- Himanshu
 
Mapraputa Is
Leverager of our synergies
Sheriff
Posts: 10065
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You didn't define your "Length of Field as defined"
If you declare it like for example
<xsl:variable name="desired_len" select="20"/>
then to concatenate spaces to the value of id, you simply write both variables in the output:
<HJ-DUMMY-VAR><xsl:value-of select="substring($spaces,1,$desired_len - $id_len)"/><xsl:value-of select="$id"/></HJ-DUMMY-VAR>
 
Himanshu Jhamb
Ranch Hand
Posts: 134
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for that !
Another question, is there any other product like XSLT that is specifically made for handling
XML - COBOL - XML mapping ? I am sure such a product would take care of the FILLERs pretty efficiently as well.
I tested the examples above in this post and they all take quite a lot of time & that would be unacceptable for a production app. If I go the XSLT way, I have an option of either calling some static java functions from inside the XSL to take care of the padding stuff.... OR .... parse the input a second time using a java class.
Any suggestions.... ???
Thanks
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic