Statalist The Stata Listserver

[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

Re: st: Creating HTML from SMCL log file including graphics - revised log2html.ado

From   Phil Schumm <>
Subject   Re: st: Creating HTML from SMCL log file including graphics - revised log2html.ado
Date   Fri, 19 May 2006 10:00:23 -0500

On May 19, 2006, at 8:35 AM, John Novak wrote:
It seems to me that the SMCL folks need to be talking to the XSLT folks. I would not even classify myself as a novice with respect to XSLT, but from my very limited understanding it would seem to be perfectly suited to handle tasks like translating code from a structured markup language into viewable HTML.

XSLT would not be useful here, since SMCL is not XML. What would be useful, if someone wanted to undertake it, would be to write an XML schema capable of representing all of the SMCL constructs. Once this was done, one could then write a utility (perhaps in Mata, but probably in another language) capable of parsing SMCL and translating it into this hypothetical XML document format. At that point, people could begin writing XSLT stylesheets to translate this into HTML, LaTeX, PDF, DocBook, OpenDocument, etc. Moreover, one could programmatically manipulate the resulting XML document to do all sorts of things.

Of course the real question is, is this worth doing? Consider three cases:

1) Using Stata to analyze and write papers. While the world would be a better place if all journals accepted submissions in an open format, I suspect that many users are submitting to journals that ask for Word format. For these poor souls, doing anything more with SMCL output would probably not be helpful.

2) Using Stata to prepare class materials, web-based instructional materials and simple reports, etc. Users doing such things might benefit from more output flexibility and processing tools, however it may be that existing approaches such as those used by -log2html-, - grss-, -do2htm- are sufficient in most cases.

3) Using Stata as part of a larger system to programmatically generate reports and other types of documents. This is where a comprehensive approach would be most useful, however users doing this have probably already put a lot of investment into established procedures, and so such an approach would have to be flexible and modular to be of value to them.

My only point is that I think a serious discussion of use cases should proceed the making of grand plans to write additional processors for Stata output.

-- Phil

* For searches and help try:

© Copyright 1996–2017 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index