Re: More XSL Discussion

Subject: Re: More XSL Discussion
From: Sean Mc Grath <digitome@xxxxxx>
Date: Thu, 26 Feb 1998 09:45:19 GMT
[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
><element type="chapter">
> <element type="sect1">
>  <target-element type="title"/>
> </element>
><text>println (...)</text>
>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

Part : Introduction
 Chapter : The Foo Manual 
  Section : Introduction
   1. The Foo Manual is a work of epic 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

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

[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

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.


 XSL-List info and archive:

Current Thread