RE: [xsl] xsl:sort in old MSXML

Subject: RE: [xsl] xsl:sort in old MSXML
From: "Claudio Russo" <crusso@xxxxxxxxxxxxxxxxx>
Date: Wed, 2 Jul 2003 14:54:59 -0300
I see...

-----Original Message-----
From: Wendell Piez [mailto:wapiez@xxxxxxxxxxxxxxxx]
Sent: Miércoles, 02 de Julio de 2003 01:42 p.m.
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: RE: [xsl] xsl:sort in old MSXML


The magic combination of standards-adherence with wide accessibility (i.e. 
reach some high percentage of browsers) is still difficult to achieve with 
generic XML, perhaps even impossible on the client. (I leave aside the 
growing number of XML applications, such as RSS or SVG, that do an end run 
around this problem for their particular application.) This is because 
although 80-90% of what is necessary is standardized -- XML and XSLT -- the 
last 10-20% is *not*, and may remain so. :-( That's the part that 
configures the browser when the document is loaded, loading the appropriate 
stylesheet (perhaps letting the user select it), passing parameters in, and 
the rest, and provides the end user with whatever interface they need to 
configure and run things further. The sort of standard xml-stylesheet PI 
(the thing that goes "<?xml-stylesheet type='xsl' 
href='mystylesheet.xsl'?>") goes only part of the way there -- beyond a 
simple one-to-one relation between documents and stylesheets, with no 
parameters and no user-driven styling, we have to resort to proprietary 
interfaces such as the MS VB/Javascript stuff (which of course only runs in 

So we route around the problem, processing the XML on the server to give 
browsers what they are used to: HTML. This processing can be either 
on-demand ("dynamic") or ahead of time ("batch mode"). HTML/CSS/scripting 
is powerful enough so that most anything can be achieved this way, 
dynamically over http when necessary (though scaling the system is harder 
than it would be in the client-side model) -- but it does mean that you 
can't serve up plain files, but have to run some kind of process on the 
back end. In turn, this means either access to a server (running Apache 
Cocoon, or something analogous such as the 4Suite engine in Python that 
I've been trying lately), or constraining yourself to the batch-processing 
model David and I have described.

It's true that we lose many of the promised strengths of XML by doing this: 
there's a great deal that's attractive about being able to process on the 
client. But without a "killer app" (a breakthrough application that 
demonstrates the strength of the paradigm and brings all competitors with 
it), there appears to be no incentive for the browser vendors actually to 
get together and develop a standard API for loading and configuring 
client-side XSLT. (For whatever reason, they prefer the zero-sum battle of 
proprietary interfaces to the positive-sum platform of a standard all can 
work with.) Consequently, if you *must have* your XSLT processing happen on 
the client, it's still very difficult (impossible) to stay browser-neutral.

XUL, anyone? (Where did that go? Can you drive XSLT processing through it?)


At 09:06 AM 7/2/2003, Claudio wrote:
>But this will tie me up with a specific technology instead of begin 
>adhering straight to standards and open tech. For sure this technology is 
>one step ahead of the standard but unless is a standard by itself (which I 
>doubt from the msgs coming to this list), will be difficult to see 
>applications running smoothly in, lets say, at least 90% of the clients 
>As I said, I've been playing a little bit (for sure not as much as you did 
>guys) with the XML/XSLT technology and is time to wrap up and take in 
>concern what I mention before, being able to deploy a site with minor 
>environment problems, inmediate adherance to standards and simple maintenance.

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

 XSL-List info and archive:

 XSL-List info and archive:

Current Thread