So write FRXtoXSL!

(lol)

>>It should be possible, Mike, but I agree with your "why?" comment. I just don't consider a direct port from FRX to XSLT something anyone would want to do.
>
>Well, I can see the benifits. But before anything, the data istelf needs to be converted to XML. That brings to the table its own set of issues but with its own benifits. After that, you can use XSLT to transform the XML into another format. I suppose the real value of XSLT depends on what are transforming your data into and wether or not preparing the data and creating the XSL saves you enough work to make the whole thing logical. Thats alot of work to print a report.
>
>But, if you do it cleanly, you'll end up with a user definable format (if you expose your XSLT) to create any text based ouput that can even be shown in a browser accross the nets.
>
>To me, those are not huge advantages, considering most of the desired outputs are not textbased, namely, PDF and DOC. However, I see this as a hurdle that may be overcome in 2002. You see standards like XSL-Formating Objects that have the potential to go head to head with PDF and software like StarOffice creating Office documents using file formats based completely on open XML definitions.
>
>I think this year will bring a slight change in the ways that most businesses use the printed and electronic documents they get from our apps, which means that we'll need to be ready to create open and flexible outputs. Though, I don't honestly see XSLT playing a critical role in this process.