Re: [xsl] [XSL] XSL Browser Integration

Subject: Re: [xsl] [XSL] XSL Browser Integration
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Mon, 17 Sep 2007 13:01:44 -0400

At 05:15 AM 9/16/2007, Alain wrote:
I have in mind several use-case where XSL gives you a *BIG *bonus
when used client-side compared to other existent technos, but these
use-case would be irrelevant if they were an obvious reason why XSL
should be mostly server-side... And I don't want to bother you
with irrelevant things!

My guess is that any such "obvious reason" why XSL should be limited to any single architecture, however defined, would be fairly easy to counter with a simple case making different assumptions about requirements.

In my experience, XSLT (given the current state of technology) runs in three types of architecture:

1. Batch
2. Server-side ("thin client")
3. Client ("thick client")

Plus, of course, hybrid variants.

But examine this and you find the distinction is only meaningful as a representation of a spectrum: at one extreme, processing is asynchronous; that is, its timing is determined by the originator. At the other, timing is determined by the receiver. At one end, resources are allocated by the originator; at the other, by the receiver. "Server" in this sense is a mid-point between "batch" and "client" -- an architecture in which the originator devotes resources in order to respond more dynamically than batch, while still addressing requirements on the client for a particular application profile (e.g., for reaching older browsers).

In short, I don't see either/or choices; I see tradeoffs. For simple or lightweight applications, any architecture may work fine, and other considerations such as available resources or opacity/transparency may be the deciding factors.

I've seen server-side applications installed simply as a convenient way of implementing a batch solution, by using the server's caching and request handling to manage updates. Conversely, many of the problems related to client-side processing (including client-side processing of Javascript) can be ameliorated using just a touch of server-side sniffing and customizing. (Not that I'm a fan of that sort of duct tape; but it can do the job.)


So let's summarize opinions & main reasons:

Scott Trenda says Mostly server-side (unreliable on client-side)
Robert Koberg says Both sides (+ must use other techno, so better
browser integration is low priority)
David Peterson says Both (+ needs better browser integration)
Alain Benedetti says Both (+ browser integration is high priority)

Correct me if I misinterpreted your thoughts, and don't hesitate to give your opinion on the question!

And sorry if a question with "no code" looks quite unusual here! /[Oops, is that trolling?] /Personally, when I manage to understand the "philosophy" that's behind the scene I make bigger steps than looking at some code (which is still useful to get good ideas), such as the example with : "Think loops run in parallel" was a giant step with "no code"!


Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.      
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
  Mulberry Technologies: A Consultancy Specializing in SGML and XML

Current Thread