RE: XSL Requirements (was: Microsoft extensions to XSL)

Subject: RE: XSL Requirements (was: Microsoft extensions to XSL)
From: Guy_Murphy@xxxxxxxxxx
Date: Wed, 18 Nov 1998 10:34:33 +0000

Being new to the list (although I have followed the archives) I did find
myself wondering at the objection to persuing transformation within a style
language, but assumed I was missing something. It would appear that I'm not
the only one seeing transformation as integral to style formating.

Surely at a fundamental level, styling raw text is applying a
transformation to that text, the question merely being to what extent this
is extrapolated, and how complex it becomes. If I wish to render a simple
series of characters it multiple columns, this requires significant
transformation of the structure, but is most definately a style formating

Maybe I am still missing something, but with my initial dabbling with XSL I
cannot see how transformation can be regarded as less than vital to style

It would initialy seem to me that arbitary transformation ie., that which
is "hard-coded" within a flow object, or through the application of inline
CSS to well formed HTML, is often regarded as style, and self specified
transformation as some how "other". I personaly can't see the distinction,
at root we're still transforming text/data at the end of the day.

If I am amiss, I'm sure it'll be pointed out to me :)


 - Guy Murphy
 - guy_murphy@xxxxxxxxxx

xsl-list@xxxxxxxxxxxxxxxx on 11/17/98 06:47:52 PM

To:   xsl-list@xxxxxxxxxxxxxxxx
cc:    (bcc: Guy Murphy/UK/MAID)
Subject:  RE: XSL Requirements (was: Microsoft extensions to  XSL)

> Oren Ben-Kiki wrote:
> > As Didier PH Martin (mailto:martind@xxxxxxxxxxxxx) correctly
> pointed out, a
> > pattern matching language is never sufficient by itself to do general
> > structural transformations.
> Right. But then, XSL is not intended as a general structural
> transformation language. Its a style language that includes the ability
> to do some transformation as part of the styling step.
So, if the transformation part is minimal why redo an new language and not
keep and improve CSS? Is it because CSS do not use the <> tagging markup
XSL does it?
> > He's also correct in that it would have been
> > interesting to start with a procedural language (say,
> JavaScript) and add
> > pattern matching facilities to it, instead of starting with a pattern
> > matching language and adding procedural hooks to it.
> You mean, like Spice?
Chris, I tried to do a research on the Web on Spice and I got, you guess
what? hundreds of links to spice girl sites :-) Do you have any link to a
site explaining or providing download for Spice? This would help us to
understand your analogy to this language.
> > The benefits of XSL's approach is that the simple things are less
> > intimidating then they would have been in a souped-up
> JavaScript approach.
> Yes. While a programattic approach always in theory yeilds more power,
> this is rather like a customer looking to buy a wordprocesso and being
> sold a C compiler "now you can write whatever you want ... in theory ...
So, what's your point here? we should stick to style processing only? And
not address the issues of transformation? So why redo an new language if it
is nearly identical to what CSS provides?
So, to help us, understand your point of view. Explain why we should redo a
new style sheet language with minimal transformation capabilities and not
keep and improve CSS.
Have a good day and think about it ;-)
Didier PH Martin

 XSL-List info and archive:

 XSL-List info and archive:

Current Thread