Skip to main content
Last updated May 05, 2012 17:22, by berhauz
Feedicon  

What is ReverseXSL ?

ReverseXSL adds a anything-to-XML Transformer class to the java native XML-to-anything XSLT Transformer class.

Hence, basically, reverseXSL is a .jar (java archive) file that you add to the classpath of your java projects in which you considered using XSLT as mapping engine, yet discovered that you lack the ability to parse non-XML data.

With ReverseXSL plus XSL (now part of any JDK), you have in hands a any-to-any Mapping Engine (CSV,EDIFACT, X12, TRADACOMS, Flat Files, IATA, SWIFT,Text, Fixed records, ...and of course XML)

A command line program is also available, that actually demonstrates the use of the reverseXSL Transformer API at the same time. Parsing meta-data and Mapping meta-data are respectively held in DEF files and XSLT files, which can be made available on the ClassPath for runtime loading through the classloader.

Design Background

Have you once thought to use XSLT for a flat-file to XML transformation with the idea that it would be almost as magical as the XML-to-anything developments you formerly achieved? You may even have looked for a secretly hidden <xsl:input>(?) method and XSL functions that you haven't used before and that would hopefully provide the solution but... we have to acknowledge that beside framing your entire file with

  <tag>..myFile..</tag>

and using substring() extensively... oups!

This is not a functional hole in XSLT, but the consequence of a very consistent design orientation hooked to the nature of the input as a tree of nodes. An input flat file is not a tree; at most a single big node. We have to build the tree... XSL and ReverseXSL complement each other Equipped with both XSL and reverseXSL capabilities, you can generalize the Transformer class to handle any-to-any traffic, and even let it determine dynamically which mapping profile to apply to which input. You drop XSL-templates and reverseXSL-DEF files on the classpath, update the mapping decision table, and without programming changes, your application can take advantage of new data transformations.

Parsing a flat file, EDI file, CSV or text file on the one hand, and processing a tree of nodes (an XML document) on the other hand are very different jobs by nature. A sister article explains the fundamental difference. The reverseXSL software basically contains an original Parser component, dedicated to organizing the four tasks required to build an XML-document tree from input data melted in repeating and nested character-based structures, namely: identify, cut, extract and validate.

Just like the XSLT processor using meta-data in the form of an XSL file for getting instructions about the XML-node transformations to perform, the reverseXSL parser uses a so-called DEF file containing details about the input syntax enhanced with meta-data for the construction of the target XML document. The reverseXSL parser is much more sophisticated than inserting '<..>' and '</..>' elsewhere in the input file for the claim to call it XML. Instead of getting something like:

  <item>
   <1>C</1>
   <2>54-12345-00007</2>
   <3>LENS</3>
   <4>12</4>
   <5>BX</5>
   <6>2350</6>
 </item> 

You shall expect:

  <LineItem status="Confirmed">
  <SKU>54-12345-00007</SKU> 
  <Name>LENS</Name> 
  <Qty Unit="Boxes">12</Qty> 
  <UnitPrice>23.50</UnitPrice> 
 </LineItem> 

The parser will readily generate the format that you need, or, in some cases very close to.

Why only 'very close to' in some cases, and which 'cases'?

We were very much concerned by not duplicating XSL functionality with the risk of pushing complexity into the Parser for tasks that are very easily achieved in XSLT. The 'case' is then simply that the Parser does not re-order elements, and does not compute data (e.g. the total price of all article items). The Parser can flatten hierarchical structures as well as increase nesting levels, it can hide elements in XML or make new groupings that are implicit in the input message, it can supply default values and even map codes, but it does not re-order elements, neither computes new values from original data beyond splitting, filtering, catenating. Therefore, next to the Parsing step, the reverseXSL Transformer may invoke an optional XSL transformation step as required by the selected mapping profile in order to execute such tasks.

The reverseXSL Transformer software can execute a Parsing step alone with a given DEF file, or the XSLT step alone with a precise XSL template, or else it performs both steps in sequence before returning the output, as illustrated in the figure.

Such flexibilty opens the possibility of delegating to the reverseXSL Transformer the task of selecting a mapping profile that matches the input at stake. A mapping profile contains by definition a pattern identifying the input brand with instructions for performing the Parsing, or the XSL Transformation, or both, or even no mapping at all. The name of the selected mapping profile is also returned, allowing to branch to diverse application processing areas according to what has been received, and possibly mapped.

Java API and Command-line interfaces

The reverseXSL software extends JAXP (the Java API for XML Processing) with a pair of classes com.reverseXSL.transform.TransfomerFactory and Transfomer just like the javax.xml.transform.TranformerFactory and Tranformer. The new Transformer is capable of transforming any character-based data into XML in addition of the XML-to-XML and XML-to-any capabilities of XSLT alone.

In addition to the java API, the reverseXSL software contains command line programs (running on Windows, UNIX, MacOS and other operating systems with a suitable java runtime) that invoke file-based mappings from the Parser alone

 Parse ..args..

or from the complete Transformer

 Transform ..args..

The java source code of the command-line programs is always included in the software distribution archive (.jar) as an example of using the APIs, and for customization of the command line tools.

 
 
Close
loading
Please Confirm
Close