XSL: Why?

[Tyler Baker]

"Simon St.Laurent" wrote:

> I'm writing a chapter on styles - just a brief overview, since the book
> doesn't deal with generic presentation issues very much - and I've come to
> something of an impasse.
>
> I can't really see where XSL fits usefully into the XML developer's tool
> kit.  I thought it was more capable than CSS, until I read the CSS2 spec in
> depth and figured it had moved from covering 70% of design needs to
> something more like 90-95%.  I'm finding it very hard to justify using XSL
> rather than CSS for most of the situations I'm describing.
>
> This may be the result of my background in Web development, rather than
> SGML, but I can't see what's so intrinsically interesting about using a
> transformative rather than a descriptive style language that it rates a
> competing spec and has many people (notably Peter Flynn on XML-L a while
> back) waiting for XSL rather than working with CSS now.
>
> Would anyone care to evangelize XSL to a rather confused and somewhat
> dispirited XML evangelist?  (I wish I had Frank Boumphrey's book now...)

If you think that the entire future of the internet rests upon the lowest common
denominator technology of a web browser, then you are probably right that there
is no reason why XSL would ever be more useful than CSS.  I in particular have a
product I have been working on that I cannot speak too much of at the moment
which could be considered as a technology replacement for much of the
functionality of a web browser and does much much more.  XML plays a very large
role in the application as it is currently written in Java and we do not want our
content bound to something as inflexible as Java object serialization in case we
want to write our application in a different language at a different date.  XSL
at the moment does not play any currently implemented role, but I forsee that it
will be something we actively support as separating abstract content from
presentation content I believe will become a mainstay of application frameworks
for the web.  The best thing we have right now that I have seen is Cold Fusion.
This primarily is only a server-side solution and costs a lot of money.  XSL's
strength I feel will be on the client side as all that a web server will need to
do is present easy to construct XML content at the server level, and then fetch a
stylesheet for the particular user (which could be customized via some sort of
profile).  The content viewer which may be an HTML browser then can do all of
this processing on the client machine rather than bog down the server with
complicated content presentation processing.

The original idea of Java (which I still fervently believe in) is that its
strength is on the client since you can transfer a lot of the processing from the
server to the client in a distributed fashion (means you need to spend less on
servers and programmer salaries to manage those servers).  XSL I believe also
will fit into this concept as it will reduce overall business costs of running an
up to date, dynamic, and attractive web site by transferring a lot of the
processing to the client (without the needs of JavaScript) as well as open the
door to many new kinds of internet content viewing software.

Tyler


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)