Re: More XSL Discussion
[Sean Mc Grath] >| >| <!-- XSL based report writer written in two seconds. Understandable >| in one second, and a lot easier to write, maintain and run than >| an equivalent perl, python, omnimark, c++, scheme, tcl, adept program >| would ever be --> >| <element type = "chapter"> >| <element type = "sect1"> >| <target-element type = "title"> >| println (...) >| >| is an abuse of XSL? [Norman Walsh] >That example is so minimal that it's difficult to say. Adding a few >wrappers for clarity, do you mean > ><rule> ><pattern> ><element type="chapter"> > <element type="sect1"> > <target-element type="title"/> > </element> ></element> ></pattern> ><action> ><text>println (...)</text> ></action> ></rule> > >Yes, that's XSL. It turns the title element in a particular context >into a text flow object containing the literal string "println (...)". > >If you've built a stylesheet that constructs some sort of a program >that you can compile, more power to you ;-) > >If you meant something else, could you please describe what you meant >in a little more detail? No I did not mean a stylesheet that writes a program via text flow objects although that might have some useful applications! I am going to have to show my age and draw an analogy with a rather old technology - RPG. RPG is an environment in which the traversal of the data set is implicit. Using RPG you do not need to hand craft the traversal mechanism-it is built in. I think of XSL as having a similar built in traversal (in this case, of an XML document hierarchy). With that built in traversal you also get a very lovely and powerful syntax for specifying *context*. My machine is positively awash with little scripts in a variety of languages that all have different ways of 1) achieving the traversal and 2) specifying context. It is my experience that the the bulk of utility SGML/XML scripts is taken up by implementing 1 and 2. (A real world example follows below) Now some of my scripts are used to generate HTML, winhelp, Lotus Notes and so on. The flow object construction side of XSL is *exactly* what I hope to use to target these output formats in the future. I am building trees. That is the way I always think about formatting. It is the way I wrote IDM. I spent a year writing a system that can take SGML, apply formatting rules and create flow objects corresponding to the capabilities of these output formats. I bear the scars of the effort! However, a lot of the scripts are utility scripts whose sole purpose is to munge XML for this sort of thing:- 1) Report Generation 2) Sanity checks (things that cannot be expressed in DTDs) I want to be able to ditch the eclectic mix of techniques used in these scripts to achieve 1) traversal and 2) specify context. Real World Example: We publish a very large manual for a company from XML source documents. As part of the process we have dozens of QA scripts. Here is an snippet of output from one of them: Part : Introduction Chapter : The Foo Manual Section : Introduction 1. The Foo Manual is a work of epic proportions...in the future. The report contains all title information for the major structural elements along with the first 10 and last 10 words of each numbered paragraph. This report is used by the client to ensure that their (Lotus Notes) database version of the data has all right bits in all the right places. The above QA script is currently in Python. The bulk of the script is simply a homegrown, proprietary combination of 1) traversal 2) context specification. The rest is trivial as you can imagine. I would like to use XSL for that. I do not mind, if, to achieve it, I need to consider the output as "wrapped" is a single output flow object called PlainText or something but I would sure like to be able to do it! Have I missed something fundamental? Am I going mad? Am I alone in thinking that XSL could be a very useful standardized way of doing the traversal/context stuff? Am I the only person on the planet with oodles of difficult to manage utility scripts that can be more more manageable as XSL. What are the possibilities? 1) Doing this sort of thing in XSL is not supported, save by proprietary extensions such as println(). If this is the case, then I think a great opportunity has been lost. 2) Doing this sort of thing in XSL will be supported but only under the banner of the creation of a TextOnly type flow-object. This is fine by me. Please don't tell me that report writing to plain text in XSL will only be possible using proprietary XSL extensions:-( [Paul Grosso] >| >it does not create an "output format," it builds a tree; it >| >is inherently object-based. It makes no sense in this light >| >to talk of half elements. >| [Sean Mc Grath] >| I don't see why this must be so. I would like to see some good >| arguments as to why this must be so as you seem to be >| suggesting. > [Norman Walsh] >What _else_ do you want to do? I don't see what you've got in >mind... > I want to generate *plain text*. I want to ditch my proprietary ad hoc apparatus for achieving traversal and specifiying context with the lovely stuff XSL provides. Unreasonable? XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format