RE: [xsl] appropriate use of xsl?

["Hunsberger, Peter" <Peter dot Hunsberger at stjude dot org>]

> I have n number of tables, that are all very similar, but in some way
> different.  Column names may mismatch.  The date in one table me be in
> mm/dd/yyyy, while another may be in yyyy/mm/dd.
> 
> I need to display the union of these tables in a homogenous way.  That is,
> if I have a column called "order date", i need to display
> table1.order_date and table2.orderdate, and in a consistent date format.

It does sound perhaps as if XSLT is the wrong tool for this.  In particular,
I perceive XSLT as being better at the opposite type of problem; taking one
type of input and creating many different types of output.  Many of the
approaches for creating one report from many sources seem to show up in the
data warehousing arena and related (eg; DTS in the MS world).  However, if
it's just a case of formatting and standardized column names I question why
you don't just perform the needed transformation on the query side?  Eg;
"select order_date as orderdate" or vice versa?  This could be even be
parameterized and stored into a conversion table that mapped columns and
column formats to a canonical form via dynamically constructed queries based
on the conversion table. Database views also come to mind as being a
sensible way of doing this if the number of tables isn't too large.

> One idea I had was to define one standard dtd that would be the format I 
> would pass to my application.  I would create an xml file for each
> different format, and to define how each attribute would map to the
> standard defined in a dtd.  I would use xsl to do the transformation to
> the standard format, and to do the data conversion...
> 
> Summary:
> 1) convert the jdbc resultset to an xml file
> 2) create dtd for the common xml file format
> 3) create a xsl file for each of the distinct formats that I encounter to
> transform them to the common format

I can see some reasons for building a canonical data format converter using
XSLT, in particular if you don't have a transformation package in house and
don't want to purchase one. Or perhaps, as a product itself.  However, in
general, there are an awful lot of tools that already do this that make me
question the cost effectiveness of reinventing the wheel...  I'm not sure
what the DTD would do?  Since the input XML would need to be converted to
the common format you can't use the DTD to validate the incoming XML?
Depending on the input data it may be possible to do some pretty generic
templates that make the conversion somewhat trivial.  Eg:

	template match="orderdate | order_date"

but I'm still wondering why you wouldn't to the transformation in the query
in the first place...



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list