Re: [xsl] [XSL] XSL Browser Integration

[Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>]

Hi,

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.)

Cheers,
Wendell

> 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"!
>
> Alain BENEDETTI


======================================================================
Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.                http://www.mulberrytech.com
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
======================================================================