RE: XSL controversy

["Sebastian Rahtz" <sebastian.rahtz@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

Sean Mc Grath writes:
 > > > take each speakers name, pass it through a normalizer and look up
 > > > the speakers C.V. in a MySQL database. The C.V. details become part
 > > > of the generated HTML/FOLIO. The original XML is never changes
 > > > because it is quasi-legal material.
 > >
 > [Sebastian]
 > >this is a good example. you wouldn't do this today in XSL, but what
 > >about it could not be expressed in the syntax?
 > 
 > How would you express the normalization

depends on the normalization. maybe in standard XSL, maybe with an extension

 >  connection to Oracle, index lookup,
thats an implementation problem, not yours or mine.

 > error handling in XSL?
implementation detail. this in the future, not now

....
 > I guess I should not have mentioned JavaScript as it has confused
 > matters. Most of the work is in the recursive algorithm for generating
 > interlinked HTML pages to fake the appearance of a collapsible table
 > of contents. My head hurts thinking about how this could be done in XSL.

hard to say, really. but I am not convinced its an unsuitable job for
the sort of language you have in XSL

 > >I cannot quite visualize what these checks are, so I'll pass on that
 > 
 > Thinks like CALS table sanity checking. Checking that elements
 > with a #PCDATA content model actually contain text. Lots of application
 > specific checks such as (in the Parliamentary debate context) checking
 > to see that each debate has at least 1 speaker, no speaker name occurs
 > more than once per speech. That sort of thing. 

surely most of these are relatively easily expressed in XSL? I agree,
it may be cumbersome to express, so this may be a case for non-XSL

 > It is a document transformation. Forget the beowulf bits. I have
 > an XML file that references thousands of other XML files. The
 > down-translation process converts each XML file to a HTML file and
 > interlinks them into a hierarchical structure expressed in the
 > top level XML file.

now don't tell me that this is not an XSL task.... why did god give you 
document()?
 
 > I stand by all my examples as things you would not want to do
 > in XSL. I am not saying they are not possible, I am saying
 > that there are tools better suited to them than straight XSL.

In another window I am preparing some slides for a talk at XML DevCon;
I am writing them as a single XML file, and have an XSL spec to turn
them into a set of interlinked HTML pages for the talk. XSL is good
for that, yes? the right tool? But the task seems to be essentially
the same as you manipulating tens of gigabytes of Irish parliamentary
stuff. The difference is a) scale, and b) some wrapper features (like
sending email). And the scale stuff is *surely* just
implementation. If the language expresses your task nicely, your
reason for not doing it today in XSL comes down the inadequacy of
todays experimental implementations....

 > The key to getting the most out of XSL is knowing when
 > *not* to use it as well as knowing when to use it.

perhaps we should turn this round and say "what is XSL better suited
for than other languages?" just the final Web display? take XSL back
to its roots? 

I am sure we are not really disagreeing on the principles. 

Sebastian


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