[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: XSL Requirements (was: Microsoft extensions to XSL)
Hi. 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 issue. 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 application. 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 :) Regards - Guy Murphy - guy_murphy@xxxxxxxxxx - http://www.dialog.com 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 and 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 do 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 mailto:martind@xxxxxxxxxxxxx http://www.netfolder.com XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list 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
|