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.
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
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'?
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.
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
or from the complete Transformer
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.