[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: The beginning of xslt?

Subject: Re: The beginning of xslt?
From: Ian Tindale <iandeli@xxxxxxxxxxx>
Date: Fri, 22 Nov 2002 11:40:17 +0000
original meaning of name
On Friday 22 November 2002 9:41 am, DPawson@xxxxxxxxxxx wrote:
> A few people picked up on the selection and transformation part, but it
> wasn't seen as sexy in DSSSL.

I'm intrigued as to why this is, and what the difference was then. For me, I 
find the difference between XSLT and XSL-FO is immense - one is simple to 
understand (although justifiably incredibly detailed and with a 
microscopically anal depth to it matched only by the legal profession) and 
the other simply makes zero sense to me whatsoever, no matter how hard I try 
and 'get it', no matter which way up I hold it - it contains no 'meaning', 
but in an amazingly homogenously impenetrable state. They're about as far 
apart as doing the washing up and teaching your dog to plan a lunar landing 
mission (including finding the budget). 

So, what kind of mentality would ever stumble across the 'T' part of what was 
to become XSLT and consider that it remotely has a place in a stylesheet 
language, which is after all, concerned with making your fonts bold and other 
nice harmless endevours. Surely devils invaded and changed all the plans 
overnight, one halloween, and nobody noticed the next morning and simply 
carried on with the perverted course of style.

I really take issue with the use of 'style' in the name of XSLT. It's not 
about style, it would seem. It seems more about structure. It's essentially a 
means of restructuring a document. This isn't style. I've never, as a 
designer, needed to specify a wholesale alteration of structure, as part of a 
style sheet. Style sheets occur at the phase between a designer and a 
finished artist, or between a designer and a typesetter, but generally, 
structure isn't communicated within a style sheet. Structure is decided at 
the beginning, with thumbnail sketches or marker roughs. 

However, in the current and future days of dynamic documents, it would be 
sensible to see structural alterations apply at a later part in the process - 
make the deviation into alternative structures as late as possible. This 
makes sense - use a structural specification (but don't call it a style sheet 
- it has zero to do with style) - or use many different ones, all from the 
same pool of resources and artistic materials. 

In a sense, I see XSLT as a kind of alternative phase-space-like specification 
of structure. It, on its own - unapplied - represents a completely different 
dimensional view of the journey between a document's raw materials on the 
pasteboard, and the end product on the shelves. It's that complicated - the 
kind of person who can somehow 'see' the altered dimensional space of an XSLT 
structural specification is looking in a completely different direction to 
the designer of the original document, who in turn is looking in a completely 
different direction to the customer or reader. 

XSL-FO on the other hand is an almost pedantically precise mapping of what 
things should look like (but not at page-level, rather at pre-imposition 
level). How can the same people be responsible for both XSLT and XSL-FO? 
Proof, as if any is needed, that the W3C does have contact with alien 
technology, I reckon.

Ian Tindale

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

Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.