You hit the nail on the head. To my knowledge, there aren't any fast (ie.
C++ or some such) processors in conformance to the spec. But that misses
the point: Transformations should *absolutely* take place on the client
side for several reasons:

- from an idealist's standpoint, having the pre-transformation xml on the
client side maintains the semantics of the original data, and in the case
of a lossy tranformation maintains the data itself as well.
- from a pragmatist's standpoint, there's no reason those valuable
processing cycles shouldn't be split up between the clients requesting the
data, because a server's job is to serve data as fast as it can.

The flow of control Sean proposes for dealing with things given current
technology is fine (I can't think of a better way of dealing with things),
but misses these two pretty key points...

Dan

On Tue, 26 Oct 1999, Lou Colon wrote:

> It has been my experience that XSLT (tested with various transformers) can
> be a bottleneck on a high-volume web/app server.  The combination of XML and
> XSL to generate HTML on a server can take about 1 second.  This makes it
> difficult to handle millions of page requests daily. Thus, it would be ideal
> to let the client do the transformations, rather than the server. This
> distributes the required processing much better.
>  -lou
> 
> ----- Original Message -----
> From: <zun@xxxxxxxxxxxxxx>
> To: <xsl-list@xxxxxxxxxxxxxxxx>
> Sent: Tuesday, October 26, 1999 4:50 PM
> Subject: Re: XML/XSL on the client for dynamic UI
> 
> 
> > Hi Olivier, everyone,
> >
> > On Tue, 26 Oct 1999 oberthier@xxxxxxxxxxxx wrote:
> >
> > > Maybe to rephrase the idea, the flow of the application would be
> > > something like this:
> > >
> > > 1. On the server, the XML data file is prepared from the content
> > >    of several RDBMS table.
> > > 2. The user receives in its browser this XML document and a way
> > >    to render it.
> > > 3. The user then enters the data he wants into various fields
> > >    (each of them having its own validation and event handling,
> > >    for instance implemented in JavaScript if we keep the
> > >    browser idea). All those changes are automatically updating
> > >    the XML document locally.
> > > 4. When finished, the user is submitting the updated XML data
> > >    back to the server which will update the database tables
> > >    accordingly.
> > >
> > > My current interest is mainly on steps 2. and 3., 1. and 4.
> > > starting to be easy to address on an application server, or at
> > > least people are obviously working on it at the moment (see the
> > > recent XML server debate on this list).
> >
> > I don't see any problems on doing 2 and 3 with XSLT.  The major roadblock
> > is that none of the major browsers have an up-to-date XSLT implementation
> > yet, but that can be circumvented by using it on the server side.
> >
> > So for today, you'd have to do something like:
> >
> > 2. Server generates HTML+Javascript from XML data file using XSLT.
> >
> > 3. User enters data, Javascript posts back to server
> >
> > The loss here is the transmission of the raw XML data in step 2.  But you
> > can rectify that by providing another URL for it on the server.
> >
> > I'm not saying step 2 is easy mind you =)  If you want to work on the
> > Javascript code, I'll help with XSLT.  Definitely would be an interesting
> > project.
> >
> > . . . Sean.
> >
> >
> >
> >
> >  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> 
> 
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> 


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